32 коммента?

комменты бывают самой интересной частью

и комменты тоже прочитал

https://github.com/scalameta/scalameta/pull/761 Скоро scalameta завезут в scala.js!

звучит не плохо.

https://github.com/scalameta/scalameta/pull/761 Скоро scalameta завезут в scala.js!

разве она сейчас там не работает?

нет

нет

ты уверен? просто я только что скомпилировал проект в жс со скаламетой впридачу)

ну наверное не просто так этот пр сделали

ну наверное не просто так этот пр сделали

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

поясни плиз, что конкретно имеешь ввиду под "завезут в scala.js" )

https://github.com/scalameta/scalameta/issues/359 Чтобы можно было запускать scalameta на scalajs

А `typecheck` уже в скаламету завезли?

А `typecheck` уже в скаламету завезли?

Полноценно нет, но работа идет.

https://github.com/scalameta/scalameta/issues/359 Чтобы можно было запускать scalameta на scalajs

в рантайме на клиенте? сколько же оно весить будет на выходе?

пилят в данный момент

в рантайме на клиенте? сколько же оно весить будет на выходе?

Есть случаи, когда размер не сильно важен

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

Есть случаи, когда размер не сильно важен

какой юзкейс в данном случае может подойти, на ум только ide приходит или есть еще какие-то варианты?

ну в задаче же написано было, я ссылку кидал

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

https://github.com/scalameta/scalameta/issues/359 Чтобы можно было запускать scalameta на scalajs

Он ж там есть, мета раньше работает, чем js backend

Он ж там есть, мета раньше работает, чем js backend

Да не об этом речь. Макросы ты мог писать, и они бы разворачивались и в scalajs коде. А в задаче и пр речь о том, чтобы прям на js стороне можно было сделать какой-нибудь репл, и там макросами обмазываться

А

Есть несколько важных моментов 1) Если scala-meta начнет компилиться в scala-js, то там и до scala-native не далеко. 2) Когда в scala-meta допилят typecheck, то можно будет без особого труда написать полноценный интерпретатор скалы без всякх там jvm-костылей. 3) scala-native+интерпретатор == мнговенно поднимаемый интерпретатор скалы. А это значит мы сможем писать на скале нормальные скрипты. Мы даже сможем сделать сборочный тул, который не будет тормозить на старте.

С такими тезисами можно и на выборы. Я бы проголосовал.

Я ужe голосую.

sbt на старте торомозит не только потому что jvm

Есть несколько важных моментов 1) Если scala-meta начнет компилиться в scala-js, то там и до scala-native не далеко. 2) Когда в scala-meta допилят typecheck, то можно будет без особого труда написать полноценный интерпретатор скалы без всякх там jvm-костылей. 3) scala-native+интерпретатор == мнговенно поднимаемый интерпретатор скалы. А это значит мы сможем писать на скале нормальные скрипты. Мы даже сможем сделать сборочный тул, который не будет тормозить на старте.

c sn дела проще, возможно уже все хорошо работает

как будто sbt только на старте тормозит

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

Есть несколько важных моментов 1) Если scala-meta начнет компилиться в scala-js, то там и до scala-native не далеко. 2) Когда в scala-meta допилят typecheck, то можно будет без особого труда написать полноценный интерпретатор скалы без всякх там jvm-костылей. 3) scala-native+интерпретатор == мнговенно поднимаемый интерпретатор скалы. А это значит мы сможем писать на скале нормальные скрипты. Мы даже сможем сделать сборочный тул, который не будет тормозить на старте.

кстати насчет мгновенного старта ты не перебарщивай) там код сразу весь будет в оперативу грузится и хз скок эт заимет)

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

Можно угареть по хардкору и юзать cbt

Как будто sbt тормозит

Можно угареть по хардкору и юзать cbt

не знаю насчет него, ибо sn заточен под sbt сильно)

cbt пeрeимкновали? Или это всe eщe крис билд тул

Chris' Build Tool (CBT) for Scala

всё еще

но если на scala native начнёт бутстрапиться скала компилятор - это прямой путь к компиляции скалы быстрее получаса

JCBT - Jesus Christ Build Tool for Scala

у нас eсть контрибутор которого христос зовут

но если на scala native начнёт бутстрапиться скала компилятор - это прямой путь к компиляции скалы быстрее получаса

скорость компиляции эт не такая уж и вина jvm

2000й ишшу сдeлал

JCBT - Jesus Christ Build Tool for Scala

Java Certified Build Tool

скорость компиляции эт не такая уж и вина jvm

ну если добавить там чутка стэкаллокации, здесь немного валью эррэев, так падажжи 36@#@

Java Certified Build Tool

Java Certified Bullshit Talent

ну если добавить там чутка стэкаллокации, здесь немного валью эррэев, так падажжи 36@#@

если добавить стекаллокации, то он у тебя с so будет сразу падать)

Oleg да сколько можно!

Oleg да сколько можно!

а я говорил, нужен бот

