Pull to refresh
75
-1
Alexey Andreev @konsoletyper

Пользователь

Send message

Да! (ваш уровень аргументации мне нравится, что ж буду пользоваться тем же приемом)

А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.

Примеров конечно же не будет приведено в качестве аргумента?

  1. Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)

  2. Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)

  3. Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).

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

CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?

Писать логику на расте для браузера вместо джава скрипта это как благословение с небес

Эээ, нет.

Переиспользовать можно 95% одного и того же кода на всех платформах
сразу: браузер, мобила, сервер - это просто супер преимущество, тут
конечно больше спасибо расту, но тем не менее.

Это совсем не уникальное преимущество WASM или Rust.

Не сегодня-завтра всем понадобится запускать ИИ модели у себя в браузере
или на мобиле и производительность там играет решающее значение, wasm и
тут должен стать незаменим.

Эээ, я думал, ИИ-модели запускают на CUDA, при чём тут WebAssembly? Может, в данном случае лучше предусмотреть CUDA API или хотя бы OpenCL API для браузера?

Вот всегда в таких статьях "как мы покоряем просторы вселенной" говорится о больших фичах, но всегда не обращается внимание на то, что "есть нюанс". Например, GC они выпустили, ага. Только там почему-то дереференс nullptr приводит к trap-у, а не к исключению, что полностью противоречит поведению в подавляющем числе мейнстримных языков с управляемой кучей (JS, Java, C#, Python); аналогично с делением на ноль или с neg для -0x100000000. Или вот GC не поддерживается ни в одном известном мне безбраузерном движке. Или что до сих пор не выпустили никакого стандарта debug информации, а поддержка DWARF (где она есть) сырая просто до неюзабельности и вообще не вполне стандартизирована (я как автор компилятора в WASM лично сталкивался с тем, что wasmtime и chrome понимают DWARF по-разному). Ну и что DWARF идеологически никак не ложится на языки с GC. Или что ничего близко к "нативной производительности" в WebAssembly и не пахнет, что его "куча" спроектирована так, что любое обращение к памяти неминуемо обкладывается проверками на рантайме, и как авторы этих рантаймов героически пишут оптимизации, призванные количество этих проверок хоть как-то снизить.

Зато, о чудо, реализовали хвостовую рекурсию, всё многочисленное сообщество программистов на OCaml будет довольно этой новости.

B2 хватает, это факт. Другое дело - это скорость и нагрузка. По-русски я пишу быстрее и лучше, при этом прикладывая меньше усилий. И да, я "-тся" и "-ться" не путаю, "не" знаю когда писать раздельно или слитно, но вот те же артикли так и не осилил во всех нюансах.

В догонку вспомнился один случай - как-то про мой проект кто-то упомянул в комментариях к посту в hacker news. И несколько пользователей сразу пожаловались - а по документации проекта не понятно, как вообще начать его использовать. При том, что документация getting started была - как с помощью строчки в CLI создать пустой проект hello world. Естественно, в шаблоне я добавил комментариев, чтобы человек мог создать проект, посмотреть код и увидеть тут же объяснение. Но видимо, они не осилили скопировать текст в консоль, или просто не знали, что в IDEA есть поддержка архетипов в UI - и сразу сделали вывод.

Ещё момент: многие разработчики open source проектов попросту не являются native english speaker и писать документацию с условным B2 (а именно на нём часто люди застревают в плато, с которого в C1 непонятно как попасть, не посвящая вообще всё свободное время планомерному изучению - где же тогда взять время на кодинг) довольно-таки сложно и медленно. И, наконец, разработчику не всегда очевидно, что может вызвать затруднения у других.

Опишу свой опыт с другой стороны. Я вот поддерживаю свой компилятор Java/Kotlin/Scala в JavaScript. Какая-то документация есть. Но документация в стиле "вот так вы можете сгенерировать JS". При этом документация не раскрывает, например, следующие моменты:

  1. Как подключить JS к HTML-файлу (потому что это элементарная культура, про это вообще в интернете куча всего)

  2. Как завести gradle или Maven проект

  3. Как обеспечить копирование какого-то файлика в директории сборки в WAR-файл

  4. Как поднять HTTP-сервер и задеплоить в нём, например, WAR-файл

  5. Как работают те или иные JS API (например, тот же DOM) - есть только документация о том, как их вызывать из Java кода

  6. Как отлаживать JS в браузере

  7. Как настроить webpack и чем ES2015 modules отличаются от CommonJS

И вот не поверите, всё это у меня постоянно спрашивают пользователи, недовольные тем, что "у проекта нет документации". Когда я кому-то из них по какой-то причине всё-таки помогаю (т.е. по сути помогаю с ИХ проблемой, а не с пониманием, как пользоваться МОИМ компилятором), то угадайте, сколько таких несчастных в ответ написали хоть один туториал в репозиторий с документацией по проекту?

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

Что касается бинарников - обычно для всяких кросплатформенных сред с этим всё сильно лучше. И тут я вам открою страшную тайну: собрать дистрибутив на Rust или C++ под все платформы - это то ещё приключение (хотя бы в силу отсутствия того или иного железа в наличии у мейнтейнера). В случае той же Java это не проблема - собирай себе на любой машине и это запуститсяу кого угодно.

Open source проектами занимаются либо большие компании, которые получают непрямой доход от проекта (например, поддерживают ядро Linux, чтобы был софт для железа, которое они продают, или делают платное IDE для языка, компилятор которого опенсорс) - и тогда всё с документацией как правило нормально, потому что большая компания может позволить себе нанять на зарплату помимо армии разработчиков, ещё технических писателей, developer advocate и т.д; либо одиночки-энтузиасты, которым просто по кайфу запрограммировать что-то вечером после работы. Во втором случае странно призывать их писать документацию - они делают то, что им нравится, т.е. пишут код, решая некоторую техническую задачу.

Я за написание гайда для пользователей open-source проектов. Напомнить лишний раз про донаты не повредит

> Ну вот и как можно утверждать, что массивы в JVM реализованы через массивы C?

я этого не утверждал

Выше было

С другой стороны, Kotlin все равно реализован на сях (ИМХО), поэтому,
мне кажется что и переписывание памяти в динамических массивах там
должно быть аналогичными,

А так же

Где-то ж должно быть пересечение с системными вызовами
[Dos]Alloc/Realloc/Free, логично это делать через Це malloc/realloc/free
ну или делая вид, что их нет - через классы Це++. Вот оно и есть в
рантайме.

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

Ваши указатели и malloc - это тоже ручка. Есть только регистры и числа в них. Остальное - от лукавого. А вообще, я сейчас даже ещё более смелое утверждение выскажу: Жаба, как и C (ИМХО) написаны на Verilog.

Вот допустим, вам потребовался объект/массив на сколько-нибудь гигабайт
памяти, вы поюзали и бросили, и далее ждете реакции допустим
пользователя до потери пульса - что будет дальше? Отдаст java системе
гигабайты?

Нет, не отдаст. Это как раз отличная иллюстрация того, что JVM не использует никак рантайм C для работы с массивами. И, кстати, для таких вот целей аллокации гигантских массивах в Java есть всяческие offheap решения (взять хотя бы тот же ByteBuffer).

Небольшое уточнение. Какие там в Windows системные вызовы, никто не знает, всё вызывается через user-level DLL. Есть подозрение, что VirtualAlloc (а не LocalAlloc) реализован практически через прямой вызов в ядро, а вот всякие LocalAlloc/HeapAlloc - это по сути реализованый из коробки в dll аналог какого-нибудь jemalloc.

Где-то ж должно быть пересечение с системными вызовами [Dos]Alloc/Realloc/Free

Извините, вы про какие системные вызовы? В какой операционной системе? Если богомерзкой, то там LocalAlloc/LocalFree. Если в православной, то mmap. Но это не относится к языку C, это просто системные вызовы, которые можно вызывать откуда угодно. malloc/realloc/free - это уже часть стандарта C, но это уже shared libraries, которые линкуются (статически или динамически) и выполняются в user space. Внутри себя реализации malloc могут использовать системные вызовы для аллокации хипа в целом, но вряд ли вызывают их на каждый чих. И строго говоря, к массивам эти функции не имеют отношения.

JVM для объектов не использует ничего близко похожего на malloc, ибо управляемая куча принципиально иначе функционирует. И в управляемой куче, строго говоря, нет такой операции как free (даже GC внутри не "освобождает" память в хипе в том же смысле, в каком это делает free).

Массивы в Java принципиально иначе устроены. Начнём с того, что в C как таковых массивов-то и нет, есть просто арифметика указателей и синтаксический сахар, совмещающий арифметику указателей с дереференсом. В массивах Java есть длина, если полноценный vtable, ибо они тоже объекты и у них можно вызвать, например, toString или clone. При обращении к элементам массива индекс проверяется на выход за границы (если только не удалось доказать во время компиляции, что индекс не выходит), кидается исключение.

Ну вот и как можно утверждать, что массивы в JVM реализованы через массивы C? Не, ну в каком-то смысле можно так натянуть. В том, что данные массива так же расположены в памяти один за другим. Но это как утверждать, что человек - это такой же камень, потому что тоже состоит из атомов.

Компилятор Java написан, не поверите, на Java. JVM написана на C++, но там на C++ написан рантайм, интерпретатор и JIT. Внутри себя они, возможно, где-то и используют массивы C. При этом уже в Java массив не имеет ничего общего C++, не инстанциируется через него и вообще иначе реализован, иначе аллоцируется. При этом следующий уровень абстракции, ArrayList, написан на Java.

На Java и Kotlin. В частности, ArrayList для JVM BE просто алиасится в java.util.ArrayList, написанный на Java

Kotlin все равно реализован на сях (ИМХО)

Эээ, нет

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

Под постоянным, как я понял, имеется в виду O(1) (например, в отличие от связного списка с его O(n)). Это не отменяет наличия константы, которая так или иначе связана с особенностями оборудования. Иначе тогда и сортировку можно вместо O(N * log(N)) притянуть всякое . Кстати, кэш - не единственный источник тормозов. Может быть так же

  1. Страничная адресация. Кэш страниц в ЦП + всякие особенности управления страницами в ОС

  2. Банальное обновление памяти

Вот никогда не понимал этого. Я ещё понимаю, во всяких OCaml, где никаких циклов не заложено by design, там хвостовая рекурсия - это единственный способ писать оптимальный код. Но Kotlin - нормальный императивный язык, нет вообще ни одной причины тот код, который легко и читабельно представим циклами, переписывать в хвостовую рекурсию. Но вот взяли и потратили силы на то, чтобы это реализовать. Чтобы что? Поставить галочку напротив "ещё одна фича из функциональных языков"? Ради читабельности? Не думаю, что большинству разработчиков удобнее спарсить глазами того же Фибоначчи в "декларативном" стиле, чем через старый добрый цикл. Кроме того, часто такие элегантные математические определения из учебника не ложатся в хвостовую рекурсию и нужно их переписать, так что они уже не будут выглядеть такими же элегантными.

Вторая компания со схемы выше может в один прекрасный день заявить: «Мы
хотим поступать порядочно и оплачивать труд людей, работающих над
программами с открытым кодом». Но ээээ… куда именно им посылать деньги?
Понятия не имею

Не согласен с автором. По личному опыту народ не сильно торопится донатить. Вот я знаю, что моим проектом пользуется одна большая компания, которой какие-нибудь $50 в месяц вообще не проблема оформить. Я даже обращался к знакомым сотрудникам, говорили, что спросят у начальства. С закономерным итогом. А так, люди не стесняются приходить, спрашивать, что делать, если что-то у них не получается, оставлять issue, просить отревьюить их PR, объяснить, почему сложно реализовать ту или иную фичу - и такое ощущение, что и значок на github, и на сайте проекта, выпадает из их поля зрения. Чтобы набрать спонсоров, надо либо делать или что-то мегаполезное с огромной аудиторией, либо обладать не-инженерными навыками продвижения.

Ну а бывает, что WebAssembly медленнее. Я тут недавно баловался с бенчмаркингом своего JVM -> JS/WebAssembly транслятора и написал для него на Kotlin софтверный 3D. И вот почему-то WebAssembly вариант работает медленнее.

Думаю, там была проблема не техническая, а политическая. Авторы браузеров не хотели иметь какую-то стороннюю инородную штуковину, которая подключалась через небезопасный API. Авторы браузеров так же не хотели лицензировать Java у Sun/Oracle (чтобы включить эту инородную штуковину прямо в код бразура) и впадать в зависимость. WebAssembly - это что-то схожее, но изобретённое у них, так что нет, не повторит.

Information

Rating
Does not participate
Location
München, Bayern, Германия
Date of birth
Registered
Activity

Specialization

Specialist
Senior
From 6,000 €
Java
Compilers
Kotlin
Gradle