Pull to refresh
4
0
Ilya Pirogov@ilyapirogov

Developer

Send message
А сколько времени понадобится на то, что бы рынок сам себя отрегулировал и какой ущерб это нанесет другим отраслям?
Не говорите это любителям таких игр, как Dwarf Fortress и Cataclysm: Dark Days Ahead :)

В этом и заключается проблема. Никто не может запретить вам покупать и сжигать Ferarri. И, вероятно, никому даже не будет до этого дела, до тех пор пока на их производство не начнет тратится заметная часть ресурсов государства.


Но если вдруг пол страны начнет покупать и сжигать Ferarri, то государство может оказаться в затруднительном положении. С одной стороны оно получает с этого доход в виде налогов. Но с другой стороны, сожженный метал не приносит никакого развития в долгосрочной перспективе и мешает другим отраслям. Ведь можно было бы пустить эти ресурсы на освоение космоса, разработки в сфере медицины, постройки промышленных предприятий, и т.д.


Отсюда и возникает одно из возможных решений — запретить сжигать Ferarri. Другое, на мой взгляд, возможное решение — это регулировать поставки электроэнергии в зависимости от его назначения. Т.е. если ты покупаешь электроэнергию для майнинга, то для тебя будет доступно условно только 100 КВт, либо цена за 1 КВт будет значительно выше.

Кроме того, многие игры позволяют персонально развиваться.
Например, такие игры как Screeps и CodeCombat помогают развивать программерские навыки. Игры на подобии Choice of Robots — не хуже хорошей книги. Role Play игры вполне себе неплохо тренируют речь. Witness, Portal, Talos Principle и сотни других подобных игр развивают логику. И этот список можно продолжать еще долго.


А какое персональное развитие человек получает от майнинга?

  1. Всё еще сидят. Часто на крутых крутящихся табуретках. Стоять 8 часов — зачем?

Уверен, что они стоят не 8 часов подряд. Для этого смены же придуманы. А зачем, я думаю, как раз об этом в статье указано.


  1. Всё еще соло-кассир, никто не помогает упаковываться. Но с учетом менталитета и культуры, оно может и к лучшему.

Да, согласен. Но на скорость продвижения очереди это однозначно положительно влияет.

Внесу немножко позитива :)


Лично мне Golang понравился своим вниманием к мелочам. Каждый преподносимый здесь плюс не тянет на киллер фитчу, будь то:


  • Встроенные утилиты godoc, gofmt, go test, go generate, etc
  • Установка пакетов из любых git репозиториев
  • Распараллеливание одним ключевым словом
  • Статическая кросс-компиляция из коробки
  • WebAssembly опять же из коробки
  • Очень простые и удобные стандартные пакеты, такие как rpc или flag
  • И многое других мелочей, что сразу не приходит в голову.

По отдельности здесь нет ничего особенного. Например в других языках есть JavaDoc, PyDoc, LuaDoc и куча разных утилит к ним; Линтеров и форматоров вагон к любому языку — выбирай на вкус. Для кросс-компиляции достаточно банч пакетов через apt/yum/portage поставить, итп.


Но удобоство Golang в том, что: a) все это сразу доступно из коробки, скачал — и можно сразу работать; б) они очень удобные и продуманные; в) благодаря предыдущим пунктам, большинство пакетов используют единый подход, что сокращает зоопарк библиотек и подходов и очень сильно упрощает анализ чужого кода.


Так что в итоге: быстрый вход, быстрая разработка, быстрое развертывание. На мой взгляд, весьма хороший инструмент для всяких ботов, консольных утилит, API и не очень крупных сервисов.
Но если вы уже умеете все это делать на других языках и вам это не доставляет никаких неудобств, то, вероятно, Golang вам не нужен.

Я бы еще записал сюда очень простую кросс-компиляцию. Для одного из своих проектов я выбрал именно Golang, потому что нужно было написать утилитку для одного очень специфичного устройства на андроидолинуксе, где не то что Python или Perl, даже Bash не было.


GOARCH=arm GOOS=linux go build


Копируем бинарник через telnet и все работает.

