- > Python has convenient and good type design with str.join ignored by other languages.
Of course such non-discoverable and unintuitive design gets ignored everywhere!
We just established that even in Python the correct way to do it would be
but for that Python would need generic iterators on the language level…Iterable[str].join(str) -> str> For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.
So you're saying you've been able to implement custom Scala collection types, which is regarded some of the more difficult stuff one could possibly do, but you don't know how to implement an Iterator for your custom collection—as this is all needed for mkString to work? BTW, how did you implement the collection type at all without implementing Iterator for it? Your collection is not Iterable?
TBH, this does not sound very realistic. This sounds more like typical HN Scala FUD. People throwing around some vague, most of the time outright made up issues they've heard about somewhere about 10 - 15 years ago.
- That's obviously the wrong signature.
The semantically correct one is "Container[T : Printable].join(): String"; T must implement the Printable concept, but Python lacks concepts (or type-classes as these are alternatively called).
But this all is irrelevant as this is anyway not the signature of `str.join()` in Python. It's `str.join(Iterable[str]) -> str` there. With sane design and syntax it would just become `Iterable[str].join(str)`.
- > or Scala 2, yes, or there was the last I looked. Still the best Scala development experience by some margin, sadly.
I can't find it.
Could you link to that "best Scala development experience by some margin"?
All I know is that the Eclipse plugin is dead since about one decade. But maybe I just missed something.
> the integration/bridging piece is still flaky
What concrete issues do you have?
I'm using Metals on a daily basis and don't know about any such problems.
Could it be that the last time you've seen Scala (if you actually ever seen it at all) was about 10 years ago?
The discussions here on HN regarding Scala seem always massively dishonest, with a lot of people always spreading outright FUD for some reason I don't understand…
- I still don't get what you want to say.
Linking some GitHub repo does not explain anything.
What is "abuse", what is "magic" in this context?
- First of all nothing in the article is about optimization. Scala does not even have an optimizer…
It was about translation strategies and macro expansion.
But this makes no difference. You have all issues you just named exactly the same in so called "high level languages" as you have in C. C is in fact a high level language, and the code you write in C has not much in common with what the machine actually executes. The last time this wasn't like that is about 40 years ago.
1. Whether the C optimizer kicks in or not is pure dark magic. Nobody can tell from just looking at the code. The optimization techniques are way too complex to be understood ad hoc, not even experts can do that.
2. The difference between the optimizer doing its work, or instead the computer just verbatim executing whatever someone written down is hilariously large! Adding -O2 can make your code many orders of magnitude faster. Or it does almost nothing… (But like said, you can't know what will happen just from looking at the code, that's point again 1.)
3. You neither can express what the machine does in C. The machine does not execute anything like C. The last time it did is over 50 years ago… Since at least 30 years we have kind of JIT compiler in the CPUs which translate the result of compilation to ASM into the actual machine language. A modern CPU needs actually to emulate a computer that still works like a PDP-11 to match the C machine model even the real hardware does not look anything like a PDP-11 any more! You have only very indirect influence on the actual machine code when writing C. It's mostly about forcing the CPU internal JIT to do something, but you have no control over it, exactly as you don't have control over what for example the JVM JIT does. It's the exact same situation, just a level lower.
- The website is a private undertaking which started literally a few days ago. It's not some official complete tracker.
The point was to show that big corps are dependent on Scala, often at their core.
Scala is likely not for everybody, but where you need to write safe high level code there is more or less no alternative, not even on the horizon. Scala is simply very likely where Rust will end up after the honeymoon, when people realize that feature rich, safety first languages aren't for the mass market, where mostly only the cost of initial development counts.
- Examples and code snippets in the official docs of course default to the new syntax, making them well readable for all people accustomed to Scala's new syntax.
> If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs.
Stating this, which is not, and never was true creates the impression you're talking about things you have no clue about.
The point is: Removing braces really makes code much easier to read for people who get distracted by useless line noise!
> So reading unfamiliar syntax is literally harder. > […] > Source: have a degree in neurophysiology.
You need a degree to understand something such obvious? Never mind…
The point is: New syntax is only new in the first few hours of contact with it.
Anybody who uses more than one language knows that switching languages is in fact a bit distracting, but at latest on the second day you completely stop thinking about syntax, and than switching back to whatever was before is as hard as the previous switch to the current thing. Usually this happens already after a few hours for languages you already know.
As we're talking about neurophysiology: As a matter of fact filtering "noise" — irrelevant information — from sensory input is a hard task for the brain. So having less distracting useless noise in the input helps to concentrate on the stuff that actually matters!
Braces in code are 100% redundant, useless noise. The only reason they were added in the first place was to make code simpler to parse for computers, something that does not matter any more since many decades. So there is no rational reason any more to pollute code with useless, distracting noise.
- Scala 2's macros are compile time constructs. There is no runtime code generation / staging.
Scala 3's macros support staged compilation, so you can have macros which create code in later stages at runtime.
https://docs.scala-lang.org/scala3/reference/metaprogramming...
- It won't in general.
Doing so is a feature of high-end VM runtimes like the state of the art JVMs or JS runtimes.
- > However I agree that the syntax is a textbook case of trying to fix what ain't broke.
The great new syntax is the very reason I don't want to even touch Scala 2 any more.
The syntax change is the absolute highlight in Scala 3. It makes the language so much better!
The only real problem was that it happened so late; at least a decade too late.
- > The original language spec is the best thing the Scala devs ever made.
The overreaching majority thinks that Scala 3 is objectively much better than Scala 2 ever was. That's at least what you hear just everywhere, besides the occasional outlier by some Scala 2 die hards.
- Sure. All successful languages go into decades still stand.
Just see how great this worked out for Java (or Perl… ;-))!
/s
- What's so bad about it?
Why not try to learn it for good?
- The upgrade Scala 2 -> 3 is usually super smooth. The compiler does all the work, you just need to update your build config / dependencies.
The only exception is macros: If you used the experimental Scala 2 macros you need to migrate them to the new system which is completely different.
- > Lower-level languages don’t have this same problem to the same extent.
Of course they have.
If the computer would directly execute what you write down in what you call "low level language" this would be slow as fuck.
Without highly optimizing compilers even stuff like C runs pretty slow.
If something about the optimizer or some other translation step of a compiler changes this has often significant influence on the performance of the resulting compilation artifacts.
- > Especially when the libraries abuse magic language features (and far too many Scala libraries do)
Would you mind to explain what you mean?
- Just for context, a lot of people in the community think that this syntax change was the best thing that happened to Scala since its inception.
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…
- What are you missing currently?
- There's still a working Eclipse plugin? Does Eclipse now support LSP servers?
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.
That's also part of what I've said.
The point still being: Where you need a safe language there is no way around it, and Scala is still one of the very few options you have at all. Scala is in that regard indispensable.
> I feel that Scala 3 really hurt the community angle
I don't see that.
Everything relevant, besides Spark, is now on Scala 3, and this is already like that since a few years.
But I agree that Scala documentation / references / tutorials are to this very day lacking. This was and still is a real issue, and that's actually a very relevant one. I really hope this gets better with time.
The sub-optimal situation regarding docs does though not prevent people from starting new projects in Scala.
In fact Scala 3 is again ahead of the pack. It provides features not seen so far in any real world language and will almost certainly again pioneer the implementation of new language concepts in the large, as it did already in the past with its pragmatic approach to a OOP / FP fusion.
Just see for yourself what is currently happening:
https://softwaremill.com/understanding-capture-checking-in-s...