посмотри для сравнения как уёбищно он выглядит в elm без рефлексии

маршалинг json отдельная тема, его глупо делать через что-то кроме интроспекции

Ну и конечно же автор не счёл нужным даже попытаться привести пример из практики, где без дженериков никуда. Чсх.

Его вполне нормально делают в том же русте через макросы, получается очень красиво и удобно И быстро, ЧСХ

тут надо ещё смотреть насколько важна эта быстротат в реальных проектах. и стоит ли она потери времени на компиляцию макросов. И самый киллер аргумент - с макросами не будет ни какого gogland, будет хз что как в русте))

У меня кстати после прочтения The Rust Programming Language сложилось первое впечатление, что Rust состоит сплошь из неудобных в использовании костылей (которые почему-то называют zero-cost abstractions, забывая про ментальный cost) где в жертву memory safety и data race safety приносится всё что только можно. Не завидую программистам, пишущим на rust многопоточные программы, работающие с shared mutable state :) Поразило отсутствие аналога go-шных горутин в стандартной поставке rust. Обнаружил там только стандартные потоки операционной системы, потребляющие мегабайты памяти под стек при старте и жрущие процессорное время при переключении между ними. Не понятно, как в этом случае писать серверные приложения, обрабатывающие миллион одновременных подключений. Через callback hell?

Я могу привести Во-первых, это коллекции Ты либо делаешь коллекцию с interface{}, либо прикручиваешь очередной кодогенератор сбоку, и то и то уродливо для невозможности Во-вторых, это всё связанное с обработкой структурированных данных Датафреймы? Забудьте. Нормальная линейная алгебра? В топку

Какие контейнеры кроме array и hashmap вы используете каждый день? Эти два контейнера встроены в Go и позволяют работать с произвольными типами. Остальные используются (у меня) настолько редко, что не составляет никакого труда написать их кастомную реализацию под требуемый тип данных.

Многие вещи делаются в Go легко и приятно, но всё вне узкой области задач не делается почти никак

на го пишут для довольно узких областей задач, на одной из которых (так уж получилось) основан веб, а другая почти стала стандартом виртуализации если ты пишешь что-то другое - тебе не нужен го, не стоит себя мучать

на го пишут для довольно узких областей задач, на одной из которых (так уж получилось) основан веб, а другая почти стала стандартом виртуализации если ты пишешь что-то другое - тебе не нужен го, не стоит себя мучать

я про докеры и кубернейтесы

Никакие и по очень простой причине: в Go их почти невозможно реализовать нормально. Поэтому как только мне нужно делать что-то сложнее hashmap, я беру питон Мне не хватает возможности сделать стек, R-деревья, вот недавно понадобилась очередь с приоритетами, и знаете что? Я плюнул и взял питон, потому что тратить время на написание уже 100500 раз написанного до этого кода, а потом на его тестирование мне не хочется Если вы используете Go исключительно как dsl для вебчика (взять данные, сходить к базе, отдать данные), то ради бога, вам не понадобится ничего сложнее hashmap Как только ты делаешь шаг в лево, шаг в право — финиш, выясняется, что тебе нужно писать либо велосипед, либо проделывать кодогенератор в пайплайн, либо кастить пустые интерфейсы на каждый чих

ни то, ни другое не виртуализация)

слушай, есть задача, есть инструмент

слушай, есть задача, есть инструмент

не все так просто, иначе бы в мире был только си и джаваскрипт)

никогда не писал продакшен код на питоне, но что-то сомневаюсь что в нём реализация r tree кардинально лучше этой https://godoc.org/github.com/dhconnelly/rtreego

стек, очередь - массив + минимальный бойлерплейт

си и Джава скрипт не решают бизнес задач по повышению производительности программистов, поддержке кода и так далее

ок, тогда еще джава

ок, тогда еще джава

https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/fulltext

Она кардинально лучше, потому что мне не нужно кастить интерфейсы. Собственно, именно такие вот случаи сводят достоинства Go, частности, статическую типизацию, в нуль

В случае Go это означает, что ты пишешь целый отдельный пакет со своими тестами

Я много кода ревьюю каждый день, бойлерплейт на подобные тесты на стек и очередь как то не сильно напрягает. А вот чтобы понять, что написано в loc на расте - надо как правило почитать про кучу трейтов, структур, увидеть кто и как наследует всякие Read + Write + Any + Send + Typeable, осилить еще и эти трейты, перечитать реализации всех трейтов дальше по коду, разобраться, какой из них из std, какой локальный и прочая, прочая и прочая. Меня смущает вот эта "нелокальность" языков, когда для того, чтобы понять происходящее, надо идти не в базовую либу, документацию и класс-предок, а облазить пол-интернета, кэши пакетных менеджеров, исходники либ на гитхабе и половину stackoverflow и гуглогрупп разработчиков языка. Да, стат. ад-хок полиморфизм в расте работает при мерно на 5 нс на один каст быстрее, чем даункасты в Го. Но проблемы с последними в проде - это нонсенс, а если и появляются, то решаются мгновенно.

А что в русте не так? Vscode + rls прекрасен чуть менее, чем полностью Тут дело не в быстроте самой по себе , а в том, что это не требует рефлексии и в тоже время удобно и быстро

Не согласен что в rust хороший тулинг. Пример хорошего тулинга - go get ./..., который вытягивает все зависимости на основе содержимого исходников. Пример устаревшего тулинга - это отдельно прописывать зависимости в toml файле. ну и ide для rust нормальной нет. И видимо не будет, поскольку там применяются маргинальные парадигмы, связанные с макросами и трейтами, которые практически не возможно номрально линтить

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

dep, glide, gb, govendor, godep

Ага, вот glide и использую. Потому что чистый go get это не выносимо когда используешь опенсорс

Шеф сказал, что мы заканчиваем программировать на GO и переходим на .NET 😪

Шеф сказал, что мы заканчиваем программировать на GO и переходим на .NET 😪

Шеф сказал, что мы заканчиваем программировать на GO и переходим на .NET 😪

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

go way в данном случае - папка vendor. абсолютная панацея от дибилизма на подобие cabal hell

Шеф сказал, что мы заканчиваем программировать на GO и переходим на .NET 😪

"пример хорошего тулинга - go get" и именно поэтому пилят dep видимо ) про cabal hell если честно смешно, когда ты последний раз реально сталкивался с этим? (а не читал пост от 2005 года где говорилось что есть такая проблема)

net core - фигня полная. дубль-джава, отстающая в развитии на 10-15 лет. Сайтики на ней писать - боль, ибо UTF16 и надо асилить и притянуть в проект сверхсложный монстро-фреймворк с кучей бесполезных костылей чтобы написать хелуворд. размер докер-имиджа не реальный проект с этим всем - от 500 мб до 1 гб

А debug версия весит таки 750 . В реальном продакшен проекте по мимо asp net core нужен ещё воз с кирпичами. Это в гошечке всё, что нужно, есть в стандартной библиотеке искаропки. А в нэт коре на любой чих начинается мучительный поиск очередной маргинальной библиотеки от непонятно кого (и не дай бог допустить малейшую ошибку с версией любой из них), которые примерно на пол гига и будут.

Павел, ваша боль понятна. Я её даже разделяю. Но где net и где канал про go ?