Там в основном маленькие пакетики, так что их легко мейнтейнить

которые +/- стабильны и работают как часы?

Например есть fasthttp - маленькая штуковина которая позволяет парсить http запросы очень быстро. И все.

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

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

вот странно...

у меня сложилось впечатление, что в сообществе Go просто не принято обращать внимание на баги)

в общем, странная ситуация

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

Но главное что есть некоторый product value, "эйдос", философски выражаясь, который позволяет программистам-пользователям решать свои задачи максимально просто и быстро.

да нормально все с vibe,d

косяки есть

но оказался не такой быстрый как хотелось бы

таки он не в глубокой разработке

Но главное что есть некоторый product value, "эйдос", философски выражаясь, который позволяет программистам-пользователям решать свои задачи максимально просто и быстро.

эйдос напрямую завязан на количество пользователей языка)

в расте вообще нормального веб-фреймворка нет

главное, что вайбд быстро развивается

тот же tcell — это отдаленный аналог ncurses, написанный практически на чистом Go, и пилят его минимум 13 человек)

в Go ща жопа как в JavaScript

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

как-то так

Раст - это жестоко. Вы постоянно боретесь с компилятором

Фу раст

мне кажется, раст — это предельная крайность шкалы [борьба с компилятором ... борьба с багами в рантайме]

не уверен

где-то, наверное, это нужно)

мне кажется, раст — это предельная крайность шкалы [борьба с компилятором ... борьба с багами в рантайме]

А где С в этой шкале?)

ближе к борьбе с багами в рантайме)

где-то справа от

ну, как бы, вполне понятно: чем больше прав, тем больше ответственности, можешь все кастовать к void*, будь добр отвечать за свои поступки)

В D слишком много понаворотили

нужны были плюсы с человеческим синтаксисом - и все

например?

например миллион аттрибутов

странноватые массивы

SFINAE, который в D нахер не нужен

нужны были плюсы с человеческим синтаксисом - и все

Кстати, возможно, такой подход и не дает равиться шумихе вокруг языка. Можно даже «слоганы» сравнить: «Go — охрененный язык для асинхронной разработки», «Rust — охрененный язык для безопасной разработки», «D — типа С++, но местами лучше».

да нет, просто D не продвигается крупными компаниями

за всеми этими Go, Rust стоят большие конторы, на которые молятся мульены

стоит какому-нибудь Google взять D под крылышко, как оно наверняка взлетит аки ракета

странноватые массивы

чего в них странного?

например миллион аттрибутов

половиной из которых можно не пользоваться

SFINAE, который в D нахер не нужен

эт почему?

чего в них странного?

Если не знать кишки можно столкнуться с WAT.

эт почему?

А зачем он нужен если есть template constraints?

половиной из которых можно не пользоваться

Да, но если ты задействовал либу в которой автор любит ими пользоваться, высок риск огрести серьезных проблем. Я например не могу апгрейдить без серьезных переделок с vibe.d 0.7.x на 0.8.x имменно поэтому.

SFINAE затрудняет поиск ошибок, а иногда провоцирует труднонаходимые ошибки

Если не знать кишки можно столкнуться с WAT.

WAT есть что?

SFINAE затрудняет поиск ошибок, а иногда провоцирует труднонаходимые ошибки

а есть другой подход?

это вот про template constaints?

template constraints это ограничение сигнатуры? типа int foo(T : float)(T a)

так ведь вместе с SFINAE это как раз работает удобно?

WAT есть что?

https://www.destroyallsoftware.com/talks/wat

template constraints это ограничение сигнатуры? типа int foo(T : float)(T a)

да но не обязательно, еще есть int foo(T)(T a) if(isNumber!T) {...

так ведь вместе с SFINAE это как раз работает удобно?

SFINAE тут явно лишний

а есть другой подход?

есть, выкинуть SFINAE нафиг

да но не обязательно, еще есть int foo(T)(T a) if(isNumber!T) {...

не знаю в чём различие механизма ограничения между int foo(T : float)(T a); и int foo(T)(T a) if (is(T : float));

в данном случае нет, просто у if гораздо больше возможностей

SFINAE подразумевает, что именно при ошибке во время инстанцирования ищется другая подходящая?

в данном случае нет, просто у if гораздо больше возможностей

это то понятно

например нельзя написать int foo(T = float)(T a) зато можно int foo(T)(T a) if(is(T == float))

SFINAE подразумевает, что именно при ошибке во время инстанцирования ищется другая подходящая?

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

например нельзя написать int foo(T = float)(T a) зато можно int foo(T)(T a) if(is(T == float))

нет, можно

просто в исполнении int foo(T=float)(T a); меньше механизмов можно задействовать

но не соль... эт я просто для ясности

хе, действительно можно

в доках нет

или я немного отстал от жизни

ERROR: S client not available

int foo(T:X[V], V, X:float)(T a) даже вот так можно

по всей видимости допустимы все выражения, которые допустимы в is

но это не точно

не, я попутал

== нельзя

= вообще непонятно что значит

а не, понятно

= - это по умолчанию

совсем другая песня

int foo(T = float)(T a) совсем не эквивалент int foo(T)(T a) if(is(T == float))

да, кстати

я имел ввиду, что нельзя писать int foo(T == float)(T a)

ты меня сбил с толку :)

а имеет смысл такая запись?

имеет

можно написать int foo()(float a); и будет тоже самое

если я хочу чтобы мой шаблон работал исключительно для флоатов

нет не тоже самое

в чём разница?

шаблоная функция будет работать только с flaot

да, только с флоат

а обычная и с int

а

типа точное соответствие без неявного приведения?

фактически запрет на неявную конвертацию

ну да

двоеточие также работает

любой тип, который можно неявно привести

а == - это точное соответствие

окей, тут согласен

Но насчёт массивов пока все равно не понял

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