6 ms·

I'm a Scala fan. (Maybe this shows :-)). But I'm also quite excited by Rust lately. But coming from Scala my feeling is constantly: Rust is missing so much st

I'm a Scala fan. (Maybe this shows :-)). But I'm also quite excited by Rust lately. But coming from Scala my feeling is constantly: Rust is missing so much still! I would really like a language more like Scala but with the performance of Rust. Of course other people get very excited when using Rust because for many this is the first proper language they've ever encountered. But I'm quite unimpressed in general regarding "hyped" Rust features. I had immutable values, HOFs, ADTs, type-classes, pattern matching with exhaustivity checks, macros, and all that "since forever". But I miss HKTs, implicits, proper macros, and some other things in Rust. It will take at least a decade for Rust to catch up. But than Scala will be even farther away… But OK, at least one can say that the ML family of languages is finally succeeding. (Scala and Rust are both descendants of ML).

tialaramex 4y ago
Sure, lots of things would be nice to have in Rust that aren't done yet. Some of them you can see in nightly, because their rough shape exists but isn't stabilised. Rust is taking things rather steady because of a strong preference for soundness. In particular I want a stable niche (my nook crate uses the unstable niches because that's the only way to do it, the intent is to use a stabilised mechanism when one exists), I want a stable way to write const implementations of traits which aren't necessarily const (and thus const for loops) and on the same lines I want const panic. A strong macro system is very dangerous. I use and like Rust's declarative ("By example") macros, and I appreciate the need for proc macros or other technology but it's very dangerous. Are Scala's macros somehow less dangerous? Or you just prefer how they work? Rust has come a pretty long way since 1.0. Once upon a time u8::MAX couldn't exist. There was no way to express the idea that a type has an associated constant, so that's why std::u8::MAX is (deprecated but) there. It's probably never going to be as comfortable to write Rust as Scala, but on the other hand it's definitely never going to be possible to deliver the performance of Rust in Scala.
- Ygg2 4y ago
  As someone that had to dabble in Scala. Most of stuff Scala has fill me with dread. "proper macro", implicits, custom operator overloading, etc. Are extremely powerful concepts. Too powerful if you ask me. They tend to make code utterly unreadable (without an IDE). Why is `int` a `Date`? Don't know. Use an IDE. What does the ~%+# operator does? ¯\_(ツ)_/¯ [2] But I'm a bit conservative in language syntax. I'm against async and its in most languages already (it makes debugging more convoluted). [1]https://lprakashv.medium.com/how-to-keep-your-sanity-working-with-scala-implicit-fda9ffc33162 https://lprakashv.medium.com/how-to-keep-your-sanity-working... [2]http://www.scala-graph.org/guides/core-initializing.html http://www.scala-graph.org/guides/core-initializing.html
  - still_grokking 4y ago
    Have you actually read what you've linked? From [1]: > While this can be really disheartening, this is not enough of a reason to move away from an amazing programming language, just because of a really abused feature! Please also note: The blog post talks only about implicit conversions. That's actually the most uninteresting part of implicits. (Watch the video there to learn what implicits are actually for). Also the post is about the old version of Scala. Implicits got redesigned in Scala 3. They're not even called implicits any more. https://docs.scala-lang.org/scala3/reference/contextual/index.html https://docs.scala-lang.org/scala3/reference/contextual/inde... All problems mentioned in the blog post are solved. For example you can't import `given`s (like implicit definitions are called now) by accident. You need to do this explicitly. They got removed form the normal import scope. Implicit conversions are btw. now heavily guarded, with very explicit declarations in form of a type-class instance & lang imports, besides the other changes that make application much safer so less surprises possible: https://docs.scala-lang.org/scala3/reference/changed-features/implicit-conversions-spec.html https://docs.scala-lang.org/scala3/reference/changed-feature... But anyway, everybody know since years that you should not overuse them. Also other languages like C# have this feature (and I'm not even talking about dynamic languages where this is the "normal" way everything works without safe guards by a static type system). Nobody ever complained about C# in this regard. Besides that: The Rust people are looking envious. I've read about some ideas that were more or less a direct copy of Scala's implicits. And I'm quite sure, if Rust would introduce something like that most people would love it! Because it would solve some issues in Rust, and would also allow to remove complex boilerplate code. Than, [2] is a pure obscurity. Never heard of. But even the "WTF-operators" defined in this library look very strange (this is not usual Scala code!) I would not know without lookup what a `WLkUnDiEdge` is, even when spelled out… And to stress it once more: This external lib is not part of Scala. Something like that wouldn't be ever accepted into the std. lib! The BDFL wants to even remove unrestricted operator syntax. But I hope this does not happen as it would only make the language more complex for no gain. Someone who defines a `~%+#` operator would likely still do it even when you would have to write it as ` ~%+# `. So nothing won. [The operator method is written without the spaces around the back-ticks of course. But this does not render well here] > Too powerful if you ask me. If you don't like powerful languages with modern features I guess Rust is also not for you.
- shrimp_emoji 4y ago
  Don't respond to the Scala stuff; the poster is just trolling you: https://news.ycombinator.com/item?id=34218609 https://news.ycombinator.com/item?id=34218609
  - still_grokking 4y ago
    I'm not trolling anybody! The parent is not fanboying Rust much. Instead this looks like an interesting exchange of insights and opinions. I actually want to learn why people seem to really like Rust even it's "just" like a "Scala light". What was deemed "too complex" or "academic" in Scala is now everybody's darling in Rust. This is actually quite interesting. I'm looking for hints how to resolve the marketing issue with Scala. The other comment was meant more lighthearted and shouldn't be read out of context.
- still_grokking 4y ago
  > 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...

tialaramex 4y ago

Sure, lots of things would be nice to have in Rust that aren't done yet. Some of them you can see in nightly, because their rough shape exists but isn't stabilised. Rust is taking things rather steady because of a strong preference for soundness. In particular I want a stable niche (my nook crate uses the unstable niches because that's the only way to do it, the intent is to use a stabilised mechanism when one exists), I want a stable way to write const implementations of traits which aren't necessarily const (and thus const for loops) and on the same lines I want const panic. A strong macro system is very dangerous. I use and like Rust's declarative ("By example") macros, and I appreciate the need for proc macros or other technology but it's very dangerous. Are Scala's macros somehow less dangerous? Or you just prefer how they work? Rust has come a pretty long way since 1.0. Once upon a time u8::MAX couldn't exist. There was no way to express the idea that a type has an associated constant, so that's why std::u8::MAX is (deprecated but) there. It's probably never going to be as comfortable to write Rust as Scala, but on the other hand it's definitely never going to be possible to deliver the performance of Rust in Scala.

Ygg2 4y ago
As someone that had to dabble in Scala. Most of stuff Scala has fill me with dread. "proper macro", implicits, custom operator overloading, etc. Are extremely powerful concepts. Too powerful if you ask me. They tend to make code utterly unreadable (without an IDE). Why is `int` a `Date`? Don't know. Use an IDE. What does the ~%+# operator does? ¯\_(ツ)_/¯ [2] But I'm a bit conservative in language syntax. I'm against async and its in most languages already (it makes debugging more convoluted). [1]https://lprakashv.medium.com/how-to-keep-your-sanity-working-with-scala-implicit-fda9ffc33162 https://lprakashv.medium.com/how-to-keep-your-sanity-working... [2]http://www.scala-graph.org/guides/core-initializing.html http://www.scala-graph.org/guides/core-initializing.html
- still_grokking 4y ago
  Have you actually read what you've linked? From [1]: > While this can be really disheartening, this is not enough of a reason to move away from an amazing programming language, just because of a really abused feature! Please also note: The blog post talks only about implicit conversions. That's actually the most uninteresting part of implicits. (Watch the video there to learn what implicits are actually for). Also the post is about the old version of Scala. Implicits got redesigned in Scala 3. They're not even called implicits any more. https://docs.scala-lang.org/scala3/reference/contextual/index.html https://docs.scala-lang.org/scala3/reference/contextual/inde... All problems mentioned in the blog post are solved. For example you can't import `given`s (like implicit definitions are called now) by accident. You need to do this explicitly. They got removed form the normal import scope. Implicit conversions are btw. now heavily guarded, with very explicit declarations in form of a type-class instance & lang imports, besides the other changes that make application much safer so less surprises possible: https://docs.scala-lang.org/scala3/reference/changed-features/implicit-conversions-spec.html https://docs.scala-lang.org/scala3/reference/changed-feature... But anyway, everybody know since years that you should not overuse them. Also other languages like C# have this feature (and I'm not even talking about dynamic languages where this is the "normal" way everything works without safe guards by a static type system). Nobody ever complained about C# in this regard. Besides that: The Rust people are looking envious. I've read about some ideas that were more or less a direct copy of Scala's implicits. And I'm quite sure, if Rust would introduce something like that most people would love it! Because it would solve some issues in Rust, and would also allow to remove complex boilerplate code. Than, [2] is a pure obscurity. Never heard of. But even the "WTF-operators" defined in this library look very strange (this is not usual Scala code!) I would not know without lookup what a `WLkUnDiEdge` is, even when spelled out… And to stress it once more: This external lib is not part of Scala. Something like that wouldn't be ever accepted into the std. lib! The BDFL wants to even remove unrestricted operator syntax. But I hope this does not happen as it would only make the language more complex for no gain. Someone who defines a `~%+#` operator would likely still do it even when you would have to write it as ` ~%+# `. So nothing won. [The operator method is written without the spaces around the back-ticks of course. But this does not render well here] > Too powerful if you ask me. If you don't like powerful languages with modern features I guess Rust is also not for you.
shrimp_emoji 4y ago
Don't respond to the Scala stuff; the poster is just trolling you: https://news.ycombinator.com/item?id=34218609 https://news.ycombinator.com/item?id=34218609
- still_grokking 4y ago
  I'm not trolling anybody! The parent is not fanboying Rust much. Instead this looks like an interesting exchange of insights and opinions. I actually want to learn why people seem to really like Rust even it's "just" like a "Scala light". What was deemed "too complex" or "academic" in Scala is now everybody's darling in Rust. This is actually quite interesting. I'm looking for hints how to resolve the marketing issue with Scala. The other comment was meant more lighthearted and shouldn't be read out of context.
still_grokking 4y ago
> 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...