ЯП V

https://vlang.io/compare
Обнаружил язык программирования V. Конечно же первым делом читаю что это
и зачем ещё один изобрели? Потому что всякие приятные плюшки разрознены:

* Быстрая сборка: D, Go, Delphi
* Простота и поддерживаемость: Go
* Нулевая стоимость общения с Си: C, C++, D, Delphi, Rust
* Безопасность (immutability, no null, free from data races): Rust
* Простая конкурентная работа: Go
* Простое кросс-компилирование: Go
* Compile time code generation: D
* Маленький компилятор без зависимостей: нема
* Отсутствие глобального состояния: нема

Мне нравится что к Go тут автор относятся адекватно и именно его
причисляют к простым и поддерживаемым языкам, где ещё и с конкурентной
работой всё отлично. Нравится что про Rust мало чего в другом абзаце
сказано, кроме подчёркивания что он сложный (а что может быть хуже
сложности?). Плюс медленный -- а это реально прям сильное против.

Говорят, что V похож на Go -- если знаешь Go, то 80% V тебе уже
известно. Но есть и отличия от него, читаю их первый раз, ничего не зная
больше про язык:

* No err != nil checks (replaced by result types)
  Ох, не то чтобы я сильно против, но всё же против.
  Мне нравится err != nil, дисциплинирует, делает явное явным
* No undefined values
  Вот в Си меня бесит что штатно значение переменной -- просто реально
  не определено. В Go же значение просто нулевое всегда. Вроде с этим
  особо проблем не встречал
* No variable shadowing
  Это наверное скорее, действительно, хорошо. Я сколько лет пишу на Go,
  но приходится аккуратно задумываться о том, не затенил ли я переменную.
  Время от времени всплывают ошибки из-за этого
* Immutability by default
  Фиг знает что это
* Enums
  Ну а iota то с "type X int" чем не угодила?
* Sum types (type Expr = IfExpr | StringLiteral | IntLiteral | ...)
  Фиг знает что это
* String interpolation: println('${foo}: ${bar.baz}')
  Объективных причин почему мне это не нравится не назову, но воротит от
  подобного. Одно дело это в shell/Perl/Tcl использовать, но там
  типизации как бы нет никакой. Знаю что коллеги любят подобные f""
  конструкции в Python, но я неустанно блюю от них, принципиально
  одобряя только форматирование через %-оператор
* If and match expressions (including sum type matches)
  Фиг знает что это
* No global state
  Сильно против. Это какой-то бездумный культ быть против этого. Как и
  культ неприемлемости goto например. Да, бывают примеры когда global
  state приносит много вреда в библиотеках, не без этого, но не надо на
  пустом месте заставлять меня в *простой* программе избавляться от него
* A simple way to check whether an array contains an element: if elem in arr
  А как именно этот in будет реализован? Как метод, как в Python? Вот
  что мне понравилось в Go и Си, так это то, что приходится задумываться
  об эффективности алгоритмов и где-то абсолютно нормально делать просто
  итерирование линейное, а где-то уже надо городить более сложные
  структуры данных. Python это не про производительность -- там поэтому
  нормально с глаз долой всё это спрятать. Кроме того, ведь в Go никто
  не мешает в функцию вынести желаемый алгоритм поиска/проверки. Вот
  напрягает меня их "simple way"
* Only one declaration style: a := 0
  Это одобряю. Пофиг что: var или :=, но когда нет чёткого ответа когда
  и что лучше использовать, то мне это не нравится
* Warnings for unused imports and vars for quicker development without
  annoying interruptions. But only in development/debugging mode. Making
  a production build still requires fixing all of them, thus enforcing
  clean code.
  Да, было бы полезно, Go многих бесит свои поведением в этом плане.
* Much smaller runtime
* Much smaller binaries
  Это всё плохо быть не может конечно. Хотя чаще всего это многих и не волнует
* Zero cost C interop
  С одной стороны хорошо. С другой -- будет мотивировать
  переиспользовать Си-программы. Что тоже и не плохо, но как бы это не
  превратилось в современный Python, где что ни библиотека, так является
  обвязкой над Си
* GC is optional
* Much faster serialization using codegen and no runtime reflection
  Ну codegen и в Go не запрещают. Это уже вопрос к конкретным
  библиотекам используют ли они reflection или нет
* Precompiled text and HTML templates unlike Go's html/templates that
  have to be parsed on every request
  Это вопрос исключительно к библиотекам.
* Fearless concurrency (no data race guarantee at compilation) wip
  wip... понятно
* No null (null is only allowed in unsafe code)
  Так и не понимаю что в нём плохого, если к месту используется
* Stricter vfmt to ensure one coding style
  Это всегда хорошо.
* Centralized package manager: vpm.vlang.io (v install ...)
  Не смотрел, но уверен что лютейшее новомодное хипстерское говно,
  неприемлемое с моей точки зрения. Задолбали всеми этими
  централизованными решениями! В Go по умолчанию тоже есть их прокси
  через который получаются пакеты и сравниваются их отпечатки, но это
  переменной окружения отключается глобально. Вообще в плане пакетов я
  ничего лучше чем в Go не видел, хотя я и не сказать что много чего
  трогал. Но никакой привязки к централизованным сервисам или
  специализированного софта для пакетов не нужно -- так держать. Плюс
  жёсткая привязка к коду, с криптографическими хэшами
* Much simpler and less verbose testing, assert.
* Primitive types can have methods resulting in less verbose code:
  strings.Replace(strings.Replace(s, "a", "A", -1), "b", "B", -1) =>
  s.replace('a', 'A').replace('b', 'B')
  После Python было чуть-чуть непривычно, но к этому привыкаешь
  моментально, ведь в Lua вроде бы аналогично многое было. Вообще мелочь
* Arrays and maps (and arrays of arrays, arrays of maps etc) are
  automatically allocated. No more nil reference panics if you forgot to
  allocate each map in a loop.
  Вот как будто это какая-то большая проблема была. Ну да, будет
  несколько строчек кода лишних в Go

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

Ладно, just out of interest, попробую собрать, ведь это та ещё проблема
с языками стала. Молодцы что один из Makefile обозвали GNUmakefile.
Предлагают просто сделать make. Что вижу?
    git clone --filter=blob:none --quiet --branch thirdparty-freebsd-amd64
        https://github.com/vlang/tccbin ./thirdparty/tcc
и запуск скачанного бинарника. Какой вердикт? На хуй идёт!
Под виртуалкой поднятой (просто так совпало что была запущенная под
рукой) разрешил ему делать это всё непотребство, так оно всё равно не
собирается: builder error: 'gc_pthread_redirects.h' not found