5 ms·

A major value proposition is also "I want to run my code with predictable latency". This opens Scala to embedded and realtime development. The LLVM AOT optimiz

A major value proposition is also "I want to run my code with predictable latency". This opens Scala to embedded and realtime development. The LLVM AOT optimizations are also likely to be a lot stronger than JVM JIT optimizations - granted it's good to compile on the exact target architecture. Also granted that sometimes dynamic optimization helps a lot. Nice handle BTW. lol

usrusr 10y ago
But how much predictability can you get in presence of garbage collection? Granted, the JIT can also be an element of surprise that is out of the picture with AOT and the statically linked GC can never be configured differently from what you expect, but it's still garbage collection and not Rust or a C.
- gravypod 10y ago
  There's a lot of examples of GC in realtime systems. It's just a different set of concerns. Rather then the programmer worrying about memory constantly, the compiler engineers are worrying about memory constantly. This is a very fun read: http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html
gravypod 10y ago
Binary sizes kill the assumption that it would be possible to use in embedded development. An unpredictable GC makes it impossible to use for realtime work. For both you need: * An understanding of what kind of code will be generated * Predictable, and hopefully verified, GC * Reasonable binary sizes * Very good tree shaking Currently the only things I've seen used for realtime developmend have been C, C++, Rust, raw assembly, and LISP. LISP and raw assembly are dead now. Rust is just starting and has a lot of progress to be made. C++ is showing some reasonable improvements. C is C. If Scala Native could deliver on small binary sizes, "0 runtime" like Rust, and a way embed inline assembly like instructions then it would be a winner.
adamwk 10y ago
Is this actually the case? I'd assume that Scala has the same dynamic nature as Java, and so AOT won't be able to convert dynamic dispatch to static as frequently.

usrusr 10y ago

But how much predictability can you get in presence of garbage collection? Granted, the JIT can also be an element of surprise that is out of the picture with AOT and the statically linked GC can never be configured differently from what you expect, but it's still garbage collection and not Rust or a C.

gravypod 10y ago
There's a lot of examples of GC in realtime systems. It's just a different set of concerns. Rather then the programmer worrying about memory constantly, the compiler engineers are worrying about memory constantly. This is a very fun read: http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html

gravypod 10y ago

Binary sizes kill the assumption that it would be possible to use in embedded development. An unpredictable GC makes it impossible to use for realtime work. For both you need: * An understanding of what kind of code will be generated * Predictable, and hopefully verified, GC * Reasonable binary sizes * Very good tree shaking Currently the only things I've seen used for realtime developmend have been C, C++, Rust, raw assembly, and LISP. LISP and raw assembly are dead now. Rust is just starting and has a lot of progress to be made. C++ is showing some reasonable improvements. C is C. If Scala Native could deliver on small binary sizes, "0 runtime" like Rust, and a way embed inline assembly like instructions then it would be a winner.

adamwk 10y ago

Is this actually the case? I'd assume that Scala has the same dynamic nature as Java, and so AOT won't be able to convert dynamic dispatch to static as frequently.