> 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.
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.
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.
I’m a very happy user (Firefox and iOS). Switched from LastPass about a year ago (found it on hacker news back then) and never looked back. I can’t compare it to 1Password, since I never used it.
What's most annoying is that local companies make exactly the same mistakes. Digitec, Migros or Galaxus they all default to German. And I use Accept-Language as well. I understand this is a special case and the heuristic works in most cases, but when you're a Swiss company operating in Switzerland the odds are slightly different. Only 63.5% are native German speakers.
But google is by far the worst, since I'm always logged in but switches languages based on IP.
The Scala compiler is indeed slow, mostly because it has to do a lot more work than the Java or Go compiler. However, in my experience Sbt's incremental compilation works well for small to medium sized projects. Beyond that we need a bigger hammer, and we're working on a parallel (and later, distributed) Scala compiler [1].
The official release is not yet announced, neither on scala-lang.org nor on the scala-announce mailing list. Your move seems overly aggressive. Why would you publish them before the maintainers?
I haven't announced anything and I haven't submitted this link to HN. I just added a comment to let people know that I might read and try to answer questions if they have any.
This submission's title at least reads "release notes" and not "2.12 released" like the submission yesterday, when people found the artifacts on Maven.
You might want to give the Eclipse Scala IDE a go. It's pretty easy to get started even if you're unfamiliar with Eclipse (watch the getting started video): http://scala-ide.org/download/current.html
Disclaimer: I'm the tech lead of the Scala IDE for Eclipse project
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.