6 ms·

> Simplify where possible > eliminate inconsistencies and surprising behavior Oh dear god please.

by mavdi 8y ago

realusername 8y ago
I know on HN people like Scala but it's by far one of the language I hated the most when I worked with it. It's the complete opposite of Go, every time the Go team said no to a random feature, the Scala team said yes to that random feature. Scala feels to me like a kind of functional Perl.
- deleted 8y ago
  [deleted]
- willtim 8y ago
  The Scala team appear to have their hearts in the right place. They seek to empower their users and have respect for them. I can't really say the same about the Go team, based on at least one Google presentation I have seen. This isn't that surprising given the goals of the projects.
  - realusername 8y ago
    I did not want to start a flame-war Scala vs Go, it's just that I like Go simplicity & readability (I also like Python and Ruby for those reasons as well) whereas I'm not a huge fan of the Perl feeling of Scala.
    - willtim 8y ago
      When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.
      - dragonwriter 8y ago
        Right: phrased differently, weaker abstraction power means recurring problems have to be addressed by documenting patterns with fill-in-the-blanks recipes, instead of reusable code libraries.
      - realusername 8y ago
        > hope that we can uncover some emergent higher-level structure, if it exists. That's exactly what I feel when I read Scala code, everything is a soup of custom operators, implicits and objects disguised like functions (or the opposite, you think it's an object but actually it's a function), it makes the code very hard to maintain and read. At least with Go, Python or Ruby your logic is in plain English, that makes it much easier.
        lmm 8y ago
        I find the opposite. With Scala my logic can be plain English written in the language of the domain, because Scala makes it very easy to push out secondary concerns like authentication or audit logging or error handling out into the type system where they're still there, still managed, still checked by the compiler, still visible on mouseover/click-through in my IDE, but they don't have to obscure the straight-through happy-path business logic. Whereas in Go, all the secondary logic has to be right there, which clutters up the code and makes it harder to see the primary thread, and in Python or Ruby either you do the same thing or else the secondary logic has to work by invisible magic (metaclasses, exceptions, method_missing...) and you have no hope of ever being able to understand what's actually going on.
      - seanmcdirmid 8y ago
        This is analogous to the tension between “worse is better” and “perfect is the enemy of good.” One the one hand, elegance is impossible and one must settle early on inelegance. On the other hand, elegance is possible but one must be clever and spend a lot of time looking for it. These trade offs are really apparent in competing language designs (Scala, Go) and it isn’t clear which ones are the better ones to make.
    - 62747478182 8y ago
      You said [Scala] it's by far one of the language I hated the most. If you don't want to start a flame-war maybe you should change the tone of the comment.
- _Codemonkeyism 8y ago
  Scala is not for development, it's a research project.
  - sulam 8y ago
    I don’t know is this is a good troll because I’m replying or a bad troll because it’s so obvious. There are Many people who work at many companies doing real development with Scala that goes all the way to production, handling real user traffic.
    - _Codemonkeyism 8y ago
      Yes we use Scala in production for >6 years. But I wonder how many companies would make the same decision again after their experience with Scala.
  - dang 8y ago
    Please don't post flamebait to Hacker News.
  - _Codemonkeyism 8y ago
    Foursquare lib migration to Scala 2.12, open since one year, we can't upgrade to 2.12 because of that dependency, https://github.com/foursquare/fsqio/issues/37 https://github.com/foursquare/fsqio/issues/37 They don't upgrade the open source version because their internal version depends on that open source version and they don't can't upgrade internally to 2.12. They can't upgrade because of several dependencies of their own, the last one Finagle. All of those although "cross compiles are no problem" as the default answer from the Scala development team on these issues.
