1. Why not just call these "structs"? Everyone knows what a struct is. Also making "struct" a reserved keyword is less likely to cause issues than "record";

2. I get that these are trying to be simple but why can't I compose records from other records? I guess I can have a record member of a record?

3. I couldn't see if records can be passed entirely on the stack like primitive values can. This would be huge. I seem to recall there was some effort to add this to Java but I'm not sure whatever happened to that. It probably added a ton of complexity.

2. Yes, you can make records of other records.

3. Not yet, but Project Valhalla will be bringing inline types to Java https://wiki.openjdk.java.net/display/valhalla/Main

https://github.com/dotnet/roslyn/blob/features/records/docs/...

It's a struct or class but you only define the data members and the compiler auto-generates boiler plate like constructors, equality tests, etc.

Records are shortcut syntax (and some runtime improvements) for a specific category of simple classes but they remain a heap-allocated reference type so calling records "struct" would be extremely misleading and would preclude (and / or make even weirder) the eventual inclusion of user-defined value types.

Struct was a suggested name.

And encourages immutability.

2. Yes, it is widely accepted that a has-a relationship is the proper way to compose data. Using inheritance for composition is bad practice.

3. The article mentions inline classes, which is what the proposed value type feature is called these days. Presumably many or most record types will be inline if and when they're both implemented in some future Java version.

If you have two records {a: 1, b: 2}, those are equal because they are the same.

If you have two structs {a: 1, b: 2}, those are also equal but they are separate instances that consume more space. The comparison is recursive.

It's more like how string works in Java and most modern languages with constant pools - behaves like values but only takes constant space.

https://cr.openjdk.java.net/~briangoetz/amber/datum.html

1. You can't change a record after the fact because if you do it's no longer reliable, it's been tampered with :)

2. Yes, existing records only. You can always create a new record pointing to the old or any other record.

3. Hope not, would make it unpractical to handle verbose facts.

I guess clojure really twisted my mind ;)

I am thrilled that algebraic datatypes (effectively the combination of records and sealed classes) are finally entering mainstream consciousness and that statically typed languages all over the place are starting to adopt them.

This is all in service of private constructors. You effectively cannot have private constructors for data classes in Kotlin because the copy method remains public and cannot be "turned off." `sealed abstract case class` in Scala gets rid of that.

Private constructors for record types is a fantastic light-weight way of incorporating runtime checks into compile-time types.

[0] https://openjdk.java.net/jeps/169

[1] https://dzone.com/articles/valhalla-lw2-progress-inline-type...

[2] https://wiki.openjdk.java.net/display/valhalla/Main

Fingers crossed Java never implements the `implicit` keyword...

[1] - http://learnyouahaskell.com/making-our-own-types-and-typecla...

I'm sure that there's some kind of purity to them, but the fact that a two records can't share field names ends up making them incredibly difficult to use for anything practical. Granted, using the makeFields function with Lenses allows you to kind of avoid the clashing, but that in itself feels like somewhat of a hack.

They're essentially just syntactic sugar for a standard product type with auto-generated functions for access and update. Unfortunately those functions come with foot guns. Here's two:

1. As you pointed out, clashing field names (since fields don't truly exist but are rather functions)

2. Partiality of the generated functions if you have multiple constructors for a type, at least one of which is a record.

Lenses are great, but would benefit from first-class integration as the "blessed" way of interacting with records (this hopefully would also reduce their learning curve).

One of my top wishes for Haskell is proper row types a la Purescript. Purescript records and polymorphic variants are amazing. I would absolutely love if this https://github.com/natefaubion/purescript-checked-exceptions was possible in Haskell.

I'm not super familiar with Purescript, so I can't comment on the row types; are they more-pleasant than Haskell's?

  myValue { field0 { subField0 { subSubField0 = 5 }}}

  -- forall x here means that our record can have other fields
  resetName :: forall x. { name :: String | x } -> { name :: String | x }
  resetName itemWithName = itemWithName { name = "Default" }

  -- Notice how Person is just a type synonym!
  -- And there's no data constructor
  -- { name :: String, id :: Int } is a type, not just a constructor
  type Person = { name :: String, id :: Int }

  type Pet = { name :: String, owner :: Person }

  bob = { name : "Bob", id : 0 }
  
  doggy = { name : "Doggy", owner : bob }

  -- Look they both work!
  bobReset = resetName bob

  doggyReset = resetName doggy

  -- And no clashes, because records are a first class type declaration
  bob.name == "Bob"
  doggyReset.name == "Default"
  

  newtype TextTooShort = ...
  newtype TextNotValidASCII = ...

  findFirst5CharWord :: forall e. String -> Either (TextTooShort + e) String

  asciiNumberRepresentation :: forall e. String -> Either (TextNotValidASCII + e) (Array Int)

  processString :: forall e. String -> Either (TextTooShort + TextNotValidASCII + e) (Array Int)
  -- No lifting or wrapping of intermediate errors required!
  -- All the types still unify!
  processString = findFirst5CharWord `andThen` asciiNumberRepresentation

  -- But you still get exhaustivity checking!
  displayString :: String -> String
  displayString input = case (processString input) of
    Left TextTooShort -> "You didn't give me enough text!"
    Left TextNotValidAscii -> "Whoops no ASCII rep exists!"
    Right arrayOfInts -> show arrayOfInts

For example in OO languages `obj.func(1, 2)` will typically require the compiler to know the type of obj before knowing which func method is being referred to here.

In Haskell however the equivalent expression is `func obj 1 2`. The compiler has already performed name resolution and knows exactly what func is. So that when doing type-checking, it is not only possible for typing information to propagate from object to method, but also from function to object. That is to say, it is possible that the compiler initially knows what type func has, but has no idea what type obj has; it will only do so after type inference using the type of func.

This makes type inference more general and more elegant. I suspect it also makes the implementation of name resolution easier. Unfortunately as you have pointed out, it's practically more of a nuisance.

Also note that this applies to more than just names of fields associated with a type; it even applies to type names associated with a type. For example if you have

    class G a where
      data N a :: *

    class G {
    public:
      class N;
    };

  data Person = Person {
    id :: Int,
    name :: Text
  }

  data Account = Account {
    id :: Int, # Oh no! Name clash
    amount :: Int
  }

  id :: Amount -> Int
  id (Amount actualId _) = actualId

For the partiality:

  data AllowedItems = Person { id :: Int, name :: Text} | JustANormalInteger Int

  name (JustANormalInteger 5) # Blows up at runtime

The workaround for clashing is to prefix your fields with your type name (luckily Haskell still has module namespaces so you don't need a globally unique name, just one unique for your module).

The workaround for partiality is to disallow a type with a record to be anything other than that record (e.g. disallow JustANormalInteger or require that Person {...} must first be an independent type before it can be used in AllowedItems).

The talk of lenses is a way to generalize the notion of field accessors and talk about the "path" generated by a series of field accessors in a first class way. E.g. you might imagine that in a standard OO language

  myClass.field0.subField0.subSubField0

Moreover, if you can talk about the paths through a class in a first-class way, what's to say that this path must actually correspond to a true field in a class? It could just be anything "field-like." For example:

  lens = integer.lastDigit.leastSignificantBit
  set(345, lens, 0) // Yields 344

Because you have now removed the need for true "fields," lenses are one strategy to get around the hackiness of fields in Haskell and in fact in many ways represent an advance in expressiveness over "true" fields (although they suffer from not really being integrated into the language in the way faux-fields are currently in Haskell).

That is awkward sometimes yes. Record fields are functions, and you can't have two functions with the same name in the same namespace.

You can, however, use namespaces to import two separate modules with conflicting names. It does mean you have to define the two different records in two different modules.

If, you want different records to have common fields because they are conceptually related, you probably want to use type classes.

I'm not a fan of ad-hoc typeclasses. I know that various approaches in modern Haskell advocate for them, but I think that ad-hoc typeclasses are a smell for overuse of typeclasses when plain-old data types should suffice.

I am a very big proponent of demanding that typeclasses have associated laws. Otherwise you can descend into the same hierarchy mess that plagues statically-typed class-based languages. And sometimes you just want to have different fields be named the same thing without an underlying profound relationship between the two.

My favorite usage is probably in a typesafe Query engine that several people[1] built at Foursquare that is a lot better than what you can find in the java world.

  Venue.where(_.closed eqs false)
       .orderAsc(_.popularity)
       .limit(10)
       .modify(_.closed setTo true)
       .updateMulti

https://github.com/foursquare/rogue

1. Hi Jorge, Liszka & Neil!

The best case scenario is that they aren't instantly horrified / confused / repulsed.

implicit is one of them

More often than not Java programming just consists of throwing gang signs on your keyboard for your Ide to create tons of boilerplate.

Well case classes can implement traits, might have a companion object and can (poorly) replace enums.

Scala sometimes seems to not need standard classes.

Other languages like go, rust or c can do just fine without classes at all.

There will be new syntax, but otherwise the underlying semantics will remain the same; it's just the implicit keyword itself and the kitchen sink of functionality that it provides in Scala 2 will be split up into new (soft) keywords like "given foo(using: Bar) = ..." rather than "implicit def foo(implicit bar: Bar) = ...", along with "extension listOps of" replacing "implicit class ListOps ...".

The community isn't united over the proposed changes (mostly due to migration concerns it seems), but overall it looks like a nice improvement over the status quo, particularly around typeclass definitions.

Now, Java only adds contextual keywords. Which are basically a sequence of Java letters that are tokenized as a keyword in certain contexts but as an identifier in all other contexts. var, record, inline, module, ect. are examples hereof.

You can read more about it in this JEP Draft about "keyword management for the Java Language": https://openjdk.java.net/jeps/8223002

At what points in a valid legal Java program could you have previously written record, where it would now conflict with this keyword in the locations where it is valid?

Map<String, String> record = getSomeData();

This should no longer be valid if record is a keyword?

Keywords are context dependent nowadays. In the context you've provided record would not be treated as a keyword.

    boolean isRecordStart() {
     if (token.kind == IDENTIFIER && token.name() == names.record &&
            (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) ||
             peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) {
          checkSourceLevel(Feature.RECORDS);
          return true;
    } else {
       return false;
   }

Java 2: strictfp

Java 4: assert

Java 5: enum

Java 9: module, requires

Java 13: yield

Java 15: record

Now my local Java dev env is only Java 8, but I'm not allowed declare

String enum = "foo";

which would have been valid prior to its addition as a keyword.

module, requires, yield, and record are not reserved words, and can still be used as names for members etc.

This isn't true. It isn't listed in the list of keywords in Section 3.9 of the 1996 Java specification.

Nope, i had to patch a bunch of codes because enum was not a reserved keyword until it was introduced in Java 5.

  (x,y) = getXY();

  record Coord(int x, int y) {}
  Coord coord = getXY();
  // access as coord.x, coord.y

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.)

But the pain remains the same in client code. Because api's are written once, but used many times, it is more important to make client code simple than api code.

In mathematics and programming, tuple content is accessed by position, not by name. e.g. The arguments in method/constructor invocation form a tuple - so there is precedent, even within java itself. Note that callers (clients) address arguments by position, and callees address them by name (api's).

There'a a very similar passage in the article to the one you quoted. Regarding nominal vs structural there, a better example is that java's class system is nominal.

"records" are nominal in that they have a class-like name, and also their content is accessed by name. Tuples are structural (not named), and access by position (not name). So I think records are not really "tuples".

1. when assigning to a variable, type inference is easy, because can't subclass records, so can omit type ceremony. So, although nominal, client can treat as structural.

2. with standard IDE completion/lookup, user need't know or enter the exact accessor names. So, the assigned variable acts like a namespace.

This mightn't be perfect, because appropriate names for the client's usage can differ from what is appropriate from the api's perspectice. (with tuples, user can name to suit their purpose).

  (lo, hi) = getLim();

  Lim lim = getLim();
  lo = lim.minimum;
  hi = lim.maximum

Yeah, this in JS:

    obj = {a: 1, b: 22, c: 333}
    const {b, a} = obj

    a_tup = function_returning_tuple()
    x = first(a_tup)
    y = second(a_tup)

  lim = getLim();
  const {minimum: lo, maximum: hi} = lim;

I thought multiple return was more interesting in the context of multiple possible types: like a type in case of success and one in case of failure (Either in Haskell, Result in Kotlin and Rust).

This type of type is a sum type a.k.a. a tagged union, you could think of as Enum types where each item can have a payload.

This comes in really handy and allows Kotlin not to (ab)use exceptions for non-fatal errors.

I never had the problem with returning several objects at ones, I would simply write a class that embeds them (and in J14 I can write a record).

That’s or (another) one in case of failure, and not multiple return values. It returns a single value.

”I never had the problem with returning several objects at ones, I would simply write a class that embeds them”

One man’s “simply” is another man’s “ugly boilerplate” or “unnecessary production of garbage objects”.

You could similarly ”simpler write a class that embeds either of them”, like this:

   class AorB {
     private final Boolean itsAnA;
     private final A a;
     private final B b;
     public AorB(A aa) {
       a = aa;
       b = null;
       itsAnA = true;
     }
     public AorB(B bee) {
       a = null;
       b = bee;
       itsAnA = false;
     }
     ...
  }

The pattern could be used commonly, and clean-up heaps of code, and remove exception's hard-to-wrap-yr-mind-around flow jumps/etc, that I do hope for both tagged unions and match switches on them to be introduced. Some are already demo features IIRC.

That's not a "multiple return", that returns a single value which is either one type or the other. Although some languages do implement it via MRV by necessity (e.g. Common Lisp, Go, Erlang).

The "either values", or sum types/ tagged unions I mentioned, are the thing that Java really lacks (and because of that the exception system got heavily abused IMHO).

Of course this is not the case for all enum types. But option / either / result, definitely.

https://github.com/dotnet/csharplang/blob/master/proposals/r...

Come on guys!

1. I don't really like this immutable approach, I want setters too.

2. I don't need those autogenerated equals/etc implementations, it's just code bloat. May be it's OK to introduce some syntax to automatically generate them like `String toString() default;` but it should not be implicit.

3. It uses non-standard getter syntax. Java developers used `getProp()` forever, now it's `prop()`. Shall we rewrite old classes or tools? Shall we live with two different styles in one codebase? Both approaches are bad.

This feature looks very out of place in Java. I hope that it'll be removed in the next release and replaced with something more compatible with old code. I waited forever to get short property syntax in Java and got unusuable feature in the end. I don't want to migrate to Kotlin just because of properties.

> I don't need those autogenerated equals/etc implementations, it's just code bloat. May be it's OK to introduce some syntax to automatically generate them like `String toString() default;` but it should not be implicit.

It sounds like you just want... regular classes? I don't understand your position here. Immutable data structures have many uses and are quite popular. If that's not what you want, why use these at all?

> Java developers used `getProp()` forever, now it's `prop()`. Shall we rewrite old classes or tools? Shall we live with two different styles in one codebase?

C# is the same way. The getProp() convention isn't as strong because it's had computed properties for longer, but one doesn't have to preclude the other.

Records provide a lot of syntactic sugar that classes don't (which is the whole reason to use them— there's nothing stopping you from creating a regular class with all final fields).

edit: I'm assuming that the "finality" of fields in records is identical to the shallow finality of a final field in an object

I wish Java provided syntax sugar similar to C#'s with {get; set;} and quick initialization with

  new C {
    field1 = X,
    field2 = Y,
    ...
  }

Records bring syntactic sugar to records only. And you're stuck with pages upon pages of unnecessary boilerplate code for classes.

The rest of us who've use kotlin's data classes or similiar features in other languages really like the first two points (the third point I don't mind but I don't like it either).

This was used in the olden days, nowadays developers prefer not to use pointless words in method names.

I really like those, and it also strengthen the fact that records are not java beans. If you want those you should write a regular class.

To the first two, it sounds like maybe you just don't want what it's offering. The autogenerated equals, etc can only work sensibly if instances are immutable. And if instances are immutable, enforcing a value-level comparison so that you can have predictable, standardized semantics around one of the pricklier bits of how a datatype is defined makes a fair bit of sense.

This is contraversial, but Java does not provide any value anymore. The JVM on the otherhand, is a remarkable piece of engineering, unrivaled by pretty much anything else in the space. I still can’t get over that Gosling was okay with the first Oak or Java or whatever release. But he’s a super smart guy so I assume there was a reason besides corporate pressure?

I’ve seen people on HN disagree, but we, as a profession, really deserve the most powerful tool for the job. Notation as a tool for thought, etc etc.

PS: The thesis is that complexity is bad (obviously), but power is good (a priori). Arguments against complexity are fine, but arguments against expressiveness and power are ridiculeous. Moreover, the arguments I’ve heard against power are strikingly similar to those I’ve heard against freedom, or drug legalization, or democracy. They always revolve around how other people are stupid and can’t be trusted with power/freedom/expressiveness/etc.

You also seem to be under the impression that more features always mean "better" and that more power always means "better." I am not sure what gave you that impression, but by most reasonable metrics neither of these is the case. Your comparison with democracy is also misused. I think you'd agree that if every person had the right to arrest anyone else or to judge and punish people, our situation would not necessarily be improved. Software, or at least the kind of software that Java is designed for, isn't written by a person but by a group of people, often a very large group of people, and over what could be decades. The goal of various restrictions is to protect the work. Finally, arguments for "expressivity" are just as ridiculous as arguments against it; these are largely matters of personal aesthetic preference.

The tooling for scala also is not as good as the rest of the Java world.

Fans love it because they code in VIM. Non-fans tend to have better tools and thus find Scala's tools very very lacking.

Quite the opposite, one of the downsides to Scala is that non-IntelliJ editor support is currently lacking.

It's not the stupid that can't be trusted with Scala's power and freedom but it is those who are trying to be too clever. At least when they are working in a team.

Of course this is not only the case with Scala, but not many languages offer you so many different ways to abuse your power as Scala does.

No guest language ever took over a platform.

Record have an automatic way to propagate annotations from the record component to the generated methods/fields and comes with native support of serialization (like enums).

There you can read about algebraic data types in java, in Java 14 you get preview for records in Java 15 probably you'll get preview for sealed types - they were developed together for some time, only recently there was a split.

"Beyond the restrictions above, records behave like normal classes: they can be declared top level or nested, they can be generic, they can implement interfaces, and they are instantiated via the new keyword. The record's body may declare static methods, static fields, static initializers, constructors, instance methods, and nested types. The record, and the individual components in a state description, may be annotated."

https://openjdk.java.net/jeps/359

Scala 13th, Kotlin 20th.

I expect the current annotation-based libraries will start supporting record classes too.

The survey SureshG put forward (in a post parallel to yours) shows Kotlin twice the size of Scala (which surprised me), and Java something like 15 times the size of Kotlin. So to say that Kotlin is popular, but Scala isn't, seems to me to be drawing the line in a fairly arbitrary place. It seems more reasonable to say that neither is popular, or that both are.

"But Android" you say. Well, that will make Kotlin pretty popular, but it hasn't yet. In the future, you'll be right. That's why I added this. In the future, my post is going to look pretty silly without this context.