3 ms·

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 pro

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.

Ygg2 4y ago
> Also the post is about the old version of Scala. It wasn't my language by choice. Neither was the version. > If you don't like powerful languages with modern features I guess Rust is also not for you. I like Rust's pragmatism. Allow limited operator overload. Eschew HKT for a simpler abstractions. Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature. The more powerful feature the more abusable it is, and Scala loves the power at all cost. Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling. Plus Scala has the big deal breaker. GC and no custom primitive types. > 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. What do you mean exactly?
- still_grokking 4y ago
  > I like Rust's pragmatism. Me too. But Scala is also a very pragmatic language. If you want something academic go for Haskell. > Allow limited operator overload. Nitpick: Scala does not have any operators. So it doesn't have operator overloading at all. Scala simulates operators by infix method syntax. Instead of writing `1.+(2)` you can just write `1 + 2`. But the later is the same method call as the first one! > Eschew HKT for a simpler abstractions. AFAIK HKTs are more or less "just postponed" in Rust, AFAIK. People would like to add them of course. The discussion goes on forever by now. Some small insight (there is much more when you look for it): https://github.com/rust-lang/rfcs/issues/324 https://github.com/rust-lang/rfcs/issues/324 https://internals.rust-lang.org/t/higher-kinded-types-the-difference-between-giving-up-and-moving-forward/3908/7 https://internals.rust-lang.org/t/higher-kinded-types-the-di... > Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature. While having a full ML style type system with afine types on top, and quite some other type level mechanics up to singleton types? Sure sure, no power in here. :-) > The more powerful feature the more abusable it is, and Scala loves the power at all cost. Everything is "abusable". This is not an argument. But that Scala loves power at all cost is simply not true. The contrary is. Just to cite one of the most influential post in Scala land of all times: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL... This, and the BDFL constantly complaining about unnecessary complex code people write speaks for itself. Scala lately even reduced the power of some features just to prevent "abuse". (Which is partly an overreaction; but that's another story). > Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling. That's also not true. Scala has a very small and simple syntax (despite all the language features). Scala is on the surface much much simpler and much more regular then Rust! https://github.com/e3b0c442/keywords https://github.com/e3b0c442/keywords (You could also compare the language grammars. This would be even more in favor of Scala in this regard). Scala 3 looks even almost like Python! https://docs.scala-lang.org/scala3/book/scala-for-python-devs.html https://docs.scala-lang.org/scala3/book/scala-for-python-dev... > Plus Scala has the big deal breaker. GC and no custom primitive types. What a "deal breaker"? https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-a-garbage-collected-language-like-java-kotlin-or-go https://github.com/carbon-language/carbon-lang/blob/trunk/do... You've seen this here in the thread? Also: https://docs.scala-lang.org/overviews/core/value-classes.html https://docs.scala-lang.org/overviews/core/value-classes.htm... As soon as Valhalla lands in JVM-land this will be full blown value types without any limitations. And in Scala Native you can have of course native structs today. (Only that Scala Native isn't ready for prime time just now). In the long run Scala Native could also run without GC. The Caprese project will bring something that is more powerful than Rust lifetimes. Lifetimes will fall out as a special case of a more general concept. > > 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. > What do you mean exactly? Implicits get discussed every now and than in Rust land. Even the above Rust internals discussion start with them. Or this here: https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/ https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa... Also I've once read something that looked like a brain storming for future Rust features. They came up with more or less implicits (only that they didn't call them like that, so I can't find this any more, didn't bookmark it). Someone even once proposed directly Scala's implicits for Rust. But this went nowhere as the other people on the forum actually didn't understand them (which was no wonder as the example was quite terrible and the proponent was not really experienced with Scala so couldn't explain it well). People came than to quite wrong conclusions (some of them even mixed implicits in general even the dreaded implicit conversions, which were in fact mostly overused and caused trouble in Scala; but things got redesigned exactly because of that).

