4 ms·

what did you resent?

Fiahil 6y ago
In no particular order: - the JVM - the tooling for writing with VSCode - SBT - NullPointerExceptions bubbling up from Java libs - the split between the functional programming community and the "Scala is just Java without ;" one - everything related to implicits (creation, resolution, etc) and everyone using them - the ability to write the same 0-100 loop with 4 different keywords and 3 different styles - the inability to enforce a coding style properly and consistently with a team of more than 1 engineer - too much people writing DSLs for no particular reason - ++, +:, :+, :++, ++=, _+_, ::, :::, _, `, <%, %, %%, %%%, <-, =>, :>, >:, (╯°□°)╯︵ ┻━┻, ., .., ... - compiler errors
- maattdd 6y ago
  - compilation time
  - zug_zug 6y ago
    Seriously. I modify a single line, in a single file, and the scala system takes 2-3 minutes to recompile at work. Apparently it spends over a minute inferring types! Hello! The types are EXACTLY THE SAME AS ALWAYS. Please cache the whole typing phase as a build artifact based on file/directory hashes. Maybe even make this cache source-control-safe.
    - benjaminjackman 6y ago
      I am curious if you are using SBT incremental builds? (putting aside how hard it can be to get and keep SBT working for a project ... I was the guy that had to do that so I know that pain quite well). Because in my experience with really large scala projects that should not be the case, unless you modify a file at the very top of the dependency tree. We used what I would call the package object predef pattern, which basically involved, rolling your own predef to have certain functions / extension classess / objects always in scope through package objects added to each sub-project. And the build would cross-compile both jvm scala and scalajs. It would not take more than a second or two unless one of those predef files were touched (which would fire off effectively a full rebuild).
      - zug_zug 6y ago
        Well, neither I, nor anybody at the startup I work at apparently (it would seem) has been able to figure it out. Out of curiosity, how many hours do you think it would take to get the compile time down? I wonder if we could find somebody to help us with that.
        funcDropShadow 6y ago
        At first I would try sbt-tmpfs, and then the largest factor in compile time imho are dependencies. Make sure that you split your project in submodules of semantically valid units. That reduce the amount of code that has to be analyzed. And then make sure that you don't have many unused imports. In every project I've been are some former Eclipse users that are accustomed to collapsing all imports and adding new ones automatically. They never look at their ever growing list of unused files that are searched, loaded, and parsed.
        benjaminjackman 6y ago
        It kind of depends on what you are looking for. It sounds like it's improving compilation times while you develop so you can get errors messages from the compiler and so on faster which SBT incremental compilation should help with. Are you guys currently using SBT? If so, is incremental compilation not working for some reason (or are you not aware of it?). In terms of time, it would really depend on the size of the project and what is currently in place. It could be a couple of hours to a few days. BTW my email is in my hn profile you want to discuss more privately.
        zug_zug 6y ago
        Yeah we are using SBT. I'm off this week, but next week I can try to see if this has legs. I checked your profile but didn't see an email.
    - valenterry 6y ago
      Upgrade your sbt version and make sure that whatever file you update is not (transitively) imported/used by every other file. If that doesn't help, check for excessive macro/typelevel usage. Incremental compile times should be seconds not minutes, something is probably wrong with your setup.
- MrPowers 6y ago
  There have been some great improvements in Scala tooling in recent years. Li Haoyi talks about all these new tools in the Hands-On Scala programming book. Some specific responses: * tooling for writing VSCode: the metals project is great: https://github.com/scalameta/metals https://github.com/scalameta/metals * NullPointerExceptions: those should be handled with Option/ Some / None * the inability to enforce a coding style properly - scalafmt is great for this and provides a "Go-like" automatic formatting experience https://scalameta.org/scalafmt/ https://scalameta.org/scalafmt/ * SBT - there are now alternatives like Mill: https://github.com/lihaoyi/mill https://github.com/lihaoyi/mill Glad you're happier with Rust, but know that Scala is a lot better now if you ever come back ;)
- esarbe 6y ago
  Yeah, the symbolic method names can be quite annoying and (often) make code unreadable. Especially ScalaZ went really overboard there. I'm happy to say that the convention is becoming more strict in this regard and symbolic method names are (mostly) discouraged [0]. [0] https://docs.scala-lang.org/style/naming-conventions.html#symbolic-method-names https://docs.scala-lang.org/style/naming-conventions.html#sy...
- SOLAR_FIELDS 6y ago
  I wrote Scala for three years or so professionally and agree with most of your points. A couple of comments though that haven’t been addressed by the sibling commenter who also addressed some of your points: - JVM is JVM I guess. You either love it or you don’t. I personally really enjoyed the access to the ecosystem so that was a major boon for me. - Gradle is just so much better than SBT in almost every way aside from simplicity. I found building Scala projects with Gradle to be quite straightforward and nearly every project that supports SBT also supports Gradle. - I agree about VSCode tooling but I do want to establish that there are actually really nice tools for writing code in Scala - specifically Jetbrains is quite great. I am not saying your point is any less worthwhile, only that I don’t want someone to read your comment and take away that there are no good code assistance tools for writing Scala. - Agree with the Java NPE’s. This is annoying - Entirely agree with implicits. The Scala team either needs to better educate people on how to use them or just tell people not to use them unless it’s a very specific circumstance. I cannot tell you how many times I’ve dived into someone else’s code and spent literally hours trying to coax the compiler to do something that was bizarrely prevented by a poorly thought out usage of implicits. - it is definitely possible to write “Scava”, and I wouldn’t really recommend a team adopting it without someone having at least a decent background in functional programming. Otherwise you might as well write Java if you are going to write imperatively. - Yes, I find that the usage of symbols in Scala is a bit excessive, but once you learn what they do it does feel more terse and concise. It doesn’t stray into the illegibility of Perl IMO. Overall it’s a nice language, fun to write in, but a bit frustrating at times. I wouldn’t use it personally at home but it does fill a nice niche professionally and it’s absolutely great for writing Spark code.
  - tasuki 6y ago
    We have recently switched from SBT to Gradle and I'm finding Gradle a lot more painful than SBT. For starters, SBT had a nice interactive shell, while Gradle takes quarter minute just to list the available tasks, after which it's another quarter minute to get anything else done...
    - SOLAR_FIELDS 6y ago
      Gradle is undoubtedly slower. However it’s at least 10x more capable of doing various things around building your app like testing, building images, publishing, etc. Like if I needed to build, fat jar, test and publish a multiproject repository I would almost certainly want to use Gradle over SBT. But Gradle is probably a bit overkill for a single entry point small app that does one thing and has minimal testing needs (though it can certainly do that!). You wouldn’t bring in a dump truck whenever a pickup would work just fine.

In no particular order: - the JVM - the tooling for writing with VSCode - SBT - NullPointerExceptions bubbling up from Java libs - the split between the functional programming community and the "Scala is just Java without ;" one - everything related to implicits (creation, resolution, etc) and everyone using them - the ability to write the same 0-100 loop with 4 different keywords and 3 different styles - the inability to enforce a coding style properly and consistently with a team of more than 1 engineer - too much people writing DSLs for no particular reason - ++, +:, :+, :++, ++=, _+_, ::, :::, _, `, <%, %, %%, %%%, <-, =>, :>, >:, (╯°□°)╯︵ ┻━┻, ., .., ... - compiler errors

