Полный аналог do-синтаксиса хаскеля в F# — computational expressions. Они даже несколько шире, т.к. позволяют вручную определять семантику (возможно, то же можно делать в Haskell).
Тот же пример из слайдов мог бы выглядеть как
Именно так у нас в проекте и сделано) Вот тут реализация, кому интересно: Result
Да. По сути, он будет отличаться от кода, изображённого на второй только операцией композиции)
Просто сейчас в рабочем проекте такую технику используем, по сравнению с исключениями это просто рай
Сначала я тоже был раздосадован этим моментом. В реальных случаях можно определить функцию MapError и передавать ей декоратор ошибки, пришедшей «снизу». Код при этом остаётся монадическим, а ошибки начинают не только пробрасываться, но и получают человекопонятное пояснение.
Что-же до функций validateRequest, canonicalizeEmail и т.д. — если их клеить не с помощью >> а с помощью FlatMap, то они смогут возвращать такие же человекопонятные ошибки, как и императивный код)
Такие споры давно уже пора закончить тезисом «лучше то, что удобнее использовать конкретному человеку». Кому-то просто физически нужны средства для построения более высоких абстракций, кто-то любит обходится более простыми инструментами. Крики «СЛОООЖНА» не менее смешны, чем «отстой, застрявший в каменном веке».
Как показывает мой опыт, функциональные языки дают больше возможностей для того, чтобы сделать проект в одиночку или небольшой командой, чем «проще» язык, тем в больших командах он находит применение, как-то так.
Многие говорят, правда, что при разработке на более «сложном» языке понадобится меньше программистов) Но мне тут трудно судить.
В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности
Всю жизнь косячили с отрицательными индексами, а теперь диктуют всем что это опасно, приводит к багам и НИНУЖНО
И это всё я пишу лишь к тому, что авторитет, каким бы он не был, это для разумного человека ещё не довод принимать мнение этого авторитета без аргументов.
Данный комментарий — гипетрофированный пример альтернативной точки зрения, но к минусам я готов.
50+ лет
создание UNIX
Ну да, наигрались с адресной арифметикой и решили запилить чего по-безопаснее, а вот посмотреть, что вокруг появилось — не хотели или забыли? Лямбды? Ну это в 80-е тупило, ну и сейчас тупит, да и всю жизнь без этого пишем, ненужно. Почему в Rust смогли сделать и удобно и быстро, а в Go — нет? Новички, говорите, не осилят? А может, их тогда вообще рановато до продакшена допускать? Технология для инженеров не должна ориентироваться на дебилов.
В общем это… Может быть, авторам на пенсию пора?
Обсуждаемая выше проблема — чистой воды теоретизирование
Как будто это делает решение поместить в комментарии инструкции для кодогенератора или «внутренности компилятора и рантайма» long-term хорошим решением.
Об этом я даже не подумал :)
В первую очередь меня смущает то, что может найтись чудак (особенно учитывая целевую аудиторию Go — тех, кого нужно «научить по-быстрому»), который напишет вот так:
//Hey! Look at my awesome function Blabla
//go:generate toolname -params -blabla
//Lorem ipsum dolor sit amet, consectetur adipiscing elit.
//Donec tortor erat, rhoncus ac turpis id, ullamcorper congue odio
func Blabla() {
// code...
}
Ну прямо ОЧЕНЬ заметно, что тут аннотация в комментариях. В общем, в других языках, которые тоже компетентные люди проектируют, такие вещи выделяют в отдельные сущности, Пайк же посчитал, что это СЛОЖНО. Ну ок, я его понял, но по-моему технология для инженеров не должна ориентироваться на дебилов…
Тем, что он
— не выглядит как комментарий
— обрабатывается не как комментарий
Аннотация явно говорит «тут делаются разные дела»
В случае комментария может быть так:
//go:generate toolname -params -blabla
//Hey! Look at my awesome function Blabla
//Lorem ipsum dolor sit amet, consectetur adipiscing elit.
//Donec tortor erat, rhoncus ac turpis id, ullamcorper congue odio
func Blabla() {
// code...
}
Нет, не криминал, но занятие тоже очень «почётное»
P.S. И кто-то очень быстро стал «Full-stack developer»
Забавно читать это в коменте человека, занимающегося парсингом сайтов)
Именно так у нас в проекте и сделано) Вот тут реализация, кому интересно: Result
Просто сейчас в рабочем проекте такую технику используем, по сравнению с исключениями это просто рай
Что-же до функций validateRequest, canonicalizeEmail и т.д. — если их клеить не с помощью >> а с помощью FlatMap, то они смогут возвращать такие же человекопонятные ошибки, как и императивный код)
Как показывает мой опыт, функциональные языки дают больше возможностей для того, чтобы сделать проект в одиночку или небольшой командой, чем «проще» язык, тем в больших командах он находит применение, как-то так.
Многие говорят, правда, что при разработке на более «сложном» языке понадобится меньше программистов) Но мне тут трудно судить.
Присоединяюсь! Таким, как эта статья, хотелось бы видеть каждое краткое введение в язык.
Сдаётся мне, там далеко не только из-за статьи школьника проблемы
Всю жизнь косячили с отрицательными индексами, а теперь диктуют всем что это опасно, приводит к багам и НИНУЖНО
И это всё я пишу лишь к тому, что авторитет, каким бы он не был, это для разумного человека ещё не довод принимать мнение этого авторитета без аргументов.
Ну да, наигрались с адресной арифметикой и решили запилить чего по-безопаснее, а вот посмотреть, что вокруг появилось — не хотели или забыли? Лямбды? Ну это в 80-е тупило, ну и сейчас тупит, да и всю жизнь без этого пишем, ненужно. Почему в Rust смогли сделать и удобно и быстро, а в Go — нет? Новички, говорите, не осилят? А может, их тогда вообще рановато до продакшена допускать? Технология для инженеров не должна ориентироваться на дебилов.
В общем это… Может быть, авторам на пенсию пора?
Как будто это делает решение поместить в комментарии инструкции для кодогенератора или «внутренности компилятора и рантайма» long-term хорошим решением.
//go:nosplit пойдёт в godoc
Это норма, да?
а есть вот такой
из комментариев второго типа генерируется документация, из комментариев первого — нет
В первую очередь меня смущает то, что может найтись чудак (особенно учитывая целевую аудиторию Go — тех, кого нужно «научить по-быстрому»), который напишет вот так:
Ну прямо ОЧЕНЬ заметно, что тут аннотация в комментариях. В общем, в других языках, которые тоже компетентные люди проектируют, такие вещи выделяют в отдельные сущности, Пайк же посчитал, что это СЛОЖНО. Ну ок, я его понял, но по-моему технология для инженеров не должна ориентироваться на дебилов…
— не выглядит как комментарий
— обрабатывается не как комментарий
Аннотация явно говорит «тут делаются разные дела»
В случае комментария может быть так: