Многие хвалят D, но остаётся подвисшим вопрос — почему он не взлетел, если он настолько хорош? Был аргумент, что за ним не стояла большая корпорация, но за последнее время появилось несколько языков вроде Zig, к которым сейчас, субъективно, больше интереса, чем к D. Дело ещё не в языке, а в тулинге например. Может быть, с тулингом что-то не так? В Go много хорошего, что есть из коробки, не касается языка как такового.
Всё-таки основной use case дженериков это обобщённые контейнеры. Из-за этого по факту в Go всего два типа контейнеров — слайсы и мапы, что далеко от идеала. Как наличие только generic-функций решило бы этот вопрос?
Да, простота может быть разная. Простота использования, простота реализации, простота поддержки кода. Брэйнфак очень простой язык, но пользоваться им невозможно.
Тут, думаю, нужно впервую очередь смотреть на практику. В целом, на Go довольно просто писать код. Но доказать, что код корректный, сложнее, чем, например, в Rust. И тут мы упираемся в то, что по большому счёту все холивары основываются на субъективных ощущениях, интуиции. Очень мало у нас опираются на исследования и метрики по поводу того, как та или иная фича влияет на разработку. А иначе мы просто топчемся на месте. Недавно открыл для себя термин evidence-based software engineering, по нему есть литература, напр. одноимённая книга Дерека Джонса.
Тут дилемма — если наваять most common denominator, т.е. только те фичи, которые есть во всех OS, то API работы с окружением будет ограничено в фичах, от этого страдала Java, например. Другой вариант вообще не делать общего API, но тогда из коробки вообще ничего нет. Выбор Unix-поведения как дефолтного считаю на практике обоснованным, т.к. целевая аудитория Go это всё-таки Unix-подобные системы, которых большинство, и Windows тут скорее исключение, чем правило. Такова реальность — в итоге в самом Windows добавили WSL, posix compatibility layer; инструменты разработчика портируются с Linux на Windows, и не наоборот.
Авторы создали Go, потому что устали ждать долгой компиляции проектов на C++ в проектах Google. Изначальная идея Go была в том, чтобы это был простой good enough язык, который легко масштабируется на большие кодовые базы at scale и при этом быстро компилируется. По сути основные первоначальные решения отталкивались именно от этого — быстрая компиляция больших проектов (что иронично, когда сейчас один из основных use case'ов Go это микросервисы). Отсюда запрещены циклические зависимости, поэтому в язык добавлен structural typing, поэтому нет наследования, поэтому местами синтаксис немного странный — для быстрого парсинга, и т.д. Дженерики, шаблоны — они значительно могут замедлить время компиляции и сильно раздуть код (code bloat), если их неправильно приготовить. Поэтому много времени ушло на то, чтобы найти правильный баланс, т.к. авторы, видимо, были травмированы опытом в C++. Go часто по фичам сравнивают с Rust, но там вроде время компиляции не возведено в абсолют, и я слышал истории, что в Rust со скоростью работы компилятора не так всё гладко. То, что авторы Go в рантайме в итоге реализовали для оптимизации компилятора, похоже на generic code sharing при реификации дженериков в C#, которые там давно есть. Странно, что так долго к этому приходили, возможно были трудно решимые проблемы с семантикой/синтаксисом, чтобы было backward compatible. Т.е. тут основной косяк авторов в том, что первоначальный драфт языка не проектировался с учётом расширения его под дженерики, напр. теперь map[int]int смотрится странно.
это закрытая разработка, всем рулит небольшая группа людей из гугла и на интересы сообщества им наплевать
Я давно слежу за разработкой go и это совсем не то, впечатление, которое я получил. Как минимум, каждый год проводится survey для понимания приоритетов сообщества, я участвую в каждом. Отсутствие дженериков было обозначено как проблема номер один. Любой желающий может предложить proposal. Проблема в том, что большинство proposals ещё более half-baked, чем то, что предлагает ядро разработчиков из Гугла. В стиле "я видел фичу Х в другом языке, хочу так же". Детали не проработаны, backward compatibility не проработано, и т.д.
Это миф про то, что "принципиально" не хотели. Если поискать через wayback machine, то официальный faq уже в 2013 году (раньше не нашёл) писал о том, что они открыты к добавлению дженериков, но пока нет понимания, как лучше реализовать.
В Go нет тип-сумм — и поэтому там реально неудобно написать тип, который представлял бы «либо адрес IPv4, либо адрес IPv6
В большинстве случаев такое спокойно решается через type switch. Но тут, думаю, нужно изначально проектировать по-иному — напр. работать не с конкретными типами, а с интерфейсами, и тогда без разницы что под капотом — ipv4, ipv6 или номер квартиры.
нo не допускает перегрузки операторов, напоминая о той давней истории Java, когда a == b не было идентично a.equals(b)
Есть такое, но менее актуально, т.к. если используются структуры по значению (которых в Java нет), то сравниваться будет контент, а не ссылки, что в большинстве случаев всё, что нужно. Но, конечно, для каких-то типов это неверно, и по синтаксису сразу не ясно, какой из типов сравнения будет использоваться.
В Go отсутствует поддержка неизменяемых данных.
По старинке — обернуть в read-only интерфейсы. Вообще мне больше импонирует идея view-интерфейсов, т.к. они более гибкие, чем какой-то один прибитый гвоздями механизм на уровне языка.
В целом я бы сказал, что для 90% случаев существующие примитивы — good enough. В 10% случаев нужны танцы с бубном. В каких-то языках из-за перфекционизма танцы с бубном будут больше 10%, зато всё теоретически красиво. Всё-таки, Go замышлялся как простой язык.
Большая часть налогов пополняется засчет экспорта энергоресурсов. Откуда и должны уходить компании, так из Европы, как главного спонсора спецоперации :)
Рынок сожмется, но я думаю, что в краткосрочной перспективе (лет 5) на высококлассных специалистов спрос будет еще больше, потому что появится новое требование — умение работать в условиях ограниченных ресурсов, придется по максимуму оптимизировать все процессы, адаптироваться под ограничения, и т.д. — что не каждому дано. Ведь сейчас почти всё завязано на IT, и я не вижу предпосылок к тому, чтобы мы за пару лет резко вернулись в средневековье — т.е. спрос на IT в любом случае будет. Что, скорей всего, не будет — так это концепции вайтишников, т.е. людей, ожидающих баснословных зарплат после 3 месяцев курса по условному JS. Количество вакансий снизится, но, мне кажется, у высококлассных специалистов зарплаты могут вырасти ещё больше (относительно других профессий), т.к. это будет редкий диковинный зверь, но очень нужный зверь.
В долгосрочной перспективе пока ясного мало. Спецоперация длится всего 3 недели и многое ещё не определено. Если Россия будет планомерно нищать следующие 10-15 лет, то да, IT будет в целом капут. Но это будет уже совсем другая история, и у нас к тому моменту будут совсем другие заботы.
OVH порезал доступ к панели управления, попытки сменить пароль игнорируются. При этом машина ещё крутится и доступна, но видимо недолго — скоро автооплата и оплата наверное не пройдет (карта Сбербанка).
Теперь завёл новую учётку через знакомого немца на его имя и карту. Теперь уж если только начнуть банить доступ по IP.
Тем временем на телевизоре перестали работать LG Channels.
Большинство разработчиков думают, что в этой истории они д'Артаньяны, и пишут исключительно красивый и качественный код. А вот программист Петя, который до меня тут работал — ну и говнецо после себя оставил. Проходит время, д'Артаньян увольняется, на его место приходит новый д'Артаньян. Оказывается, предыдущий д'Артаньян на деле был самозванец, и писал он не красивый и качественный код, а быдлокод. И так ad infinitum, круговорот говнокода и д'Артаньянов… Нужно как-то по-философски к этому относиться :)
Для каких целей используется данная библиотека? При падении сервиса операция останется висеть в полуобработанном состоянии, т.к. события никуда не персистируются. Т.е. для критичной бизнес-логики не подходит. Для логирования - ОК. Возможно, стоит прописать это явно?
Имеет смысл ещё написать про реентрабельность. Напр., что будет, если я дёрну bell.Ring в обработчике?
Как дела с graceful degradation? Т.е. у нас крутятся тяжеловесные обработчики, а процесс нужно срочно стопануть. Как поведёт себя библиотека?
Согласен. Но в данной статье (и других похожих) делается вывод, что ranges являются (помимо прочего) решением проблем с памятью. Хотя по факту это просто синтаксический сахар, и ситуация мало поменялась, только добавилось новых подводных камней :) Я на это хотел обратить внимание.
Почитал документацию - range на массивы создаёт копию массива в нужном срезе, т.е. я не понял, почему нагрузка на память меньше. Тут ведь всё ещё хуже - новый синтаксис скрывает аллокации потенциально больших данных. Согласно той же документации, копирования нет только на Span и Memory. Т.е. нужно обращать внимание на тип коллекции, чтобы понять, будет выделение памяти или нет. И со Span'ом тоже спорный вопрос. Допустим, у меня есть массив в мегабайт, далее я создал range на 3 элемента и собираюсь пользоваться только им - не получится ли так, что в памяти будет болтаться 1 мегабайт бесхозной памяти, потому что Span удерживает ссылку на массив в целом?
А, и ещё - в языках низкого уровня типа C/C++ существует проблема алиасинга, т.е. это когда мы не можем активизировать оптимизацию при работе с указателем в полную меру, потому что статически мы не всегда можем определить, есть ли ещё кто-то, кто ссылается на этот участок памяти (возможно, с другим типом). Если мы будем считать, что у указателя только один пользователь, мы можем применить далеко идущие оптимизации, но это зачастую ломает кучу кода (когда оказывается, что пользователей много - в других потоках, через type punning, это может быть несколько указателей на пересекающиеся участки массива), в итоге часто или ставят не самый высокий уровень оптимизации, или в самом компиляторе не делают оптимизацию, т.к. 99% софта надеятся на UB (не зная об этом). Вот тут как раз у более высокоабстрактных языков с чётко определённой memory model можно больше оптимизаций выжать.
Многие хвалят D, но остаётся подвисшим вопрос — почему он не взлетел, если он настолько хорош? Был аргумент, что за ним не стояла большая корпорация, но за последнее время появилось несколько языков вроде Zig, к которым сейчас, субъективно, больше интереса, чем к D. Дело ещё не в языке, а в тулинге например. Может быть, с тулингом что-то не так? В Go много хорошего, что есть из коробки, не касается языка как такового.
Всё-таки основной use case дженериков это обобщённые контейнеры. Из-за этого по факту в Go всего два типа контейнеров — слайсы и мапы, что далеко от идеала. Как наличие только generic-функций решило бы этот вопрос?
Да, простота может быть разная. Простота использования, простота реализации, простота поддержки кода. Брэйнфак очень простой язык, но пользоваться им невозможно.
Тут, думаю, нужно впервую очередь смотреть на практику. В целом, на Go довольно просто писать код. Но доказать, что код корректный, сложнее, чем, например, в Rust. И тут мы упираемся в то, что по большому счёту все холивары основываются на субъективных ощущениях, интуиции. Очень мало у нас опираются на исследования и метрики по поводу того, как та или иная фича влияет на разработку. А иначе мы просто топчемся на месте. Недавно открыл для себя термин evidence-based software engineering, по нему есть литература, напр. одноимённая книга Дерека Джонса.
Тут дилемма — если наваять most common denominator, т.е. только те фичи, которые есть во всех OS, то API работы с окружением будет ограничено в фичах, от этого страдала Java, например. Другой вариант вообще не делать общего API, но тогда из коробки вообще ничего нет. Выбор Unix-поведения как дефолтного считаю на практике обоснованным, т.к. целевая аудитория Go это всё-таки Unix-подобные системы, которых большинство, и Windows тут скорее исключение, чем правило. Такова реальность — в итоге в самом Windows добавили WSL, posix compatibility layer; инструменты разработчика портируются с Linux на Windows, и не наоборот.
Авторы создали Go, потому что устали ждать долгой компиляции проектов на C++ в проектах Google. Изначальная идея Go была в том, чтобы это был простой good enough язык, который легко масштабируется на большие кодовые базы at scale и при этом быстро компилируется. По сути основные первоначальные решения отталкивались именно от этого — быстрая компиляция больших проектов (что иронично, когда сейчас один из основных use case'ов Go это микросервисы). Отсюда запрещены циклические зависимости, поэтому в язык добавлен structural typing, поэтому нет наследования, поэтому местами синтаксис немного странный — для быстрого парсинга, и т.д. Дженерики, шаблоны — они значительно могут замедлить время компиляции и сильно раздуть код (code bloat), если их неправильно приготовить. Поэтому много времени ушло на то, чтобы найти правильный баланс, т.к. авторы, видимо, были травмированы опытом в C++. Go часто по фичам сравнивают с Rust, но там вроде время компиляции не возведено в абсолют, и я слышал истории, что в Rust со скоростью работы компилятора не так всё гладко. То, что авторы Go в рантайме в итоге реализовали для оптимизации компилятора, похоже на generic code sharing при реификации дженериков в C#, которые там давно есть. Странно, что так долго к этому приходили, возможно были трудно решимые проблемы с семантикой/синтаксисом, чтобы было backward compatible. Т.е. тут основной косяк авторов в том, что первоначальный драфт языка не проектировался с учётом расширения его под дженерики, напр. теперь map[int]int смотрится странно.
Я давно слежу за разработкой go и это совсем не то, впечатление, которое я получил. Как минимум, каждый год проводится survey для понимания приоритетов сообщества, я участвую в каждом. Отсутствие дженериков было обозначено как проблема номер один. Любой желающий может предложить proposal. Проблема в том, что большинство proposals ещё более half-baked, чем то, что предлагает ядро разработчиков из Гугла. В стиле "я видел фичу Х в другом языке, хочу так же". Детали не проработаны, backward compatibility не проработано, и т.д.
Это миф про то, что "принципиально" не хотели. Если поискать через wayback machine, то официальный faq уже в 2013 году (раньше не нашёл) писал о том, что они открыты к добавлению дженериков, но пока нет понимания, как лучше реализовать.
В большинстве случаев такое спокойно решается через type switch. Но тут, думаю, нужно изначально проектировать по-иному — напр. работать не с конкретными типами, а с интерфейсами, и тогда без разницы что под капотом — ipv4, ipv6 или номер квартиры.
Есть такое, но менее актуально, т.к. если используются структуры по значению (которых в Java нет), то сравниваться будет контент, а не ссылки, что в большинстве случаев всё, что нужно. Но, конечно, для каких-то типов это неверно, и по синтаксису сразу не ясно, какой из типов сравнения будет использоваться.
По старинке — обернуть в read-only интерфейсы. Вообще мне больше импонирует идея view-интерфейсов, т.к. они более гибкие, чем какой-то один прибитый гвоздями механизм на уровне языка.
В целом я бы сказал, что для 90% случаев существующие примитивы — good enough. В 10% случаев нужны танцы с бубном. В каких-то языках из-за перфекционизма танцы с бубном будут больше 10%, зато всё теоретически красиво. Всё-таки, Go замышлялся как простой язык.
Большая часть налогов пополняется засчет экспорта энергоресурсов. Откуда и должны уходить компании, так из Европы, как главного спонсора спецоперации :)
90% специалистов по эффекту Даннига-Крюгера считают, что они понимают эффект лучше, чем большинство других специалистов.
Хорошо будет звучать "держу свои сбережения выибанке"
Рынок сожмется, но я думаю, что в краткосрочной перспективе (лет 5) на высококлассных специалистов спрос будет еще больше, потому что появится новое требование — умение работать в условиях ограниченных ресурсов, придется по максимуму оптимизировать все процессы, адаптироваться под ограничения, и т.д. — что не каждому дано. Ведь сейчас почти всё завязано на IT, и я не вижу предпосылок к тому, чтобы мы за пару лет резко вернулись в средневековье — т.е. спрос на IT в любом случае будет. Что, скорей всего, не будет — так это концепции вайтишников, т.е. людей, ожидающих баснословных зарплат после 3 месяцев курса по условному JS. Количество вакансий снизится, но, мне кажется, у высококлассных специалистов зарплаты могут вырасти ещё больше (относительно других профессий), т.к. это будет редкий диковинный зверь, но очень нужный зверь.
В долгосрочной перспективе пока ясного мало. Спецоперация длится всего 3 недели и многое ещё не определено. Если Россия будет планомерно нищать следующие 10-15 лет, то да, IT будет в целом капут. Но это будет уже совсем другая история, и у нас к тому моменту будут совсем другие заботы.
OVH порезал доступ к панели управления, попытки сменить пароль игнорируются. При этом машина ещё крутится и доступна, но видимо недолго — скоро автооплата и оплата наверное не пройдет (карта Сбербанка).
Теперь завёл новую учётку через знакомого немца на его имя и карту. Теперь уж если только начнуть банить доступ по IP.
Тем временем на телевизоре перестали работать LG Channels.
Большинство разработчиков думают, что в этой истории они д'Артаньяны, и пишут исключительно красивый и качественный код. А вот программист Петя, который до меня тут работал — ну и говнецо после себя оставил. Проходит время, д'Артаньян увольняется, на его место приходит новый д'Артаньян. Оказывается, предыдущий д'Артаньян на деле был самозванец, и писал он не красивый и качественный код, а быдлокод. И так ad infinitum, круговорот говнокода и д'Артаньянов… Нужно как-то по-философски к этому относиться :)
Silverlight помер, потому что требовал установки плагина, а потом внезапно html5.
Для каких целей используется данная библиотека? При падении сервиса операция останется висеть в полуобработанном состоянии, т.к. события никуда не персистируются. Т.е. для критичной бизнес-логики не подходит. Для логирования - ОК. Возможно, стоит прописать это явно?
Имеет смысл ещё написать про реентрабельность. Напр., что будет, если я дёрну bell.Ring в обработчике?
Как дела с graceful degradation? Т.е. у нас крутятся тяжеловесные обработчики, а процесс нужно срочно стопануть. Как поведёт себя библиотека?
Хотелось бы подобных деталей.
Ну да, в прошлый раз с Итаниумами ведь удачно вышло ;)
Согласен. Но в данной статье (и других похожих) делается вывод, что ranges являются (помимо прочего) решением проблем с памятью. Хотя по факту это просто синтаксический сахар, и ситуация мало поменялась, только добавилось новых подводных камней :) Я на это хотел обратить внимание.
Почитал документацию - range на массивы создаёт копию массива в нужном срезе, т.е. я не понял, почему нагрузка на память меньше. Тут ведь всё ещё хуже - новый синтаксис скрывает аллокации потенциально больших данных. Согласно той же документации, копирования нет только на Span и Memory. Т.е. нужно обращать внимание на тип коллекции, чтобы понять, будет выделение памяти или нет. И со Span'ом тоже спорный вопрос. Допустим, у меня есть массив в мегабайт, далее я создал range на 3 элемента и собираюсь пользоваться только им - не получится ли так, что в памяти будет болтаться 1 мегабайт бесхозной памяти, потому что Span удерживает ссылку на массив в целом?
А, и ещё - в языках низкого уровня типа C/C++ существует проблема алиасинга, т.е. это когда мы не можем активизировать оптимизацию при работе с указателем в полную меру, потому что статически мы не всегда можем определить, есть ли ещё кто-то, кто ссылается на этот участок памяти (возможно, с другим типом). Если мы будем считать, что у указателя только один пользователь, мы можем применить далеко идущие оптимизации, но это зачастую ломает кучу кода (когда оказывается, что пользователей много - в других потоках, через type punning, это может быть несколько указателей на пересекающиеся участки массива), в итоге часто или ставят не самый высокий уровень оптимизации, или в самом компиляторе не делают оптимизацию, т.к. 99% софта надеятся на UB (не зная об этом). Вот тут как раз у более высокоабстрактных языков с чётко определённой memory model можно больше оптимизаций выжать.