maattdd 6y ago
- compilation time
- zug_zug 6y ago
  Seriously. I modify a single line, in a single file, and the scala system takes 2-3 minutes to recompile at work. Apparently it spends over a minute inferring types! Hello! The types are EXACTLY THE SAME AS ALWAYS. Please cache the whole typing phase as a build artifact based on file/directory hashes. Maybe even make this cache source-control-safe.
  - benjaminjackman 6y ago
    I am curious if you are using SBT incremental builds? (putting aside how hard it can be to get and keep SBT working for a project ... I was the guy that had to do that so I know that pain quite well). Because in my experience with really large scala projects that should not be the case, unless you modify a file at the very top of the dependency tree. We used what I would call the package object predef pattern, which basically involved, rolling your own predef to have certain functions / extension classess / objects always in scope through package objects added to each sub-project. And the build would cross-compile both jvm scala and scalajs. It would not take more than a second or two unless one of those predef files were touched (which would fire off effectively a full rebuild).
    - zug_zug 6y ago
      Well, neither I, nor anybody at the startup I work at apparently (it would seem) has been able to figure it out. Out of curiosity, how many hours do you think it would take to get the compile time down? I wonder if we could find somebody to help us with that.
      - funcDropShadow 6y ago
        At first I would try sbt-tmpfs, and then the largest factor in compile time imho are dependencies. Make sure that you split your project in submodules of semantically valid units. That reduce the amount of code that has to be analyzed. And then make sure that you don't have many unused imports. In every project I've been are some former Eclipse users that are accustomed to collapsing all imports and adding new ones automatically. They never look at their ever growing list of unused files that are searched, loaded, and parsed.
      - benjaminjackman 6y ago
        It kind of depends on what you are looking for. It sounds like it's improving compilation times while you develop so you can get errors messages from the compiler and so on faster which SBT incremental compilation should help with. Are you guys currently using SBT? If so, is incremental compilation not working for some reason (or are you not aware of it?). In terms of time, it would really depend on the size of the project and what is currently in place. It could be a couple of hours to a few days. BTW my email is in my hn profile you want to discuss more privately.
        zug_zug 6y ago
        Yeah we are using SBT. I'm off this week, but next week I can try to see if this has legs. I checked your profile but didn't see an email.
  - valenterry 6y ago
    Upgrade your sbt version and make sure that whatever file you update is not (transitively) imported/used by every other file. If that doesn't help, check for excessive macro/typelevel usage. Incremental compile times should be seconds not minutes, something is probably wrong with your setup.