Может быть просто нужно иметь немного уважения к сообществу и правилам?

@fomkin не все люди умные

Oleg да сколько можно!

но ведь это меметичный мат, у вас что нет уважения к мемесам может быть?

Против правил ; остоeдинится от нас радикальноe движeниe скалистов и создадут отдeльный чатик гдe они будут ток матeриться.

Против правил ; остоeдинится от нас радикальноe движeниe скалистов и создадут отдeльный чатик гдe они будут ток матeриться.

давно

Можно для самых маленьких? Суть native и прочего обсуждаемого выше – уйти от jvm вообще или просто для особо упоротых случаев?

Можно для самых маленьких? Суть native и прочего обсуждаемого выше – уйти от jvm вообще или просто для особо упоротых случаев?

нет

просто для особо упоротых случаев)

А какой смысл будет использовать jvm, если допилят native?

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

native скорее для короткоживущих приложений

все зависит от задач в общем

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

Почему? Не всё ли равно что крутится внутри контейнера? А с native быстрее по идее

Почему? Не всё ли равно что крутится внутри контейнера? А с native быстрее по идее

простите, но с херали? )

Говорю же, для самых маленьких)

ERROR: S client not available

sn не такой уж и native будет

потому что gc там будет

а вот возможности люто оптимизировать с помощью jit не будет

а вот возможности люто оптимизировать с помощью jit не будет

Ну как-то же другое на LLVM без jit живет

Ну как-то же другое на LLVM без jit живет

эт не значит, что оно быстрее jvm

а вот возможности люто оптимизировать с помощью jit не будет

большая часть лютой оптимизации на jit - это отыгранный перфоманс от невозможности написать нативно

все нормальные оптимизации LLVM умеет

все нормальные оптимизации LLVM умеет

У статической компиляции нет информации о рантаиме, поэтому с jit будет лучше

все нормальные оптимизации LLVM умеет

но по части тестиков LLVMный свифт сливает жабе https://benchmarksgame.alioth.debian.org/u64q/swift.html правда, надо смотреть что там за тесты и всё такое

У статической компиляции нет информации о рантаиме, поэтому с jit будет лучше

пока ни одного статистически оправданного подтверждения этому наивному утверждению нет

но по части тестиков LLVMный свифт сливает жабе https://benchmarksgame.alioth.debian.org/u64q/swift.html правда, надо смотреть что там за тесты и всё такое

свифт сливает всем, просто потому что он свифт

GHC на LLVM бустится порой, против совсем нативной компиляции https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/code-generators.html

У статической компиляции нет информации о рантаиме, поэтому с jit будет лучше

ведь точно так же можно сказать, что у jit нет 99% информации о типах

свифт сливает всем, просто потому что он свифт

А что с ним не так? Не особо в курсе

А что с ним не так? Не особо в курсе

неизвестно что, но почему-то он очень медленный

хм, интересно Scala-native быстрее/медленнее компилится чем оригинальный компилятор

пока ни одного статистически оправданного подтверждения этому наивному утверждению нет

Да как бы есть

Куча сравнении jvm с native

хм, интересно Scala-native быстрее/медленнее компилится чем оригинальный компилятор

это оригинальный компилятор + несколько навешенных штук, плюс компиляция в гораздо более развёрнутый чем java bytecode, так что должна проигрывать хотя бы из-за размера генерируемых артефактов

Куча сравнении jvm с native

и везде jvm сосёт

неизвестно что, но почему-то он очень медленный

https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-2-speed-ca65b2f79505#.jk6xbnocp по тестикам vapor свифтовый очень даже бодрый

Она сосет из-за gc

Если убрать время на сборки

То врядли

https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-2-speed-ca65b2f79505#.jk6xbnocp по тестикам vapor свифтовый очень даже бодрый

тебя не смущает, что там по графику node.js быстрее jvm ? дальше можно не читать)

Она сосет из-за gc

ну опять же гипотетические рассуждения, я тоже предполагаю, что некий гипотетический компилятор может писать код лучше людей, но неизвестно, что ему в этом поможет лучше - трейсить поведение в рантайме, или точно знать все логические взаимосвязи между процессами в дизайн тайме, поэтому пока что лучший jit на сегодняшний день LuaJIT редко оказывается лучше натива

ну опять же гипотетические рассуждения, я тоже предполагаю, что некий гипотетический компилятор может писать код лучше людей, но неизвестно, что ему в этом поможет лучше - трейсить поведение в рантайме, или точно знать все логические взаимосвязи между процессами в дизайн тайме, поэтому пока что лучший jit на сегодняшний день LuaJIT редко оказывается лучше натива

Да почему ж, говорю, куча доков

Сравнение прям ассемблера

Да почему ж, говорю, куча доков

ну хорошо, что ты говоришь, что их куча

Ты прост смотришь на время, что не есть правильно

Ты прост смотришь на время, что не есть правильно

Нет, я не смотрю на время в твоём пруфлинке, т.к. ты ещё не предоставил пруфлинка

пруф-пуф-пуф