и где-то там выше по стеку кто-то знает, чо делать

например, идешь в базу читать объект по ключу, а таких нету, возвращаешь null-object

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

Я не говорю, что исключения - это фу, плохо. Тоже удобный механизм. Но они медленные (это правда проблема) и не очень гибкие - и это серьезные минусы.

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

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

А отсутствие записи в БД - это ошибка???

Я не говорю, что исключения - это фу, плохо. Тоже удобный механизм. Но они медленные (это правда проблема) и не очень гибкие - и это серьезные минусы.

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

и нету другого такого инструмента

всё остальное приходится обмазывать ифами-хуифами, а потом разбираться во всем этом хитросплетении

Ну такое...

При поиске записи в БД, имхо, нормально возвращать NullObject, а не исключение

Т.к. это просто не найдена запись

про что я и говорил)

БД же тебе не кидает исключение при поиске

А код, который кидает исключения при таких ситуациях, лично мне, не нравится.

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

всё остальное приходится обмазывать ифами-хуифами, а потом разбираться во всем этом хитросплетении

Ну в целом explicit is better than implicit частенько. Строить иерархию исключений, проверять функции на уровень гарантии исключения - тоже такое себе удобство.

Кто там хотел генерики в Gо? https://github.com/albrow/fo

пффффффф. Ну всё! Я пошел в Go)))

А стоп!

это ЯП отдельный

не Go

произошла типичная подмена понятий)

Кто там хотел генерики в Gо? https://github.com/albrow/fo

Там мрак

func curry2__int__int__int(f func(int, int) int) func(int) func(int) int { return func(p1 int) func(int) int { return func(p2 int) int { return f(p1, p2) } } }

Капец)))

Мне go чем-то напоминает советский автопром

Раз простой - легко починить на месте.

С помощью кувалды и изоленты.

это ЯП отдельный

Это суперсет, надстройка. Как С++ в молодости.

я не знаю что такое суперсет(

func curry2__int__int__int(f func(int, int) int) func(int) func(int) int { return func(p1 int) func(int) int { return func(p2 int) int { return f(p1, p2) } } }

В Ди шаблоны в такую же лапшу раскрываются, просто мы это не видим обычно.

как будет антоним к "подмножеству"?

любой код на Го это валидный код на Фо

В Ди шаблоны в такую же лапшу раскрываются, просто мы это не видим обычно.

Вот именно! Мы его не видем. А тут ЭТО ты видешь и если что-то не так, ты не получаешь бектрейс своего fo, а go

И тебе нужно разбераться уже в нем...

По идее, кроме как в бектрейсах тут тоже не должен видеть.

как будет антоним к "подмножеству"?

Надмножество видимо

любой код на Го это валидный код на Фо

а понял

Такое чувство будто сижу на канале по го, а не дланг)

Такое чувство будто сижу на канале по го, а не дланг)

Напиши админам, пусть переименуют

Да про дланг все и так понятно

В нем все хорошо, все инструменты есть. Надо просто сесть и закодить, а это самое трудное.

Кстати еще один вопрос хороший

Стоит ли делать микропакеты как JS или делать более крупные пакеты с подпакетами, примерно как в vibe.d

Я так понял что подпакеты это какая-то фишка dub и там все запутано

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

Народ, vibe.d умеет http/2 ?

Народ, vibe.d умеет http/2 ?

Нет

Есть ПР https://github.com/vibe-d/vibe.d/pull/1160 но не доделан видимо

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

И было бы ещё лучше общаться с nginx по fcgi или scgi)

Стоит ли делать микропакеты как JS или делать более крупные пакеты с подпакетами, примерно как в vibe.d

Фишка в том, что микропакеты JS'шные ставятся быстрее dub'ных

Хз почему так

Это терпимо, главное чтобы пакеты не влияли на размер/скорость итогового бинарника

Кстати, как в CT чекнуть, что аргумент темплейта - структура?

is(T==struct)

И было бы ещё лучше общаться с nginx по fcgi или scgi)

А смысл?

Я так понял что подпакеты это какая-то фишка dub и там все запутано