MrPowers 6y ago
There have been some great improvements in Scala tooling in recent years. Li Haoyi talks about all these new tools in the Hands-On Scala programming book. Some specific responses: * tooling for writing VSCode: the metals project is great: https://github.com/scalameta/metals https://github.com/scalameta/metals * NullPointerExceptions: those should be handled with Option/ Some / None * the inability to enforce a coding style properly - scalafmt is great for this and provides a "Go-like" automatic formatting experience https://scalameta.org/scalafmt/ https://scalameta.org/scalafmt/ * SBT - there are now alternatives like Mill: https://github.com/lihaoyi/mill https://github.com/lihaoyi/mill Glad you're happier with Rust, but know that Scala is a lot better now if you ever come back ;)
esarbe 6y ago
Yeah, the symbolic method names can be quite annoying and (often) make code unreadable. Especially ScalaZ went really overboard there. I'm happy to say that the convention is becoming more strict in this regard and symbolic method names are (mostly) discouraged [0]. [0] https://docs.scala-lang.org/style/naming-conventions.html#symbolic-method-names https://docs.scala-lang.org/style/naming-conventions.html#sy...
SOLAR_FIELDS 6y ago
I wrote Scala for three years or so professionally and agree with most of your points. A couple of comments though that haven’t been addressed by the sibling commenter who also addressed some of your points: - JVM is JVM I guess. You either love it or you don’t. I personally really enjoyed the access to the ecosystem so that was a major boon for me. - Gradle is just so much better than SBT in almost every way aside from simplicity. I found building Scala projects with Gradle to be quite straightforward and nearly every project that supports SBT also supports Gradle. - I agree about VSCode tooling but I do want to establish that there are actually really nice tools for writing code in Scala - specifically Jetbrains is quite great. I am not saying your point is any less worthwhile, only that I don’t want someone to read your comment and take away that there are no good code assistance tools for writing Scala. - Agree with the Java NPE’s. This is annoying - Entirely agree with implicits. The Scala team either needs to better educate people on how to use them or just tell people not to use them unless it’s a very specific circumstance. I cannot tell you how many times I’ve dived into someone else’s code and spent literally hours trying to coax the compiler to do something that was bizarrely prevented by a poorly thought out usage of implicits. - it is definitely possible to write “Scava”, and I wouldn’t really recommend a team adopting it without someone having at least a decent background in functional programming. Otherwise you might as well write Java if you are going to write imperatively. - Yes, I find that the usage of symbols in Scala is a bit excessive, but once you learn what they do it does feel more terse and concise. It doesn’t stray into the illegibility of Perl IMO. Overall it’s a nice language, fun to write in, but a bit frustrating at times. I wouldn’t use it personally at home but it does fill a nice niche professionally and it’s absolutely great for writing Spark code.
- tasuki 6y ago
  We have recently switched from SBT to Gradle and I'm finding Gradle a lot more painful than SBT. For starters, SBT had a nice interactive shell, while Gradle takes quarter minute just to list the available tasks, after which it's another quarter minute to get anything else done...
  - SOLAR_FIELDS 6y ago
    Gradle is undoubtedly slower. However it’s at least 10x more capable of doing various things around building your app like testing, building images, publishing, etc. Like if I needed to build, fat jar, test and publish a multiproject repository I would almost certainly want to use Gradle over SBT. But Gradle is probably a bit overkill for a single entry point small app that does one thing and has minimal testing needs (though it can certainly do that!). You wouldn’t bring in a dump truck whenever a pickup would work just fine.