[throwaway89988]

Sorry, but Odersky is nothing like Wirth.

Scala failed hard because it is kitchen sink of every half baked feature someone wanted to write a PhD thesis about. The graphs of the interdependencies of the standard library are an excellent example of a totally insane design, the Scala data structures have been at least an order of magnitude slower than the JVM native ones. Don't get me started about the tooling, which is too slow for any real world projects. (The only ones I regularly see to use Emacs are Scala developers, because opening projects in an IDE like IDEA could take up to 30 min on high end workstations.)

Wirth valued clean design, speed and simplicity. Odersky wants to compete with C++ for complexity. As the article stated, for Wirth a feature would have to pay for itself regarding complexity, speed and usability. If someone can demonstrate how Scalas features came to pay for themselves, I would appreciate a pointer.

Finally... generics in Java are a shit show, thanks to type erasure. Fair enough, Odersky was probably forced for this implementation, thanks to backwards compatibility, still, nothing to be proud of.

[kagakuninja]

Type erasure is an interesting discussion, because functional programmers love type erasure. Consider the function:

    def foo[T](t: T): T    

If the function is truly generic, then we know nothing about the implementation details of T. The only meaningful implementation of foo is identity:

    def foo[T](t: T): T = t

From a FP perspective, T should be erased, and the programmer should not cheat and use reflection. The type signature should tell you much about what the function does.

I've used Scala professionally for the last 8 years. The tooling is fine, assuming you avoid exotic libraries like Shapeless. Compile times are fast enough that I don't think about it much, using IntelliJ incremental compilation. A full recompile of a micro service might take 30 seconds, whatever it is is not a big deal IMO.

> opening projects in an IDE like IDEA could take up to 30 min on high end workstations

This is insanely wrong. Maybe you are operating on experiences from 10 years ago? I have a new M2 MacBook Pro, and opening projects is quite fast. The first time you do it, it will resolve the SBT dependencies and index files. That can be done in the background, and is probably less than a minute for a typical project. Even my previous laptop could open projects quickly despite being 3 years old.

> the Scala data structures have been at least an order of magnitude slower than the JVM native ones

They are slower, but not an order of magnitude slower. Perhaps you are remembering the infamous email from the Yammer CTO that got leaked, but that was a long time ago, and the compiler and libraries have improved greatly since then.

But yes, in performance critical code, you can just switch to an imperative style and use Java collections.

I don't have time to explain the benefits of Scala features, but I'll just point out that other than implicits, many ML inspired features of Scala have made their way into modern languages, including Java, C#, Rust and Swift. Scala didn't invent those ideas, but repackaged them in a novel way.

[throwaway89988]

