https://issues.dlang.org/show_bug.cgi?id=18403

вроде оно

Ага. В кои-то веки скачал человек dmd чтобы новый язык выучить, а он краш логи выдает на простейших программах

Это ещё что. Rust у меня вообще не завёлся (на Windows)

а кто-нибудь вообще смотрел код фронтенда? может там проще всё выкинуть и заново переписать (нидайбох)

очень уж дофига багов смешных таких

Покажи примеры на го тех вещей о которых ты говоришь

https://paste.ofcode.org/GCZdTGZEQaEfTiuABgAtSp

Пасибо

Так, а если не инты будут?

Так, а если не инты будут?

Про сумм я писал выше - или писать универсальное что-то через reflect, или указывать тип. На D тоже по-умолчанию инты.

Хотелось бы более универсальный вариант

Хотелось бы более универсальный вариант

Ну вот есть готовый пакет с редьюсом: https://github.com/robpike/filter, но там сложно и накладные расходы на рантайм-рефлексию. А так - да, прекрасный мир сиподобных языков без перегрузки функций.

Это только доказывает тезис о том, что на Го практически невозможно делать элементарные обобщения. Нельзя делать обобщения -- нельзя компактно решать задачи. Больше кода-больше ошибок. Сложнее разработка\тестирование\поддержка и тд

Даже Nim на фоне Go смотрится в разы более продуманным

почему "даже"?

Потому что его велосипедили люди без поддержки одной из самых крупных корпораций

И смогли сделать более продуманный язык нежели Go

у Go цель другая

Какая?

Я сколько не читал про цель -- там одна вода и дешевый маркетинг

"чтобы каждый кто не осилили Си начал писать кучу кода"

"мы поставили крест на наработках в области ЯП за последние 40 лет"

Go напоминает велосипед с квадратным колесами

Это только доказывает тезис о том, что на Го практически невозможно делать элементарные обобщения. Нельзя делать обобщения -- нельзя компактно решать задачи. Больше кода-больше ошибок. Сложнее разработка\тестирование\поддержка и тд

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

Какая?

заставить сильно средних кодеров приносить чуток пользы

Си нужен для системных вещей. Go фиг пойми для чего

Это только доказывает тезис о том, что на Го практически невозможно делать элементарные обобщения. Нельзя делать обобщения -- нельзя компактно решать задачи. Больше кода-больше ошибок. Сложнее разработка\тестирование\поддержка и тд

Тут каждый тезис можно оспорить. Нельзя компактно решать задачи - ну и что. За количеством символов гонимся? Тогда си выиграет, там все можно в пару символов уместить. Больше кода - больше ошибок - ну да, поэтому лучше не программировать вообще чтобы не делать ошибок.

Си нужен для системных вещей. Go фиг пойми для чего

Docker недостаточно системный? Го - это про правило 80/20. 20% инструментов - делают 80% работы, так давайте выкидывать все из языка, чья польза сомнительна и экзотична, а вот выстрелить в ногу с помощью этого легко можешь. В итоге в го сейчас ОЧЕНЬ и ОЧЕНЬ тяжело стрелять себе в ноги, компилируется - значит работает.

Павел, читабельность крайне важна. Питон крайне читабельный и легкий в написани. Поэтому у него такая большая доля на рынке. На нем сложно делать ошибки именно благодаря этим качествам. Ошибки из-за типизации в рассчет не берем. Это явная проблема.

Павел, читабельность крайне важна. Питон крайне читабельный и легкий в написани. Поэтому у него такая большая доля на рынке. На нем сложно делать ошибки именно благодаря этим качествам. Ошибки из-за типизации в рассчет не берем. Это явная проблема.

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

В отличие от всяких языков, где поведение может быть неявно переопределено с помощью метапрограммирования и алиасов всяких.

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

Как по мне она крайне низкая по сравнению с тем же Питоном и Ди

Смотришь одно, а делает этот код совсем другое. А глде нибудь наверху там alias true = false. Вот это и называется нечитабельный код.

Питон по читабельности вообще вне конкуренции

Читабельность тоже вещь субъективная, вот я с питоном так и не подружился, он у меня какое-то отторжение вызывает)

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

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

