Alexey Andreev
@konsoletyper
Пользователь
Information
- Rating
- Does not participate
- Location
- München, Bayern, Германия
- Date of birth
- Registered
- Activity
Specialization
Specialist
Senior
From 6,000 €
Java
Compilers
Kotlin
Gradle
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?
Эээ, нет.
Это совсем не уникальное преимущество WASM или Rust.
Эээ, я думал, ИИ-модели запускают на 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". При этом документация не раскрывает, например, следующие моменты:
Как подключить JS к HTML-файлу (потому что это элементарная культура, про это вообще в интернете куча всего)
Как завести gradle или Maven проект
Как обеспечить копирование какого-то файлика в директории сборки в WAR-файл
Как поднять HTTP-сервер и задеплоить в нём, например, WAR-файл
Как работают те или иные JS API (например, тот же DOM) - есть только документация о том, как их вызывать из Java кода
Как отлаживать JS в браузере
Как настроить webpack и чем ES2015 modules отличаются от CommonJS
И вот не поверите, всё это у меня постоянно спрашивают пользователи, недовольные тем, что "у проекта нет документации". Когда я кому-то из них по какой-то причине всё-таки помогаю (т.е. по сути помогаю с ИХ проблемой, а не с пониманием, как пользоваться МОИМ компилятором), то угадайте, сколько таких несчастных в ответ написали хоть один туториал в репозиторий с документацией по проекту?
Ещё часто пользователи просто не могут глазами спарсить сообщение об ошибке, где им чёрным по белому расписано, почему что-то не работает. При этом есть ещё небольшая прослойка адекватных пользователей, которым, как оказывается, документация вообще не нужна, потому что они давно склонировали репозиторий и нашли в нём папку samples, где уже есть готовые примеры - изучай нехочу, да папку tests, где, не поверите, лежат тесты, которые являются по совместительству ещё и примерами использования проекта.
Что касается бинарников - обычно для всяких кросплатформенных сред с этим всё сильно лучше. И тут я вам открою страшную тайну: собрать дистрибутив на Rust или C++ под все платформы - это то ещё приключение (хотя бы в силу отсутствия того или иного железа в наличии у мейнтейнера). В случае той же Java это не проблема - собирай себе на любой машине и это запуститсяу кого угодно.
Open source проектами занимаются либо большие компании, которые получают непрямой доход от проекта (например, поддерживают ядро Linux, чтобы был софт для железа, которое они продают, или делают платное IDE для языка, компилятор которого опенсорс) - и тогда всё с документацией как правило нормально, потому что большая компания может позволить себе нанять на зарплату помимо армии разработчиков, ещё технических писателей, developer advocate и т.д; либо одиночки-энтузиасты, которым просто по кайфу запрограммировать что-то вечером после работы. Во втором случае странно призывать их писать документацию - они делают то, что им нравится, т.е. пишут код, решая некоторую техническую задачу.
Я за написание гайда для пользователей open-source проектов. Напомнить лишний раз про донаты не повредит
Выше было
А так же
Ваши указатели и malloc - это тоже ручка. Есть только регистры и числа в них. Остальное - от лукавого. А вообще, я сейчас даже ещё более смелое утверждение выскажу: Жаба, как и C (ИМХО) написаны на Verilog.
Нет, не отдаст. Это как раз отличная иллюстрация того, что JVM не использует никак рантайм C для работы с массивами. И, кстати, для таких вот целей аллокации гигантских массивах в Java есть всяческие offheap решения (взять хотя бы тот же ByteBuffer).
Небольшое уточнение. Какие там в Windows системные вызовы, никто не знает, всё вызывается через user-level DLL. Есть подозрение, что VirtualAlloc (а не LocalAlloc) реализован практически через прямой вызов в ядро, а вот всякие LocalAlloc/HeapAlloc - это по сути реализованый из коробки в dll аналог какого-нибудь jemalloc.
Извините, вы про какие системные вызовы? В какой операционной системе? Если богомерзкой, то там 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Эээ, нет
Под постоянным, как я понял, имеется в виду O(1) (например, в отличие от связного списка с его O(n)). Это не отменяет наличия константы, которая так или иначе связана с особенностями оборудования. Иначе тогда и сортировку можно вместо O(N * log(N)) притянуть всякое . Кстати, кэш - не единственный источник тормозов. Может быть так же
Страничная адресация. Кэш страниц в ЦП + всякие особенности управления страницами в ОС
Банальное обновление памяти
Вот никогда не понимал этого. Я ещё понимаю, во всяких OCaml, где никаких циклов не заложено by design, там хвостовая рекурсия - это единственный способ писать оптимальный код. Но Kotlin - нормальный императивный язык, нет вообще ни одной причины тот код, который легко и читабельно представим циклами, переписывать в хвостовую рекурсию. Но вот взяли и потратили силы на то, чтобы это реализовать. Чтобы что? Поставить галочку напротив "ещё одна фича из функциональных языков"? Ради читабельности? Не думаю, что большинству разработчиков удобнее спарсить глазами того же Фибоначчи в "декларативном" стиле, чем через старый добрый цикл. Кроме того, часто такие элегантные математические определения из учебника не ложатся в хвостовую рекурсию и нужно их переписать, так что они уже не будут выглядеть такими же элегантными.
Не согласен с автором. По личному опыту народ не сильно торопится донатить. Вот я знаю, что моим проектом пользуется одна большая компания, которой какие-нибудь $50 в месяц вообще не проблема оформить. Я даже обращался к знакомым сотрудникам, говорили, что спросят у начальства. С закономерным итогом. А так, люди не стесняются приходить, спрашивать, что делать, если что-то у них не получается, оставлять issue, просить отревьюить их PR, объяснить, почему сложно реализовать ту или иную фичу - и такое ощущение, что и значок на github, и на сайте проекта, выпадает из их поля зрения. Чтобы набрать спонсоров, надо либо делать или что-то мегаполезное с огромной аудиторией, либо обладать не-инженерными навыками продвижения.
Ну а бывает, что WebAssembly медленнее. Я тут недавно баловался с бенчмаркингом своего JVM -> JS/WebAssembly транслятора и написал для него на Kotlin софтверный 3D. И вот почему-то WebAssembly вариант работает медленнее.
В стандарте я не смог найти
Думаю, там была проблема не техническая, а политическая. Авторы браузеров не хотели иметь какую-то стороннюю инородную штуковину, которая подключалась через небезопасный API. Авторы браузеров так же не хотели лицензировать Java у Sun/Oracle (чтобы включить эту инородную штуковину прямо в код бразура) и впадать в зависимость. WebAssembly - это что-то схожее, но изобретённое у них, так что нет, не повторит.