было бы круто если бы WASM завезли не на js, а полноценно, чтобы можно было кодить на java) и не трогать js

что такое WSM? или WASM?

да

очепятка

слишком разные языки что бы java в js колбасить

да в какой js

хотя jb смогли же kotlin подтянуть

wasm это не js

но работает поверх js пока что

wasm это не js

мы про одно и то же? webassembly?

да, webassembly

WebAssembly — эффективный низкоуровневый байт-код, предназначенный для исполнения в браузере.

это не js

wasm это не js

js компилится в wasm

ты путаешь

что путаю?

как js может компилится в wasm, если wasm работает поверх js

не, в браузерах впиливается поддержка wasm как бинарного формата для веба, а js компилится в него

конечно, это сделать можно, но сейчас бессмысленно

когда завезут вот тогда огонь

это понятно что в мире браузерный зоопарк

js компилится в wasm

Разве? В WASM компилятся нативные языки, но никак не JS.

Разве? В WASM компилятся нативные языки, но никак не JS.

вроде да, так

SVM наверное когда-нибудль сможет конпелять в WASM (но сейчас он не может компилять даже в Windows :)

Разве? В WASM компилятся нативные языки, но никак не JS.

не только, подразумевается, что в wasm можно будет компилить любой язык и даже реализовывать на нём целые рантаймы, рождая при это до селе невиданых чудищ и мутантов. мс, например. уже начали свеого франкештейна делать https://github.com/aspnet/Blazor

поэтому я и глаголю мутить сразу на java

в wasm компилить и всё

поэтому я и глаголю мутить сразу на java

жава в браузере? тебя фронтёры заживо съедят, никто не будет на ней писать, после всяких флоу и тс, да даже после жс. слишком топорно, скажем так

wasm же

он решит все проблемы

будет ровно такой же выхлоп как после js

скомпиленного в wasm

чем это хуже?

он решит все проблемы

ну только если загнать людей не с фронта в браузер то да, как англуяр в своё время

ват?

ват?

ну зачем тебе жава в васм?

потому что мне нравится java и гораздо удобнее js'a

особенно я не терплю яп где нет статической типизации

поэтому я и глаголю мутить сразу на java

Проходили уже GWT

это жесть просто

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

потому что мне нравится java и гораздо удобнее js'a

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

но отсутсвие статической типизации это я понять не могу

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

я про то, что если у тебя всё под одим байткодом

ты можешь писать под любые либы

без каких-либо проблем

ты про kotlin, scala, groovy не слышал что ли?

но отсутсвие статической типизации это я понять не могу

Kotlin/JS и TypeScript же есть

Kotlin/JS и TypeScript же есть

https://habr.com/company/oleg-bunin/blog/417459/

смотри видосик под конец

но отсутсвие статической типизации это я понять не могу

дело вкуса и задачи. лисп, питон, эрлаг... как- то же живут и при этом довольно хорошо

там про typescript

дело вкуса и задачи. лисп, питон, эрлаг... как- то же живут и при этом довольно хорошо

ну живут и страдают

смотри видосик под конец

А если в двух словах без видосика?

там нет статической типизации

ну живут и страдают

не страдаем.

несмотря на то, что она вроде бы "есть"

И что?

И что?

не влезай в разговор если не знаешь о чём он

не страдаем.

Ладно, расскажи мне о прелестях работы под js

какие самые частые ошибки у вас случаются?

Ой, уж лучше на JS писать, чем с такой системой типов как в Java

Ладно, расскажи мне о прелестях работы под js

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

не влезай в разговор если не знаешь о чём он

И о чём же он? Ты уже определись, что тебе нужно. Статическую типизацию в исходниках или производительность

И о чём же он? Ты уже определись, что тебе нужно. Статическую типизацию в исходниках или производительность

я про то, что ты несёшь чушь, я говорю про статическую типизацию вообще со всеми минусами и плюсами

ну живут и страдают

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

и про производительность, я ещё не слова не сказал

и про производительность, я ещё не слова не сказал

ну да, она выше (если про ноду на нио задачах), чем у жвм такие дела.

ERROR: S client not available

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

проблема в том, что js доминирует на этом поле

ничего против них не имею если у меня есть выбор и свобода

а тут этого нет

кодь на js и всё тут

хоть убейся

а, пагодь ты про фронт ща?

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

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

и про производительность, я ещё не слова не сказал

Тогда при чём тут JIT?

ещё раз повторяю я скинул то, как устроен js под капотом

JS заставляет писать продуманный код. Любой непродуманный код в JS мгновенно превращается в ад адский. Это плохо!

не знать этого когда кодишь под этот язык

ну такое

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

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

крч я холиварю на js потому что он меня не удовлетваряет и при это не оставляет выбора

кроме как кодить на нём

Тогда при чём тут JIT?

ну и про jit я тебе скинул про то, что у typescript нифига нет статической типизации, он создаёт видимость её существования и всё, не более того

это как в java закинуть в idea ошибку на отсутствие @override

ещё раз повторяю я скинул то, как устроен js под капотом

Ок, спасибо, почитаю на досуге. Но я ожидал нормального объяснения, как это относится к разговору о типизации и Java на фронте, а не какой-то непонятный наезд. По мне так Java в WASM - это на уровне ваадина в электроне - лютый изврат.

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