Как по мне она крайне низкая по сравнению с тем же Питоном и Ди

Так что там низкого? Ты прочитав строчку в go не можешь себе интерпретировать что она делает?

Да и приколы Go типа: var x int8 :=1 или как оно там пишется уже обсуждали

короче, у каждого языка есть свои плюсы и минусы, чего тут спорить?)

Так что там низкого? Ты прочитав строчку в go не можешь себе интерпретировать что она делает?

Шарп и яву я понимаю, а Го с огромным трудом.

но каким бы кривым не был дизайн го, на нем прилят софт в неимоверных количествах, и это факт)

не думаю, что гугол ловит программистов по всему миру, сажает в карцер и дает ноутбук, чтобы те разрабатывали софт ради хайпа)

Питон по читабельности вообще вне конкуренции

Ну такое, динамическая типизация же - никогда не знаешь что прилетает тебе в функцию, ВНЕЗАПНО обнаруживаешь какие-нибудь поля, которые прицепили на объект где-то хуй знает где и для чего они.

Шарп и яву я понимаю, а Го с огромным трудом.

Ты скажи, что конкретно тебе не понятно в строчке var x int8 :=1 Ты можешь понять, x - это переменная или функция? Ты можешь понять, называется ли она x или foo? Ты можешь понять, имеет она в памяти размер 8 бит или 42? Ты можешь понять, ей по умолчанию присваивается значение 1 или 146?

Да и приколы Go типа: var x int8 :=1 или как оно там пишется уже обсуждали

Ну и каша. Нормальные люди пишут: var x int8 или var x = 1 или x := 1

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

я не могу понять нафига еще var лепить и почему тип функции после названия переменной указан

тут это же обсуждали -- вроде бы пришли к выводу, что больше на костыль похоже

var - чтобы ты понял что тут объявляется переменная

новая

тут это же обсуждали -- вроде бы пришли к выводу, что больше на костыль похоже

Не, пришли к тому, что с точки зрения читаемости и т.д. - это субъективно, а парсер у компилятора однозначно проще.

на много ли проще то? Да и странно делать все в угоду компилятору, а не программисту

Факт в том что go разработчики очень быстро вчитываются в код, это нельзя оспорить. Подтверждено тысячами хомячков.

В D код быстро вчитаться - невозможно. Если он не написан в стиле go.

вот честно, похоже на холивар плоские отвертки vs крестообразные

вот честно, похоже на холивар плоские отвертки vs крестообразные

Вообще да. Читаемость у го высокая именно за счет минимума механизмов, которые могут глобальное состояние как-то менять и явной типизации всех входов/выходов.

А уж кто где тип пишет - вкусовщина

В D код быстро вчитаться - невозможно. Если он не написан в стиле go.

на любом языке можно писать на фортране!

Ну такое, динамическая типизация же - никогда не знаешь что прилетает тебе в функцию, ВНЕЗАПНО обнаруживаешь какие-нибудь поля, которые прицепили на объект где-то хуй знает где и для чего они.

ну, код со статической типизацией тоже приходится тестировать/отлаживать.

ну, код со статической типизацией тоже приходится тестировать/отлаживать.

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

товарищи, я решил всех вас замучать дурацкими вопросами :) я сам не настоящий программист, так что извиняйте если что. принимаю в сокет байты, хочу распарсить пакет. у пакета есть основная структура (не меняющаяся), дальше идет опциональная часть с некоторым количеством TLV (type-length-value) которые идут друг за другом. как ранее в чатике подсказали - для постоянной части сделал через структуру + union с ubyte[]. с TLV уже так не получается. есть ли более красивый способ, чем через функцию в этой же структуре, которая будет один за одним разбирать TLV-шки? еще отягощает что внутри tlv могут быть еще tlv.

Очень забавно как Dmitry сам бесконечно задает вопросы типа "А вот я прочитал что в Ди есть леворекурсивное объявление функционального квази-шаблона на стеке с иммутабельностью всех ссылок на его подтипы, для чего это сделано и где полезно?" - и ему люди даже объяснить не могут что в 1% случаев бывают кейсы в которых шаблоны дают 0.05% ошибок и для исправления этой ситуации вот такое нагородили. А писал бы на го - уже бы давно программу написал, получил деньги и даже не задавался бы вопросами где что полезно и почему.

