161–170 of 195 posts
Earlier quoted context omitted.
Java's new features are always going to be on paper. The ecosystem, with all its legacy code, is always going to be a decade behind. And if you are starting a new project, why would you pick Java over Kotlin?
It’s a lot cheaper to hire for Java than for „modern“ languages.
And yes, "you get what you pay for" is part of this.
Earlier quoted context omitted.
Benchmarking requires a bit of different setup than the rest of the testing, especially if you want down to the ms timings. We have continous benchmarking of one of our tools, it's written in C++, and to get "same" results everytime we launch it on the same machine. This is far from ideal, but otherwise there be either noisy neighbours, pesky host (if it's vm), etc. etc. One idea that we thought was what if we can ru…
https://en.wikipedia.org/wiki/Hardware_performance_counter can help with noisy neighbors. I am still getting into this.
Earlier quoted context omitted.
I tried getting into Scala several times and kept going back to Clojure. Unless you are into type system minigames Clojure has many of the things Scala advertises but without the dumptruck of Scala overhead and complexity. Another commenter briefly touched on this but it's a language made by academics for academics to play with language design. It was a little weird it blew up in industry for a while.
> It was a little weird it blew up in industry for a while. It never went away. It only got more: https://business4s.org/scala-adoption-tracker/
I don't see the chart with changes of number of companies using Scala over time. But even without the chart - if after 15 years there are less than 300 companies in total, that's a bit depressing.
Of course legacy never goes away, and even 20 years down the line there will still be some demand for Scala programmers. Similar to how Cobol still lives on. But in my experience the language isn't growing anymore, even slowly dwindling in userbase. And this became way worse after Scala 3 mess.
Earlier quoted context omitted.
It was absolutely amazing how stubborn and ridiculous the whole bracket-less syntax change was handled. It was basically a dictatorial decision that they pretended to be a community decision. It was just pushed and tons of people voiced their disapproval. In the end it was "so bad so sad you can always reenable brackets". They did it to try to appeal to Pythonists.. turns out that wasn't why Pythonists didn't use sca…
> In the end it was "so bad so sad you can always reenable brackets". This is not true. Nobody ever proposed to replace the old syntax! The new syntax was, and is, optional, and that's exactly like designed from the very beginning.
If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs. But it wasn't done right from the start, and when that was finally added most of the damage was done, people already lost interest.
I understand that removing braces might feel harmless - but it really makes the code harder to read for people that use braces all the time.
If someone's brain is accustomed to seeing braces everywhere, reading code with them becomes almost automatic, handled by "low-level" parts of the brain. If the syntax is changed, then "low-level" brain areas have to pass work to "higher-level" areas, which increases energy requirements and processing latency. So reading unfamiliar syntax is literally harder.
Incidentally, that's also why many people are so picky about grammar - grammatical errors make the text noticeably harder to read.
Source: have a degree in neurophysiology.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Hardware_performance_counter can help with noisy neighbors. I am still getting into this.
Yes, that can help with detecting how much cpu was actually used during the run. But it doesn’t influence benchmark results. Not sure how exactly to use it for doing subsequent runs and comparing final performance. Then this needs to be extrapolated to final performance in production.
> After upgrading the library, performance and CPU characteristics on Scala 3 became indistinguishable from Scala 2.13. Checking the bug mentioned, it was fixed in 2022. So, I’m wondering how one would upgrade to scala 3, while keeping old version of libraries? Keeping updated libraries is a good practice (even mandatory if you get audits like PCI-DSS). That part puzzled me more than the rest.
> Keeping updated libraries is a good practice First, the "good practice" argument is just an attempt to shut down the discussion. God wanted it so. Second, I rather keep my dependencies outdated. New features, new bugs. Why update, unless there's a specific reason to do so? By upgrading, you're opening yourself up to: - Accidental new bugs that didn't have the time to be spotted yet. - Subtly different runtime chara…
You can instead document exceptions for why all those vulnerabilities doesn't apply to your app, but that's sometimes more trouble.
Earlier quoted context omitted.
Everything is up to date with the new syntax as far as I'm aware. Also, the compiler and scalafmt can rewrite one to the other. A project can pick whatever style it wants and have CI reformat code to that style.
> Everything is up to date with the new syntax as far as I'm aware. The Eclipse plugin isn't, and none of the newer IDE integrations is reliable.
The most reliable Scala IDE is currently Metals (in VSCode, but other editors work, too). Metals uses directly the compiler for all code intelligence so it's as reliable as the compiler itself.
Earlier quoted context omitted.
What I don’t get because there is LSP and BSP support. What else is needed to get support for scala 3 from an IDE? Obviously, Kotlin coming from Jetbrains will make it receive a lot more love and first class support.
Parity with Scala 2 development experience, which was lacking a year ago.
Earlier quoted context omitted.
Sorry, I'm coming from C++-ish background - can anyone explain what's going on :)
Scala 2's syntax is mostly Java/C-style with a few peculiarities. Scala 3's optionally allows indentation based, brace-less syntax. Much closer to the ML family or Python, depending on how you look at it. It does indeed look better, but brings its share of issues.[1] Worse, a lot of people in the community, whether they like it or not, think this was an unnecessary distraction on top of the challenges for the entire…
Also the silent majority thinks that the people who still lament over that change are just a very vocal minority.
Almost all Scala 3 code uses the new syntax, no matter how loud a few people cry. Similar situation to systemd on Linux…
The takeaway of upgrading your libraries when upgrading major language and framework versions applies beyond Scala. Especially when the libraries abuse magic language features (and far too many Scala libraries do) or otherwise integrate deep into the framework/language.
Would you mind to explain what you mean?