luajit
Scala.js
luajit | Scala.js | |
---|---|---|
1 | 34 | |
540 | 4,542 | |
- | 0.3% | |
10.0 | 9.0 | |
over 4 years ago | 3 days ago | |
C | Scala | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
luajit
-
Back-end languages are coming to the front-end
> No offence, but have you written any compilers or interpreters?
I have, but nothing sophisticated.
> The points that you discuss [...] may be performance concerns for application developers [...] but they have very little to do with the optimisations you can make as a compiler/interpreter writer. [...] The only one that's somewhat relevant is 'global scope by default'
I didn't mean to imply that these where the three common traits that make both Javascript and Lua particularly hard to optimize, I just picked them as examples for how Javascript and Lua are closer to each other than most other dynamic languages.
But let's dig in a bit on your claim that things like all numbers being doubles or having a array cum map cum record type has very little to do with the optimizations you can make as a compiler/interpreter writer, because it sure seems to me that LuaJIT and V8 do a bunch of optimizations around these things. Both have dual number representations under the hood and will try to avoid representing numbers that remain in the domain of 32 bit integers as double values internally when that gives performance gains. The logic for figuring out if that's the case doesn't seem to be super-straightforward or target architecture independent from looking at the comments in <https://github.com/LuaDist/luajit/blob/master/src/lj_opt_nar...>.
LuaJIT furthermore uses NaN tagging (as do some JS engines, although not V8), which looks less attractive to me as a representation strategy if your numbers are not all/mostly notional doubles (as is indeed the case in newer version of Lua where 64bit integers are the dominant number type)
Also, as far as the super-flexible lua tables are concerned, I'm pretty sure LuaJIT goes through some amount of trouble to specialize various common use cases of tables, e.g. as arrays without holes, and surprise, so does V8 (https://v8.dev/blog/fast-properties#elements-or-array-indexe...). I don't think you'd find something equivalent in a high performance scheme implementation.
> but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole').
Eval belongs to a core set of features that basically all popular dynamic languages share that presents headaches for high performance implementations. How is Javascript's eval particularly problematic in this regard, and specifically much more so than Lua's loadstring/load?
More generally what do you think makes (pre-ES6) javascript significantly harder to optimize than lua 5.0?
Scala.js
-
The dangers of single line regular expressions
`$` does mean end of input in Java, unless you explicitly ask for multiline mode. In the latter case it means `(?=$|\n)` if also in Unix-lines mode, and the horrible `(?=$|(?I wrote a compiler from Java regex to JavaScript RegExp, in which you'll find that particular compilation scheme [1].
[1] https://github.com/scala-js/scala-js/blob/eb160f1ef113794999...
- Typescript FP Job?
-
Reconnecting with Scala. What's new?
Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html
-
Rust on Espressif chips – 2023 Roadmap
> Scala choices were directly dictated by JVM
Initially, yes. But Scala has evolved beyond the JVM, with Scala.js [1] being rock-solid, and Scala Native [2] under development. Neither are truly hampered by the initial JVM roots of Scala.
> Scala gives you a better horse
Weird analogy ;)
[1] https://www.scala-js.org/
- 10 years of Scala.js
-
Looking for an alternative to Javascript
Have you had a look at Scala.js yet? Also see "Scala.js for JavaScript developers." and "Tour of Scala."
-
Contrary to popular belief, Scala is actually a quite small and simple language
What does that have to do with language size? It also compiles to js https://www.scala-js.org/ and native https://scala-native.org/en/stable/
-
Switch JS job for Scala internship?
Here's a hybrid option: Scala.js. Yes, it is about building web applications but in Scala. You can retain the HTML/CSS/JS knowledge you have but build web applications from a typesafe and powerful language: Scala
-
Dropping Scala 2.11 support in Scala.js and Scala Native
The compiler crash in question affects another feature that we would like to merge for the benefit of all users, namely https://github.com/scala-js/scala-js/pull/4735. Keeping 2.11 means that testing and shipping that feature is much more difficult, even for 2.12+ users only. It's not just "to fix a compiler crash".
-
Windows decide whether your computer has limited or full Internet access
TS is more in the "mixed feelings" department, imho.
I would take Scala.js anytime instead. (If I would need to do front-end ever again).
https://www.scala-js.org/
What are some alternatives?
wasmer-python - 🐍🕸 WebAssembly runtime for Python
scalajs-react - Facebook's React on Scala.JS
diode - Scala library for managing immutable application model
js-scala - js.scala: JavaScript as an embedded DSL in Scala
htmx - </> htmx - high power tools for HTML
awesome-wasm-langs - 😎 A curated list of languages that compile directly to or have their VMs in WebAssembly
mumba - Write web-native p2p distributed apps in Swift (and others)
sri
reactor - Phoenix LiveView but for Django
React4s - Production ready React wrapper for Scala.js - composable lifecycle - no memoization, no macros, no implicits.
django-unicorn - The magical reactive component framework for Django ✨
Laminar - Simple, expressive, and safe UI library for Scala.js