> Rust is taking things rather steady because of a strong preference for soundness. As does Scala. Scala has even formal and machine checked proves for large

> Rust is taking things rather steady because of a strong preference for soundness. As does Scala. Scala has even formal and machine checked proves for large parts of the language. Something that almost no other languages have. Especially no mainstream language. > A strong macro system is very dangerous. In which way? What do you mean exactly? > Are Scala's macros somehow less dangerous? Hard to say without knowing what is meant by "dangerous". :-) But I guess you can judge for yourself: https://docs.scala-lang.org/scala3/reference/metaprogramming/index.html https://docs.scala-lang.org/scala3/reference/metaprogramming... The new meta-programming features are at least type safe. (Also this is most likely the most advanced macro system out there. Fresh form top notch research, after many years of experimentation in the field). > It's probably never going to be as comfortable to write Rust as Scala […] As long as Rust doesn't change it's syntax (very unlikely) and adds a garbage collector (actually likely as there are some explorations already done in this direction) this will stay true, yes. > […] but on the other hand it's definitely never going to be possible to deliver the performance of Rust in Scala. I see no technical reason for that. Rust doesn't do magic. It just optimizes things quite well. Key is aggressive erasure, specialization, and monomorphisation. Things that every compiler can do, if implemented. Scala on the JVM can't do that really as this would break the expectations and semantics of the JVM. But Scala Native can do that! It would "only" take someone to build this stuff… Scala had already almost a quite advanced optimizer. But the dude who was building this left as soon as he got his PhD for that project and didn't finish it at all. Someone would need to pick up the remains and push this over the finish line. As long as you would write code like in Rust (which is perfectly possible as Rust is kind of a subset of Scala) performance could be very close. (Of course you would need to avoid some features, like dynamic dispatch, and also excessive OOP patterns, but there is no technical reason why this shouldn't be possible at all). Creating all the desugarings like the ones used in Rust would be of course some work. The optimizer that was almost there did not do that. It "only" optimized user level code, not the implementation of base types and build-in language features. (But still it could generate code that was en par with Java written by hand in the best possible way; the performance of such code is almost on the C level; the JVM suffers from issues with memory, not with performance, which is actually very competitive; there are even cases where the JVM beats C/C++ code regarding performance; but usually with one to two orders of magnitude more memory used). But like I said, Scala Native could take even one step further and optimize things in a way C/C++/Rust compilers do. In case you missed Scala Native: https://scala-native.org/en/stable/ https://scala-native.org/en/stable/ Please bear in mind when comparing to something else: It's still pre v1.0 and still needs quite some love. But it has partly better performance than GraalVM, and is much more stable than Kotlin Native (which is still alpha quality). But for example the manual region based memory management in Scala (which can be used along the GC) would need improvement. To keep up with Rusts borrow checker the whole capture checking stuff needs to land first; and this could take some time. But with this features Scala could do also completely without GC in the long run! (Only for dedicated "no GC code" of course). https://www.slideshare.net/Odersky/capabilities-for-resources-and-effects-252161040 https://www.slideshare.net/Odersky/capabilities-for-resource... https://docs.scala-lang.org/scala3/reference/experimental/cc.html https://docs.scala-lang.org/scala3/reference/experimental/cc...