Ygg2 4y ago

> Also the post is about the old version of Scala. It wasn't my language by choice. Neither was the version. > If you don't like powerful languages with modern features I guess Rust is also not for you. I like Rust's pragmatism. Allow limited operator overload. Eschew HKT for a simpler abstractions. Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature. The more powerful feature the more abusable it is, and Scala loves the power at all cost. Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling. Plus Scala has the big deal breaker. GC and no custom primitive types. > 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. What do you mean exactly?

still_grokking 4y ago
> I like Rust's pragmatism. Me too. But Scala is also a very pragmatic language. If you want something academic go for Haskell. > Allow limited operator overload. Nitpick: Scala does not have any operators. So it doesn't have operator overloading at all. Scala simulates operators by infix method syntax. Instead of writing `1.+(2)` you can just write `1 + 2`. But the later is the same method call as the first one! > Eschew HKT for a simpler abstractions. AFAIK HKTs are more or less "just postponed" in Rust, AFAIK. People would like to add them of course. The discussion goes on forever by now. Some small insight (there is much more when you look for it): https://github.com/rust-lang/rfcs/issues/324 https://github.com/rust-lang/rfcs/issues/324 https://internals.rust-lang.org/t/higher-kinded-types-the-difference-between-giving-up-and-moving-forward/3908/7 https://internals.rust-lang.org/t/higher-kinded-types-the-di... > Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature. While having a full ML style type system with afine types on top, and quite some other type level mechanics up to singleton types? Sure sure, no power in here. :-) > The more powerful feature the more abusable it is, and Scala loves the power at all cost. Everything is "abusable". This is not an argument. But that Scala loves power at all cost is simply not true. The contrary is. Just to cite one of the most influential post in Scala land of all times: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL... This, and the BDFL constantly complaining about unnecessary complex code people write speaks for itself. Scala lately even reduced the power of some features just to prevent "abuse". (Which is partly an overreaction; but that's another story). > Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling. That's also not true. Scala has a very small and simple syntax (despite all the language features). Scala is on the surface much much simpler and much more regular then Rust! https://github.com/e3b0c442/keywords https://github.com/e3b0c442/keywords (You could also compare the language grammars. This would be even more in favor of Scala in this regard). Scala 3 looks even almost like Python! https://docs.scala-lang.org/scala3/book/scala-for-python-devs.html https://docs.scala-lang.org/scala3/book/scala-for-python-dev... > Plus Scala has the big deal breaker. GC and no custom primitive types. What a "deal breaker"? https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-a-garbage-collected-language-like-java-kotlin-or-go https://github.com/carbon-language/carbon-lang/blob/trunk/do... You've seen this here in the thread? Also: https://docs.scala-lang.org/overviews/core/value-classes.html https://docs.scala-lang.org/overviews/core/value-classes.htm... As soon as Valhalla lands in JVM-land this will be full blown value types without any limitations. And in Scala Native you can have of course native structs today. (Only that Scala Native isn't ready for prime time just now). In the long run Scala Native could also run without GC. The Caprese project will bring something that is more powerful than Rust lifetimes. Lifetimes will fall out as a special case of a more general concept. > > 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. > What do you mean exactly? Implicits get discussed every now and than in Rust land. Even the above Rust internals discussion start with them. Or this here: https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/ https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa... Also I've once read something that looked like a brain storming for future Rust features. They came up with more or less implicits (only that they didn't call them like that, so I can't find this any more, didn't bookmark it). Someone even once proposed directly Scala's implicits for Rust. But this went nowhere as the other people on the forum actually didn't understand them (which was no wonder as the example was quite terrible and the proponent was not really experienced with Scala so couldn't explain it well). People came than to quite wrong conclusions (some of them even mixed implicits in general even the dreaded implicit conversions, which were in fact mostly overused and caused trouble in Scala; but things got redesigned exactly because of that).