Снова про ГО, но... У них интересно сделано. Ты можешь ввиде зависимости поставить не только репозиторий, а конкретную папку

Что тоже интересно

И интересно, что нет централизованного стореджа пакетов

и у нас его нет, можно навернуть много разных

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

Позволяет вообще без проблем подключать внутри-фирмовые пакеты

DUB тоже позволяет

DUB тоже позволяет

Круто! Как?

А смысл?

протоколы проще, нет лишней мишуры

протоколы проще, нет лишней мишуры

Чем простой http?

ERROR: S client not available

конечно

Круто! Как?

add local

Как я понимаю в Раст главная фишка в том, что он позволяет гарантировать что потоки будут безопасными и без гонок. Вопрос а в Ди разве не так? У нас же есть тот же shared

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

Наверно ты прав

Кстати, а как правильно делать UDA?

Как я понимаю в Раст главная фишка в том, что он позволяет гарантировать что потоки будут безопасными и без гонок. Вопрос а в Ди разве не так? У нас же есть тот же shared

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

Если не пользоваться shared, а следовать заветам std.concurrency, то будет уже ближе к Расту: либо шлешь иммутабельные данные, либо копируешь, не разделяя.

Но остается __gshared как хак, который может все испортить.

А от утечек памяти Раст не очень-то защищает: там чуть что везде счетчики ссылок используются, и заиметь где-то лишний указатель, который будет счетчик ссылок держать ненулевым, совсем не сложно. И будет эта память висеть.

Снова про ГО, но... У них интересно сделано. Ты можешь ввиде зависимости поставить не только репозиторий, а конкретную папку

dub add-path, dub add-local

Если не пользоваться shared, а следовать заветам std.concurrency, то будет уже ближе к Расту: либо шлешь иммутабельные данные, либо копируешь, не разделяя.

Это к месседж-пассингу относится?

Ага, в чистом виде

dub add-path, dub add-local

Нужно будет попробовать

dub add-path, dub add-local

Нет, это совсем не то

Это ты должен локально склонить репу

Сам позаботиться о git pull во всех локальных репах ..

Если мы пишем File file = File(“test.txt”, «r») То указатель на файл будет расположен на стеке. Содержимое файла в куче. Вопрос. А что будет если добавить кейворд new? Что и где тогда будет расположено?

Если мы пишем File file = File(“test.txt”, «r») То указатель на файл будет расположен на стеке. Содержимое файла в куче. Вопрос. А что будет если добавить кейворд new? Что и где тогда будет расположено?

Структура в кучу уйдет вроде и все.

Если мы пишем File file = File(“test.txt”, «r») То указатель на файл будет расположен на стеке. Содержимое файла в куче. Вопрос. А что будет если добавить кейворд new? Что и где тогда будет расположено?

Содержимое файла может быть где угодно. Открывая файл мы не читаем его по умолчанию.

Если ты прочитаешь его и запишешь в куче, то в куче

Если мы пишем File file = File(“test.txt”, «r») То указатель на файл будет расположен на стеке. Содержимое файла в куче. Вопрос. А что будет если добавить кейворд new? Что и где тогда будет расположено?

С new в куче разместит

Если мы пишем File file = File(“test.txt”, «r») То указатель на файл будет расположен на стеке. Содержимое файла в куче. Вопрос. А что будет если добавить кейворд new? Что и где тогда будет расположено?

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

Кстати, а как правильно делать UDA?

Не понятна суть вопроса.

Кстати, а как правильно делать UDA?

https://dlang.org/phobos/std_traits.html hasUDA, getUDAs

Не понятна суть вопроса.

Как правильно создавать UDA, что бы можно было его отличить.

Как правильно создавать UDA, что бы можно было его отличить.

На сколько я понимаю, UDA не создается. UDA - это способ вызова функции, а не ее описание

void test(int g){ int y = g;} 11.test(); // UDA test(11); // default calls

На сколько я понимаю, UDA не создается. UDA - это способ вызова функции, а не ее описание

UDA это же вроде атрибуты?

UDA это же вроде атрибуты?

Блин

которые @Test

UDA это же вроде атрибуты?

Да, User Defined Attributes