> changing 4 lines into 13 scaled into a entire code base is a massive amount of sludge to wade thru
It's only more verbose for the code that is defining new types. Code that is simply defining behavior (either in functions or methods) is unaffected and my experience is that that's the majority of code.
But reading those definitions at the top of the file is usually one of the first places I’m going to go to understand what’s going on. The 4-line option to me is much easier to grok, not only because it’s more terse but the way the pipes are stacked to indicate visually that they are related to the same underlying structure. The `extends Message` bit is a level of indirection that requires the reader to juggle a lot more in their head (as is immutable `final` not being the default). The `class` keyword also carries a lot of baggage that it’s not clear what to expect (will this have methods or not?, will we be seeing `this`?, etc.).
I think you're evaluating this as a notation for defining sum types. But that's not what it is. It's a notation for defining a class hierarchy, with all of the additional affordances that gives you.
In practice, most real-world Dart code that uses sealed types also defines methods in those types, getters, and all sorts of useful stuff. Once you factor that in, the data definitions themselves are a relatively small part.
(Of course, you could argue that defining class hierarchies is already intrinscally bad. But Dart is an object-oriented language targeting people that like organizing their code using classes.)
It's only more verbose for the code that is defining new types. Code that is simply defining behavior (either in functions or methods) is unaffected and my experience is that that's the majority of code.