what did you resent?
- 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
* tooling for writing VSCode: the metals project is great: 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/
* SBT - there are now alternatives like 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 ;)
- 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.
I picking this up, because it was also mentioned in a sibling comment. Let's continue this discussion.
It doesn't matter if we have multiple alternative to SBT, some more usable than other. Rust has one package manager (+build tool +distribution tool): Cargo. That's it. Whatever the project you just cloned and whatever the platform you're using, `cargo build` is going to compile it. Now, if every Scala project starts using a different package manager, that's going to be a problem. The best solution would have been to make SBT usable without a prescription from your doctor. It didn't happen. That's okay, programming languages are just tools anyway, and they get replaced too.
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...
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.
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#sy...
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.
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).
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.
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.
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.
Incremental compile times should be seconds not minutes, something is probably wrong with your setup.