имхо будущее в следующем 1) Писать без IDE нельзя. IDE становится частью языка 2) В IDE встроен ИИ, вначале это будет тупо нейросеть с захардкожеными алгоритмами. 3) Код пишется в том виде, что больше удобен пользователю. Например, это REPL, не обязательно файл. 4) Но при этом IDE/язык/ИИ не позволяет писать неправильный код 5) Код, написанный пользователем - можно рассматривать как поток ивентов в event sourcing 6) То что попадет в реальную кодовую базу (в компиляцию) - это не то, что написал пользователь, а результат процессинга пользотвательского кода с помощью ИИ 7) Способ физического хранения ивентов и финального кода неважен. Возможно код будет "на лету" превращаться и сохраняться в кодовую базу в "правильном" виде. Возможно, материализовываться из ивентов только на момнет компиляции. В первом случае, в IDE пользователь сможет смотреть как свой код (ивенты), так и результат транскомпиляции. 8) В целом, это можно назвать AI-assisted code-as-event sourcing & CQRS, где IDE работает как human-machine-interface (и в будущем сможет быть заменена каким-нибудь имплантом в мозг, экзокортексом)

Ок, спасибо, почитаю на досуге. Но я ожидал нормального объяснения, как это относится к разговору о типизации и Java на фронте, а не какой-то непонятный наезд. По мне так Java в WASM - это на уровне ваадина в электроне - лютый изврат.

я тебе скинул ссылку где всё подробно объясняется, ты попросил в двух словах - я ответил в двух словах... Слушай, мне кажется ты зажрался

ну и про jit я тебе скинул про то, что у typescript нифига нет статической типизации, он создаёт видимость её существования и всё, не более того

Ну понятно, что в коде, который попадает браузерный движок JS, нет типов. Я спросил, какие это несёт минусы разработчику?

скинь сообщение где ты это спросил и скинь моё сообщение, как минимум половина ответа

скинь сообщение где ты это спросил и скинь моё сообщение, как минимум половина ответа

Ты не правильно понял мой вопрос "и что?", ну это ладно.

JS заставляет писать продуманный код. Любой непродуманный код в JS мгновенно превращается в ад адский. Это плохо!

по поводу продуманного кода, если разр пишет не продуманный код, то это не разр

Ты не правильно понял мой вопрос "и что?", ну это ладно.

Статическая типизация даёт самый простой машинный код. Поэтому она удобна для языков, дающих исполняемые файлы ОС или JIT-компилируемые промежуточные коды. Многие ошибки исключаются уже на стадии компиляции. Поэтому статическая типизация хороша для написания сложного, но быстрого кода. В интегрированной среде разработки осуществимо более релевантное автодополнение, особенно если типизация — сильная статическая: множество вариантов можно отбросить как не подходящие по типу. Чем больше и сложнее проект, тем большее преимущество дает статическая типизация, и наоборот. Недостатки Статическая типизация позволяет уже при компиляции заметить простые ошибки «по недосмотру». Для динамической типизации требуется как минимум выполнить данный участок кода. В объектно-ориентированных языках не действует, либо действует с ограничениями, автодополнение: трудно или невозможно понять, к какому типу относится переменная, и вывести набор её полей и методов. [источник не указан 315 дней] Развитая статическая система типов (такая как Хиндли-Милнер) играет значительную роль в самодокументировании программы[1]; динамическая типизация по определению не проявляет этого свойства, что затрудняет разработку структурно сложных программ. Снижение производительности из-за трат процессорного времени на динамическую проверку типа, и излишние расходы памяти на переменные, которые могут хранить «что угодно». К тому же большинство языков с динамической типизацией интерпретируемые, а не компилируемые.

Статическая типизация даёт самый простой машинный код. Поэтому она удобна для языков, дающих исполняемые файлы ОС или JIT-компилируемые промежуточные коды. Многие ошибки исключаются уже на стадии компиляции. Поэтому статическая типизация хороша для написания сложного, но быстрого кода. В интегрированной среде разработки осуществимо более релевантное автодополнение, особенно если типизация — сильная статическая: множество вариантов можно отбросить как не подходящие по типу. Чем больше и сложнее проект, тем большее преимущество дает статическая типизация, и наоборот. Недостатки Статическая типизация позволяет уже при компиляции заметить простые ошибки «по недосмотру». Для динамической типизации требуется как минимум выполнить данный участок кода. В объектно-ориентированных языках не действует, либо действует с ограничениями, автодополнение: трудно или невозможно понять, к какому типу относится переменная, и вывести набор её полей и методов. [источник не указан 315 дней] Развитая статическая система типов (такая как Хиндли-Милнер) играет значительную роль в самодокументировании программы[1]; динамическая типизация по определению не проявляет этого свойства, что затрудняет разработку структурно сложных программ. Снижение производительности из-за трат процессорного времени на динамическую проверку типа, и излишние расходы памяти на переменные, которые могут хранить «что угодно». К тому же большинство языков с динамической типизацией интерпретируемые, а не компилируемые.

Для кода, написанного на ЯП со статической типизацией и конвертированного в JS, из перечисленного здесь характерна только более низкая производительность.

зачем его конвертировать в js?

Для кода, написанного на ЯП со статической типизацией и конвертированного в JS, из перечисленного здесь характерна только более низкая производительность.

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

v8 просто скопилирует в байткод

зачем его конвертировать в js?

Чтобы писать на нормальном языке код, который можно запускать в браузере, который понимает только JS.

wasm

v8 просто скопилирует в байткод

JIT не бесплатный, как ни крути