IMHO the keyword is 'microservice': Compile times of 30sec for a microservice are not acceptable for me, btw. The projects I am referring to were bigger, and the time to compile/open projects in IDEA where _not_ acceptable at all. (Btw.: I am speaking about Scala experts, not some new grads which didn't know what they were doing.)

Concerning your type erasure example, the id function obviously doesn't need to know anything about types. In the real world, types have traits/interfaces/expected attributes etc. and type erasure prevents the compiler to verify this when using binary dependencies, which is obviously _not_ what one wants in a statically compiled language.

[kagakuninja]

I just compiled our oldest, largest micro service, it was 17 seconds. This is a full recompile, which I rarely need to do, because IntelliJ has incremental compilation. If you have a giant mono-repo, then compile time becomes important.

I can only guess what these "Scala experts" were doing, there are certain language features that can slow your compile times, and libraries like Shapeless that leverage those features in amazing ways, but can kill your compile times.

Scala is a toolkit that enables amazing things, but you have to understand the trade-offs, both in terms of compile time, and understandability of the code.

>In the real world, types have traits/interfaces/expected attributes etc. and type erasure prevents the compiler to verify this when using binary dependencies, which is obviously _not_ what one wants in a statically compiled language.

Scala has ways of recovering the information, such as using context-bounds and type manifests. Scala can actually verify an amazing amount of constraints at compile time, but the more exotic tricks will increase compile time.

What you are complaining about are foot-guns that rarely happen in my 20 years experience with JVM languages (I think generics were added in Java 5, but still...)

[dragosiulian]

> it is kitchen sink of every half baked feature someone wanted to write a PhD thesis about.

Having been a PhD student in his lab between 2005-2010, I can attest that's not true. Language design was definitely Martin's prerogative. As a PhD student, a lot of time went into implementation efforts, and while several features did end up in PhD theses, the last word on what goes in the language was Martin's.

Scala was ultimately a research project, with ambitions to succeed outside of academia. As such, some ideas worked better than others (pattern matching and case classes vs specialization). As it became clear that the language was picking up in the industry (lead by Twitter around 2008), many of these experiments moved into compiler plugins, macro libraries or research forks.

> Sorry, but Odersky is nothing like Wirth.

I haven't known Wirth to venture into such broad statements, but given what's been written about the way he lead his lab, I would say there were many similarities: a strong bias for solid implementation work, the (bootstrapping) compiler as a litmus test for features or performance work. And yes, a focus on simplicity.

Unfortunately, simplicity is often confused with familiarity. What's simpler: having statement and expressions as separate concepts that don't mix well, or only expressions? Most people coming from C and Java would have internalized the dichotomy and find it (or at least, back in the day, found it) "complex" to think of every expression having a type ('void' vs 'Unit'). The same goes for the split between primitive and reference types vs a unified type hierarchy.

This is not to say Scala doesn't have its warts, and implicits (in particular, implicit resolution rules) combined with macros could lead to a lot of pain. Hopefully there are lessons learned there and Scala 3 is better.

> Scala failed hard

Far from obvious. Databricks has probably upwards 10MLOC of Scala code, and seem to be doing very well (https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala...). Plenty other examples.

Could Scala have been more successful? Undoubtedly. But it's far from a "hard failure". New languages have adopted many Scala features, so nowadays Scala is believed to pay for itself only when using pure-FP libraries. That's very unfortunate if you ask me, since I believe there's a pragmatic sweet spot that lies around the style best illustrated by Haoyi Li's ecosystem of libraries.

[throwaway89988]

Thanks for the inside story.

Let me elaborate: Scala failed hard in the sense, that it was IMHO a far superior language compared to Java around 2010 (! JDK 7/8 times) and basically is dead now for new projects (unless there are some die hard Scala fanatics on a team, and even they are moving for greener pastures), also see how Kotlin succeeds everywhere at the moment.

What I totally don't get is, that Scalas failure was _not_ surprising at all, and there were a lot of kind people giving constructive feedback, why Scala fails in the industry (example: https://gist.github.com/alexo/1406271):

- Slow compile times - No binary compatibility even between minor updates - Every feature under the sun was stuffed into Scala, making it impossible to transfer projects to 'industry programmers' w/o too extensive training - Tooling support (like IDEs) was extremely lacking/slow/bad - Not to speak about the community infights about the right way(TM) to approach a problem

Personal experience from me: Scala was too slow/cumbersome to use with subpar tooling. And I consider myself a target group: In love with FP but forced to deploy on the JVM. Besides my own experience, I saw teams of Scala developers fail to materialize any significant benefit in real world projects over 'dumper' programming languages, not even speaking about transferring Scala projects to non academic 'elite' teams.

I like some ideas in Scala 3 and IMHO it is sad that Kotlin (which is IMHO just syntactic sugar over Java) gets so much attention, but in the end Scala hat plenty of years to fix its problems and its failure comes as no surprise, because there was plenty of feedback. Are there still some Scala projects around? Yes, mostly Scala 2 because, surprise, libraries still don't have binary compatibility etc. For Scala 3 I have neither seen industry adaption or any enthusiasm from a wider community.

[bombcar]

This all sounds right to me - scala needs first class support for what it is doing in the JVM itself - which it doesn’t have. Trying to ASM scala is a pain.

[switchbak]

Come on now, Scala has its issues, but statements like "because opening projects in an IDE like IDEA could take up to 30 min on high end workstations" are just not true unless your project is straight up broken.