- lmm 8y ago
  Can you be specific? This is a popular meme but it doesn't match my experience of Scala's language features at all (indeed I'd say Scala is very good at pushing things out into libraries or composition of existing features rather than making them language features), and often I find people with this kind of complaint were actually using a library with poorly named functions and mistaking its features for language features.
  - realusername 8y ago
    I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Secondly, the implicit concept makes the code difficult to read. Then I would add that the differentiation between function & variable isn't always clear and sometimes you don't know what you call.
    - lmm 8y ago
      > I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them - no language is impossible to write bad libraries in. Certainly I wouldn't ever want to go back to a language that uses magically-named methods for operator overloading, like Python and Kotlin do - I find that far more confusing, I can never remember whether a * b is calling a.__times__(b) or a.__star__(b) or something else. I could get behind a language that disallowed symbolic names entirely, but I don't think I've seen one of those since Java. > Secondly, the implicit concept makes the code difficult to read. IDE support has gotten a lot better now (green underline to highlight any implicit conversion, expand out implicit parameters) which makes them much easier to work with. If you only use implicits in cases where you otherwise wouldn't do anything in code at all, they enhance readability - but of course if you use them to replace things that you'd otherwise make explicit then they can reduce readability. I don't have a good answer, because I definitely want extension methods, typeclasses with derivation, and the magnet pattern, but I haven't yet seen a language design that makes those things possible while disallowing the bad uses of implicits.
- icedchai 8y ago
  I share the same opinion of Scala. It definitely feels like it has too many features and is too complicated. Back in 2010 - 11, when I last worked with it, the compiler was also dog slow and IDE support was terrible. No doubt this has changed for the better, but it did ruin the language for me. I'll stick to Kotlin and Java, thanks.
MrBuddyCasino 8y ago
Also, no plans to get rid of implicits apparently. Sorry Scala, we're not gonna be friends.
- pul 8y ago
  Not fully, but implicit type conversion must be marked explicitly: https://medium.com/bigdatarepublic/key-takeaways-from-the-scala-days-keynote-702febe95c3d https://medium.com/bigdatarepublic/key-takeaways-from-the-sc...
  - modersky 8y ago
    Here's the current state: https://github.com/lampepfl/dotty/pull/4229 https://github.com/lampepfl/dotty/pull/4229
- Cyph0n 8y ago
  Implicits are very powerful when used correctly, but are terrible if not.
  - MrBuddyCasino 8y ago
    If "<feature> is very powerful when used correctly, but terrible if not": think long and hard before adding to a language.
    - lmm 8y ago
      Completely agreed. Implicits are the one place where Scala genuinely pushes the art of language design a bit beyond what's really possible; I expect future languages to come up with a better solution to the same problem. But in the meantime the things they enable - typeclasses, extension methods, the magnet pattern - are too valuable to do without, and we can't just sit around and wait for the perfect language to arrive. I wouldn't want to have any more language features that pushed as hard as implicits do, but one somewhat-experimental feature in a language is ok, just about. I don't think Scala is a thousand-year language, but it strikes the best balance given the current state of the art.
simon_o 8y ago
Not going to happen. I assume that the "added feature" section of the Dotty documentation and this blog entry have been written by different persons, because it's utterly impossible to reconcile those documents: More complicated features, more experiments, more NIH, more ad-hoc inventions, larger language footprint with more inconsistencies and surprising behaviors.

> Simplify where possible > eliminate inconsistencies and surprising behavior Oh dear god please.

by mavdi 8y ago

> Simplify where possible > eliminate inconsistencies and surprising behavior Oh dear god please.

I know on HN people like Scala but it's by far one of the language I hated the most when I worked with it. It's the complete opposite of Go, every time the Go team said no to a random feature, the Scala team said yes to that random feature. Scala feels to me like a kind of functional Perl.

deleted 8y ago
[deleted]
willtim 8y ago
The Scala team appear to have their hearts in the right place. They seek to empower their users and have respect for them. I can't really say the same about the Go team, based on at least one Google presentation I have seen. This isn't that surprising given the goals of the projects.
- realusername 8y ago
  I did not want to start a flame-war Scala vs Go, it's just that I like Go simplicity & readability (I also like Python and Ruby for those reasons as well) whereas I'm not a huge fan of the Perl feeling of Scala.
  - willtim 8y ago
    When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.
    - dragonwriter 8y ago
      Right: phrased differently, weaker abstraction power means recurring problems have to be addressed by documenting patterns with fill-in-the-blanks recipes, instead of reusable code libraries.
    - realusername 8y ago
      > hope that we can uncover some emergent higher-level structure, if it exists. That's exactly what I feel when I read Scala code, everything is a soup of custom operators, implicits and objects disguised like functions (or the opposite, you think it's an object but actually it's a function), it makes the code very hard to maintain and read. At least with Go, Python or Ruby your logic is in plain English, that makes it much easier.
      - lmm 8y ago
        I find the opposite. With Scala my logic can be plain English written in the language of the domain, because Scala makes it very easy to push out secondary concerns like authentication or audit logging or error handling out into the type system where they're still there, still managed, still checked by the compiler, still visible on mouseover/click-through in my IDE, but they don't have to obscure the straight-through happy-path business logic. Whereas in Go, all the secondary logic has to be right there, which clutters up the code and makes it harder to see the primary thread, and in Python or Ruby either you do the same thing or else the secondary logic has to work by invisible magic (metaclasses, exceptions, method_missing...) and you have no hope of ever being able to understand what's actually going on.
    - seanmcdirmid 8y ago
      This is analogous to the tension between “worse is better” and “perfect is the enemy of good.” One the one hand, elegance is impossible and one must settle early on inelegance. On the other hand, elegance is possible but one must be clever and spend a lot of time looking for it. These trade offs are really apparent in competing language designs (Scala, Go) and it isn’t clear which ones are the better ones to make.
  - 62747478182 8y ago
    You said [Scala] it's by far one of the language I hated the most. If you don't want to start a flame-war maybe you should change the tone of the comment.
_Codemonkeyism 8y ago
Scala is not for development, it's a research project.
- sulam 8y ago
  I don’t know is this is a good troll because I’m replying or a bad troll because it’s so obvious. There are Many people who work at many companies doing real development with Scala that goes all the way to production, handling real user traffic.
  - _Codemonkeyism 8y ago
    Yes we use Scala in production for >6 years. But I wonder how many companies would make the same decision again after their experience with Scala.
- dang 8y ago
  Please don't post flamebait to Hacker News.
- _Codemonkeyism 8y ago
  Foursquare lib migration to Scala 2.12, open since one year, we can't upgrade to 2.12 because of that dependency, https://github.com/foursquare/fsqio/issues/37 https://github.com/foursquare/fsqio/issues/37 They don't upgrade the open source version because their internal version depends on that open source version and they don't can't upgrade internally to 2.12. They can't upgrade because of several dependencies of their own, the last one Finagle. All of those although "cross compiles are no problem" as the default answer from the Scala development team on these issues.
lmm 8y ago
Can you be specific? This is a popular meme but it doesn't match my experience of Scala's language features at all (indeed I'd say Scala is very good at pushing things out into libraries or composition of existing features rather than making them language features), and often I find people with this kind of complaint were actually using a library with poorly named functions and mistaking its features for language features.
- realusername 8y ago
  I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Secondly, the implicit concept makes the code difficult to read. Then I would add that the differentiation between function & variable isn't always clear and sometimes you don't know what you call.
  - lmm 8y ago
    > I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them - no language is impossible to write bad libraries in. Certainly I wouldn't ever want to go back to a language that uses magically-named methods for operator overloading, like Python and Kotlin do - I find that far more confusing, I can never remember whether a * b is calling a.__times__(b) or a.__star__(b) or something else. I could get behind a language that disallowed symbolic names entirely, but I don't think I've seen one of those since Java. > Secondly, the implicit concept makes the code difficult to read. IDE support has gotten a lot better now (green underline to highlight any implicit conversion, expand out implicit parameters) which makes them much easier to work with. If you only use implicits in cases where you otherwise wouldn't do anything in code at all, they enhance readability - but of course if you use them to replace things that you'd otherwise make explicit then they can reduce readability. I don't have a good answer, because I definitely want extension methods, typeclasses with derivation, and the magnet pattern, but I haven't yet seen a language design that makes those things possible while disallowing the bad uses of implicits.
icedchai 8y ago
I share the same opinion of Scala. It definitely feels like it has too many features and is too complicated. Back in 2010 - 11, when I last worked with it, the compiler was also dog slow and IDE support was terrible. No doubt this has changed for the better, but it did ruin the language for me. I'll stick to Kotlin and Java, thanks.

MrBuddyCasino 8y ago

Also, no plans to get rid of implicits apparently. Sorry Scala, we're not gonna be friends.

pul 8y ago
Not fully, but implicit type conversion must be marked explicitly: https://medium.com/bigdatarepublic/key-takeaways-from-the-scala-days-keynote-702febe95c3d https://medium.com/bigdatarepublic/key-takeaways-from-the-sc...
- modersky 8y ago
  Here's the current state: https://github.com/lampepfl/dotty/pull/4229 https://github.com/lampepfl/dotty/pull/4229
Cyph0n 8y ago
Implicits are very powerful when used correctly, but are terrible if not.
- MrBuddyCasino 8y ago
  If "<feature> is very powerful when used correctly, but terrible if not": think long and hard before adding to a language.
  - lmm 8y ago
    Completely agreed. Implicits are the one place where Scala genuinely pushes the art of language design a bit beyond what's really possible; I expect future languages to come up with a better solution to the same problem. But in the meantime the things they enable - typeclasses, extension methods, the magnet pattern - are too valuable to do without, and we can't just sit around and wait for the perfect language to arrive. I wouldn't want to have any more language features that pushed as hard as implicits do, but one somewhat-experimental feature in a language is ok, just about. I don't think Scala is a thousand-year language, but it strikes the best balance given the current state of the art.

simon_o 8y ago

Not going to happen. I assume that the "added feature" section of the Dotty documentation and this blog entry have been written by different persons, because it's utterly impossible to reconcile those documents: More complicated features, more experiments, more NIH, more ad-hoc inventions, larger language footprint with more inconsistencies and surprising behaviors.