У меня на языке вертится только одно слово: «Хренейдж» :)

Несколько персональных наблюдений отличий американских магазинов от российских. Правда в российском магазине я был последний раз 4 года назад, но возможно это все равно будет в тему.


  1. Во всех магазинах, которых я бывал, кассиры обслуживают стоя. Еще ни разу не видел, что бы они сидели.
  2. Очень часто кассир работает в паре с упаковщиком (рассовывателем продуктов по пакетам?). Т.е. кассир пробивает товар, а второй человек тут же укладывает его в пакет и убирает в твою тележку. К моменту завершения оплаты весь товар у тебя уже разложен.
  3. Нету никаких ограничений где входить и выходить из магазина. Т.е. никто не запрещает зайти в магазин через кассу, если так ближе или там меньше народу. В последнем российском магазине, который я помню, даже турникет был.
  4. Скорее больше относится к этике покупателей. В здешних магазинах всегда лежат 2-3 разделителя товаров и покупатели относятся очень трепетно к этому.
  5. А также весьма распространены кассы самообслуживания.

Лично для меня код с for:


for (const el of elements) {
  // ...
}

Куда более выразительный и самодокументируемый, чем:


elements.forEach(el => {
  // ...
})

Однажды, у меня был баг, который я весьма долго отлавливал. В итоге выяснилось, что я вместо примерно следующей конструкции:


if (control.isEnabled()) { ... } 

Написал:


if (control.isEnabled) { ... }

Да, к сожалению, даже отсутствие подобных хаков не позволяет избегать таких ошибок. Зато правило strict-boolean-expressions в tslint работает исправно.

Про хак с ~~ я, наример, не знал, хоть и работаю разработчиком уже 14 лет. Видимо, не в тех командах я работаю :)


Но тут вопрос в другом: зачем вообще использовать эти хаки и ухудшать читабельность кода, если есть полноценные, понятные даже людям незнакомым с JS, конструкции? В чем сакральный смысл выполнять работу минификатора?

Так может быть их нету в учебниках, потому что это вредные советы, которые ухудшают читаемость кода и не дают никакого реального профита? Во всяком случае, советы из разделов про условные операторы и преобразование типов.


Серьезно, сэкономить 8 байт и несколько секунд на parseInt() или Number(), чтобы потом потратить час, гадая что значит в данном контексте конструкция ~~someVar.

Есть еще простенькая библиотека https://github.com/caarlos0/env. Она позволяет мапить переменные окружения на структуру в стиле encoding/json

Отсюда еще нужно вычесть премиумы за страховку, отчисления в 401k (пенсия) и fee за социальные услуги. Наберется еще ~$500-1000. Плюс отдельно может быть еще налог штата.
Я не пропустил. Я просто не знаю как его компилировать, а времени разбираться не было. Добавлю попозже, если надо. Или же PR всегда приветствуются :)
В общем, в итоге собрал все тесты которые смог скомпилировать в одном месте и прогнал их с perf stat gist.github.com/ilya-pirogov/8079ed7dca0185a1cb89ec20910e26c4:



Если интересно, то весь исходный код выложил на github: github.com/ilya-pirogov/harb-test-1

PS Не обращайте внимания на то что однопоточный Rust на первом, я просто перепутал бинарники. он на предпоследнем у меня, перед однопоточной версией Go.
Так для того и делают шлем :)

У меня был включен режим madvise.


# cat /sys/kernel/mm/transparent_hugepage/enabled 
always [madvise] never

Попробовал переключать на always, never и обратно, но отличия были в пределах погрешности. Или нужно было как то иначе их включать?


Вообще, я думаю, что в данном случае все немного проще. Обслуживание ~30000 горутин априори чуть более затратно, чем четырех горутин + chan. Однако из-за того что я тестирую это на процессоре 7 летней давности эта разница кажется куда более заметной для меня.

А какая у вас версия Golang? Такое впечатление, что у вас GOMAXPROCS устанавливается в 1, а не равное количеству ядер.


И как вы его запускали? Через go run или go build?

Information

Rating
Does not participate
Location
Austin, Texas, США
Date of birth
Registered
Activity