товарищи, я решил всех вас замучать дурацкими вопросами :) я сам не настоящий программист, так что извиняйте если что. принимаю в сокет байты, хочу распарсить пакет. у пакета есть основная структура (не меняющаяся), дальше идет опциональная часть с некоторым количеством TLV (type-length-value) которые идут друг за другом. как ранее в чатике подсказали - для постоянной части сделал через структуру + union с ubyte[]. с TLV уже так не получается. есть ли более красивый способ, чем через функцию в этой же структуре, которая будет один за одним разбирать TLV-шки? еще отягощает что внутри tlv могут быть еще tlv.

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

Прочитал тип - объявил структуру, дальше прочитал размер - выделил столько байтов буфер, потом туда прочитал остаток.

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

я вот просто как делал до этого. для каждого типа TLV создаю свою структуру. ну там тип в enum свой. и там конструктор, который на вход берет uint[] и из него копируются сначала тип и длина, потом аллоцируется память и заполняется value. прочитанные байты вырезаются. ну и в цикле пока байты не кончатся создаются объекты, складываются в массив. потом с ними и работаю. но почему то у меня стойкое ощущение что можно проще это сделать.

Да врядли

типа вот так (пример без union, написанный ранее) this( ubyte[] msg ) { this.code = msg.read!ubyte; this.identifier = msg.read!ubyte; this.length = msg.read!ushort; this.authentificator = msg[ 0..16 ]; msg = msg[ 16 .. msg.length ]; ushort cur_length = cast(ushort)( this.length - 20 ); while( cur_length >= 2 ) { writeln( msg ); ubyte cur_a = msg.read!ubyte; ubyte cur_l = msg.read!ubyte; ubyte[] cur_v = msg[ 0 .. cur_l-2 ]; msg = msg [ cur_l-2 .. msg.length ]; cur_length -= cur_l; auto a = parseAVP( cur_a, cur_v ); if( a !is null ) attributes ~= a; } }

он конеш кривой, поэтому и переписываю его. но вроде работает.

Вообще это теоретически можно как-то обобщить через темплейты и аннотации, но тебе это надо? )

ну вот я собираюсь с сетевыми штучками плотно заняться. а там постоянно tlv разные. где-то 1 байт тип, 2 байта длина. где-то 8 байтов тип, 1 байт длина. думаю хотя бы тимплейты заюзать какие-нить

То есть обходить все публичные свойства класса, у каждого определять тип и в соответствии с этим генерить код который в нужную переменную читаешь нужные байты из сокета. А если у переменной объявлена какая-то аннотация то парсер как-то по другому допустим парсит.

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

Например темплейт с двумя аргументами - первый длина типа, второй длина размера последующих данных

struct TLV( T, L ) { T type; L length; ubyte[] value; }

аля такой?

попробуем, спасибо)

да

ну вот я собираюсь с сетевыми штучками плотно заняться. а там постоянно tlv разные. где-то 1 байт тип, 2 байта длина. где-то 8 байтов тип, 1 байт длина. думаю хотя бы тимплейты заюзать какие-нить

в коде не хватает заморочек с ntoh и т.д.

ну, это дело такое. где-то network byte order, где-то нет) пока хочу норм парсить пакеты хотя бы.

я стараюсь как только принял пакет из сети превращать ubyte[] в immutable(ubyte)[], после чего не паришься с тем что где-то кто-то поменяет данные при обработке

Что за пьянка была?

всё как обычно)

Обычно я принимаю участие в дискуссии, но в этот раз я пролетел

Щас будем читать

И да, у тебя на мобилке менюшка не отображается - сделай лучше пикчей

что значит, не отображается?)

Стоит крестик вместо меню. Тофами называются, вроде

что за браузер?

Стандартный андройда версии 5.1

и скрин желательно, потому что всё равно не понимаю, о чем ты)

а, ясно, сама менюшка-то открывается?

Ага

поправлю)

В хроме еще некрасивое подчеркивание кликнутого пункта меню

run.dlang.io замени на что-нибудь внятное, типо "Открыть в онлайн IDE"