классная статья. рано или поздно будет форк компилятора, я думаю. потому что синтаксис прекрасный, минимальный из всех ML, без груза легаси фич. выкинуть бы оттуда ток завязку на package.elm-lang и всю эту магию package manager-а которой elm-make занимается помимо основной функции: превращать одни файлы в другие.

Я все удивляюсь почему до сих пор не форкнули.

После этой статьи часики затикали)

А что в твоём понимании легаси фичи? Тайпклассы?

Это не первая и даже не десятая такая статья)

Да полно такого было, это точно

Ну например много в Окамле и в Джаве в стандартной библиотеке очень давно было сделано криво и теперь приходится тащить это всё в депрекейтнутом виде из-за обратной совместимости.

Например, Раст и Свифт не поддерживают целые числа в качестве стринговых индексов, принимая во внимание, что мы живём уже давно не в мире ASCII, а в мире юникода.

https://doc.rust-lang.org/stable/book/ch08-02-strings.html

https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID534

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

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

Flutter сделал это с рендеринг пайплайном, Rust более-менее сделал это с системным программированием.

Посмотрите какого рода тупые баги (https://2ality.com/2013/10/typeof-null.html) приходится тащить буквально с 1й версии джаваскрипта.

Вот про такое легаси я веду речь.

Ну это то конечно да

Похоже до Эвана всё-таки статья дошла . Но наверно никаких изменений мы не увидим . Цель iOS https://twitter.com/czaplic/status/1248696174401458177?s=19

> Whether all kernel code lives in elm/* or not decides whether "all packages work" or not. It cannot be both ways.

Поскольку их нельзя публиковать на package.elm-lang этот аргумент не валиден. Все “пакеты” и так будут работать. Могут сломаться только приложения. Ну как сломаться, не будут компилиться под другую платформу.

А вообще, чтобы сделать нативные биндинги под iOs, нужны наверно миллионы человеко-часов. И там почти всюду API  на мутабельных объектах. Часто есть несколько разных API для одного и того же, разной степени свежести. И дока мягко говоря не самая приятная) Так что от команды, которая не может за 8 лет покрыть биндинги для веб, где всё открыто и разжёвано в спеках и не надо даже писать свой GC, сказки про iOS звучат неубедительно.

Даже на окамле пока проблемы с этими биндингами, хотя есть и компилятор в ARM и годный FFI.

Я сам пытался писать эти биндинги для окамла просто, поэтому представляю какой там треш. (При том, что окамл поддерживает и ООП и мутабельность).

Единственное, что приходит на ум, что они реализуют свой собственный рендеринг UI на OpenGL на манер флаттера. А все нативные API (аудио, базу данных и тд) заставят юзать через порты.

Там же есть проект с google summit или как его

Только забросили

Только зачем ещё один флаттер? Ради ml?
А нарисовать кучу контролов на канве, как во флаттер, требует не малых ресурсов.
Да и в свете SwiftUI это выглядит мало перспективным занятием.

React Native без этого работает

Angular и vue юзают native script для этого

Собственно если заменить в elm вызовы dom на вызовы react, то это заработает.

Есть костёльные демки с прикидыванием дерева https://thoughtbot.com/blog/elm-native-ui-in-production

Это не миллионы человекочасов. У нас react native в проде больше 3 лет. На 0.23 были терпимые косяки. 0.62 работает как часы.

Flutter 🤮 как минимум потому, что убивает все родные инструменты платформы.

Костёльные демки 😂👍

Исправлять не буду 😂