Brian Goetz

> Sun could have (and should have) copied them in Java, and I don't know why they didn't.

I had always assumed that, initially, Sun was distracted by the Oracle acquisition. But there's also a philosophical / design principle in Java which tends towards being conservative about what features they add, for instance see this discussion thread [1,2] about adding a Pair class into java.util. Given the wide deployed footprint of Java across platforms, one can even sympathize with this.

There is also the central Java philosophy (which also influences the Pairs/Tuples discussion) that "names matter"[3]. I would argue that in my experience, in some contexts, especially in the server-side enterprise context where Java is very popular, names don't always matter, which is why developers keep asking for Pairs and Tuples and keep complaining about Java's verbosity -- because Java forces them to care about things they don't really care about (another great example is checked exceptions).

C# to me is like a "mirror universe" Java, where the underlying philosophy is to add features if they make a developer's life simpler. As a result, C# "feels" nicer to use and in the right hands can result in (subjectively) nicer code. In JVM land, this also explains why so many developers like Kotlin.

In reality, developers can write unreadable code in both languages. Although my main criticism of Java is that they probably shouldn't be that dismissive of Lisp, there are some good ideas there, as…

I agree with most of your comment. Thanks for writing it down!

First, the agreement:

Yep, structs are a VM thing. We are very excited about Project Valhalla (http://cr.openjdk.java.net/~briangoetz/valhalla/ etc).

Refactoring in a dependently typed language is hard. There's room for improvement. Scala-refactoring is a great example of community contribution.

Scala style checking is on our roadmap for 2.12. I'm procrastinating reviewing the first PR for the tool (abide) right now.

Finally, I would like to clarify we are doing everything we can think of to encourage the community to help shape the design and implementation of Scala. We publish roadmaps, review (and even rework) community PRs, do most of our team comms publicly (we are a distributed team), solicit proposals for language changes (e.g., http://docs.scala-lang.org/sips/pending/42.type.html). We spun out library modules that are now being maintained by the community. I spent last year simplifying the core build, so that we can move to a standard sbt build this year, which should also make it easier to contribute. As a first step towards updating the [spec](http://scala-lang.org/files/archive/spec/2.11/), we converted it to [markdown](https://github.com/scala/scala/tree/2.11.x/spec).

That said, I think it's only natural that the Scala committers on Typesafe's payroll are more inclined to work on customer support issues / internal Typesafe support. We always try to strike a fair balance to give back to the…

I really like (and work in) Scala, and Scala native is an interesting project.

However, its use cases seem to be encroached on all fronts.

If you want native, performance and don't need the JVM ecosystem, Rust and go both take very different but good approaches to that problem. I would have a hard time recommending Scala Native over Rust.

If you want browsers, Javascript is rapidly evolving and becoming a better lanuage. Typescript adds an excellent type system given the constraints its working with. Webassembly opens the door to use your own favorite. I would have a hard time recommending Scala.js over Typescript.

If you want JVM, Java is adopting traditional Scala killer features at a glacial pace, lambda's in 8, pattern matching in 11+ [1], Data/Case classes in ? [2], but adopting them nonetheless. Kotlin has succesfully performed a Blitzkrieg maneuver on Scala's "better Java" territory and has full support from Google in Android. It's also much more approachable for Java devs. I have a hard time convincing JVM devs that Scala is a good choise over Kotlin. At the place I work in all new projects are Kotlin, and Scala is used for the projects that were started in it.

Python and R are mainstays in the data science world, with Spark serving as a sort of Scala bastion.

I like scala, and follow its developments and 3.0 (Dotty) version somewhat, but I am slowly seeing it dwindling into irrelevance.

[1] http://openjdk.java.net/jeps/305
[2]…

That is by design (https://cr.openjdk.java.net/~briangoetz/amber/datum.html)

Why not "just" do tuples?

Some readers will surely be thinking at this point: if we "just" had tuples, we wouldn't need records. And while tuples might offer a lighter-weight means to express some aggregates, the result is often inferior aggregates.

Classes and class members have meaningful names; tuples and tuple components do not. A central aspect of Java's philosophy is that names matter; a Person with properties firstName and lastName is clearer and safer than a tuple of String and String. Classes support state validation through their constructors; tuples do not. Some data aggregates (such as numeric ranges) have invariants that, if enforced by the constructor, can thereafter be relied upon; tuples do not offer this ability. Classes can have behavior that is derived from their state; co-locating state and derived behavior makes it more discoverable and easier to access.

For all these reasons, we don't want to abandon classes for modeling data; we just want to make modeling data with classes simpler. The major pain of using named classes for aggregates is the overhead of declaring them; if we can reduce this sufficiently, the temptation to reach for more weakly typed mechanisms is greatly reduced. (A good starting point for thinking about records is that they are nominal tuples.)

Hey, sorry if it came across as condescending, I really didn't mean it to be. All I wanted to say was I don't think the choice is obvious and leave a few googleable buzzwords for anyone interested to go read up more on it.

I don't think I took a stance pro/anti erasure other than to say I think it's way more complicated a topic than it might seem (maybe not to you, but likly to others!) and it's worth reading up on. AND I didn't want to dig up old HN comments/posts to confirm what I'd read about it, so I was necessarily vague.

Edit 1:
For instance, I vaguely recall that Scala head trouble porting to C# because of erasure related stuff. But I'm not genius enough to remember the details so I didn't get into it.

Edit 2: So I dug one up: https://cr.openjdk.java.net/~briangoetz/valhalla/erasure.html
And posted here https://news.ycombinator.com/item?id=33171832

Edit 3: Other good conversations on it: https://news.ycombinator.com/item?id=18679684
https://news.ycombinator.com/item?id=13051594

Again, my only stance is that it's a surprisingly deep topic — Not making any claims!

I meant that it's worked out pretty well for Java. ML -- one of my favorite languages, alongside Java and a couple of others -- has also managed to avoid being used by anyone, really. But look at Java now: it has generics and higher-order functions, and it's getting a uniform treatment of types (Project Valhalla), and pattern matching [1]. And so while ML introduced those features in a research context, Java is the language that has made and will make the world actually use them. Being ahead of your time is often just as much of a mistake as being behind (as far as product design goes).

As to the question of "holding programming back," it is yet to be seen how much of an impact these features have in practice. Same goes for what ML "lacked." I personally like some features more and some less, as do you, but I don't think anyone knows which programming language features really push programming forward.

[1]: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html