All streams
Search
Write a publication
Pull to refresh
191
0
divan0 @divan0

Пользователь

Send message
Я попросил три реальных примера (показать код, к примеру или рассказать суть задачи).
Человек привел надуманный пример и сказал одно (сортированный список).
Вы перекрутили его слова, обвинив меня в том, что я предлагаю список для реализации сортированного массива.
Потом сказали, что «там как раз понятно».

Новый формат общения на Хабре, мда.
Отнюдь, статья была не «мне не понравился язык», а «какой плохой дизайн у языка». Статья, которую, не читая, репостят и рассылают, а комментарии оккупированы людьми, не знакомым с языком, но люто его ненавидящим, и искажающим реальную картинку. Эта статья — зеркальный ответ для уравновешивания, не более.
А вот автор статьи явно считает, что Go идеально спроектирован профессионалами

Автор статьи уже несколько раз писал, что категориями «идеально»/«не идеально» не мыслит. Не нужно обвинять его в том, что придумали сами. :)

А если вы изучите истории появления различных языков, то поймете, что за всеми ними действительно стоят разной зрелости люди и команды, и разные мотивы.
«Костыль» — это ярлык, не более. Shebang — это тоже такой-же «костыль», что не мешаем ему исправно выполнять свою функцию на всех UNIX-системах, не так ли?
Так что важнее — практическая польза или чей-то ярлык «костыля»? Какие реальные практические проблемы с go generate были хотя бы у одного из комментаторов тут? Да ни у кого.

Конкретно по поводу go generate — был пропозал и были дискуссии о том, как лучше решить проблему. В дискуссии мог поучаствовать каждый хабровчанин и предложить «не костыль», обосновав, почему его «не костыль» будет хорошим дизайном.
Почему «к сожалению»? Сейчас append — детерминированная функция, которая делает одну ясную и четкую операцию.
Если вам нужно добавить несколько других значений и слайсов — сделайте это явно. Избавляйтесь от этого желания «написать все в два символа», чтобы потом другие программисты гадали, что же имелось ввиду и зачем.
А тут — набор ad-hoc-костылей и решений с потолка, уж простите.

Это не так. Хотите себя убеждать, что Go — это набор костылей с плохим дизайном, пожалуйста. Самообман — дело легкое.
То есть идея в том, что глядя на вставку в середину массива, человек должен заподозрить неладное и убедиться, что оно к месту.

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

Добавление элемента в сортированный список.
Вы самостоятельно изменили слово «список» на «массив», и находитесь в шоке. Почему бы и другие слова не поменять, как вам хочется?
Ни о чём.
Потому что потребность в работе с сишным кодом уменьшается с каждым месяцем, хотя и так была невелика.

Да, могут, но только если вы специально захотите это сделать, и разберетесь в том, как и зачем это делать. Реальность Go такова, что когда речь заходит о таких специфических случаях, это оказывается банально простой и удобный способ. Со стороны, конечно, это не очевидно.
Да, про CGO я забыл, так как уже почти не встречаю в реальности — но на заре Go это был очень полезный инструмент, который использовался, разумеется, не так, как в вашем примере.
Если бы вы писали на Go, вы бы понимали, почему нет оснований полагать, что кто-нибудь так напишет. А если и напишет, то ничего страшного не произойдет. С таким же успехом можно говорить «Tesla — плохой автомобиль, потому что кто-то можно положить пальто на тачскрин и не сможет его видеть». Попробуйте на практике и судите о дизайне по делу, а не по придуманным кейсам.
Так и происходит обычно, но это всё процессы, занимающие месяцы/годы и отнимающие силы, ресурсы и эмоции.
Отказ от мейкфайлов — это желание упростить процесс сборки, убрать необходимость в ещё одном «языке», ещё одном слое потенциальных проблем, ошибок и сложности.
Все проекты в Go собираются командой «go build» или «go build ./..» (для рекурсивной сборки проектов в поддиректории). go generate появился в Go 1.4, как ответ на все чаще возникающие проекты, в которых нужно было запускать время от времени какие-то кодогенераторы — специально ради них городить подобие мейкфайлов было бы никудышним решением.

Не думаю, что авторы Go когда-либо допустят злоупотребления вот такими «специальными» комментариями — уж слишком долгие и широкие дискуссии вызывает каждый пропозал. «Просто так», «по неосмотрительности» в Go решения не попадают. Если появится надобность в новых «специальных комментариях», то будут искать более оптимальное решение. Пока же это один go generate — никаких проблем реально нет. Удобное решение для конкретной практической задачи.

Про инклуд уже писал выше. Да, сам сначала возмущался — ведь так непривычно. Сейчас не представляю, во чтобы превратился мой (и чужой) Go код, позволяй мне компилятор «иногда отключать» эту ошибку.
А что, по вашему, будет хорошим решением?
Вы это уже написали в 10 комментариях. Отсутствие отрицательных индексов — это не «актуальные проблемы», это «привычка». На этом и разойдемся.
Безусловно. Но, если вы когда-нибудь пробовали внедрять новые технологии в очень консервативную среду, то должны знать, что это процесс зачастую непростой и встречающий массу сопротивления.
Комментарии не меняют логики программ, автор вас ввел в заблуждение.

go generate используется для стандартизации рабочего процесса, позволяя любые кодогенераторы (для Protocol Buffers, Thrift или SWIG) вызывать одной командой — go generate, а не заставлять каждого писать мейкфайлы.
Евнух, так можно про каждый комментарий писать. Это же не дискуссия уже. Вот ваш комментарий — тоже пустой спор и болтовня. и вы субъективны.

Какие факты? Человек, рассказавший, как ему неадекватные вбросы приводит к реальным проблемам на работе — должен анонимусам в интернете «факты» писать? Справки с работы и видеозаписи общения с боссом? О чем вы? :)
И «школьник» — это не унижение, автор статьи нам знаком и он, действительно, учится в школе.
lair, ваши комментарии заполонили каждую статью про Go. Предлагаю вам сделать следующий шаг и написать реальный проект на Go. Отлично будет, если это будет open-source проект — тогда мы вместе посчитаем, сколько раз вам понадобился insert или обход слайса в обратном порядке. Все таки главное разногласие у вас с Go именно в том, что практично, а что нет.

Давайте, после многих месяцев и лет теоретизирования о том, почему Go плох, и насаживания своего мнения, перейдем к следующему этапу — к практике. Я знаю, это сложный шаг, но мы вас тут поддержим :)
Эта статья — исключительно контр-ответ на не совсем адекватный выпад, который, к сожалению, люди уже тиражируют и репостят, не читая. Вот вам реальный случай:
Пока читал вброс от Ильи хотелось дать ему леща отцовского, да обещал в интернетах не срываться. :) Для меня самые важные показались последние абзацы, потому что я уже потратил 6 мес на своей работе внедряя Go. (Пока результат не очень — пишем внедряем, выпиливаем потому что все боятся начинать). И что самое страшное после каждого выпиливания, я получаю набор статей от моих коллег типа той что состряпал Илья, как аргумент что язык сырой и что пока рано на него переходить. Я смело могу сказать что болтовня таких малолеток не только замедляет развитие языка, но еще и не дает развиваться специалистам, которые хотят его попробовать в продакшене. Но Илье то этого не понять, потому что сидя за партой в школе можно только догадываться о том как же живет программист в реальном мире и на сколько трудно привносить какие-то новые технологии в старые компании.

Information

Rating
Does not participate
Location
Barcelona, Barcelona, Испания
Date of birth
Registered
Activity