6 ms·

I appreciate the hard work that went into the things that did make it into Valhalla eventually, but: > The model was powerful, but also mentally heavy No it i

• andyjohnson0 4mo ago
  > The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here. I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentre/compute business at this point, with appendiges for its legacy activities and a vast overhang of debt. I sometimes wonder if the only parts of Oracle that are still profitable are the Legal and Lawnmower divisions.
  • rf15 4mo ago
    How .net got so many things right where java did not is a mystery to me, but appreciated (it has its own flaws, of course). Java, in my understanding, is still of core relevance to Oracle, and tied into a lot of contracts that require very little effort from them to maintain. But you are correct in observing that they want to be a datacentre/compute business more and more these days; they may have in fact overcomitted to this due to the AI craze, since shareholders are already complaining.
    • jbellis 4mo ago
      It's no mystery. https://en.wikipedia.org/wiki/Anders_Hejlsberg https://en.wikipedia.org/wiki/Anders_Hejlsberg
      • pjmlp 4mo ago
        Which recently decided that Go was a better option than C# for the Typescript rewrite, exactly because not all decisions were done correctly to make C# a better fit for the problem.
        • Rohansi 4mo ago
          Go was chosen mainly because it aligned more with how the existing compiler is designed. They did not want to redesign the compiler which eliminated C# as a choice. So Go is apparently just a better fit for quickly porting JavaScript code to.
          • pjmlp 4mo ago
            That was the original motivation yes, although they acknowledged later that the weaker type system from Go required redesigning the data structures anyway. And as proven in the recent announcement, they had to rewrite parcel from C++ into Go, as they didn't found a comparable library in Go ecosystem. There is also another interview, where again they mention having used AI as tool for code rewriting as well. Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
            • Rohansi 4mo ago
              They said the prototyped in a few languages before settling on Go. Based on what you said it sounds like they didn't do a great job at that and stuck with their decision anyway. > Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one. It's been working fine for a few years now. The only problem I know is there is little to no reflection allowed (by design) so a lot of code out there is not compatible with it yet. Not sure if that's what turned the TypeScript team away from it.
  • watwut 4mo ago
    > particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.
    • andai 4mo ago
      I had the opposite experience, spent a year with each language, first Java then C#, and to me C# felt like "Java done right". (Which appeared to be the original design goal behind the language!) So I'm curious about your experience. To me it felt a bit less like a religion and more like a language. It didn't force me to do things a particular way, quite as much. (Still more than I would have liked, though! After all, it's called that[0] for a reason :) [0] https://www.reddit.com/r/ProgrammerHumor/comments/ddc4b0/microsoft_java/ https://www.reddit.com/r/ProgrammerHumor/comments/ddc4b0/mic...
    • bazoom42 4mo ago
      What do you like about Java compared to C#?
      • watwut 4mo ago
        First, huge open source ecosystem and culture. Mature open source projects, culture of writing blogs and tutorials (that one will die due to changes in search engines, but it was super nice while it lasted). Second, working in C# felt clunky, as if every other thing was done to check the checkbox "done" and the author called it the day once it sorta kinda worked. There was some additional syntactic sugar in that language that was nice, but it did not made that much difference in practice and I don't miss it after coming back to java. Third, I found the obsession with bashing java by people who have no idea how java projects look like and which problems they have annoying.
    • ivolimmen 4mo ago
      Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are: -Java always has an API, .NET is about extending an existing application (Servlet API vs IIS) -Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET). -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure). -Java's Eco-system is way bigger.
  • gf000 4mo ago
    > The stewardship of Java seems rather lacking In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times from heap size. Like if anything, Java is at the best place it has ever been.
    • lmm 4mo ago
      > They have added proper algebraic data types to the language No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.
      • _kidlike 4mo ago
        optional is not how algebraic data types are implemented in Java. Basically it's the combination of sealed types and records.
        • joe_mwangi 4mo ago
          Until they implement member patterns. https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns https://openjdk.org/projects/amber/design-notes/patterns/tow...
      • gf000 4mo ago
        Sealed classes/interfaces and records are proper sum and product types. The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java: ``` sealed class Maybe<T> permits Some, None { record Some<T>(T obj) {} record None() {} } ``` (You will probably have to write Maybe.Some and I might have messed up the generic syntax as I wrote it on my phone, but that's mostly how it looks)
  • pron 4mo ago
    First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections. Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things: 1. Opinions about features are almost never universal, even among experts, and almost each of them is about a tradeoff where different people prefer different sides. It is rare that some scientific study settles the issue. 2. These preferences are often not evenly split. Even when both sides are equally confident that their preference is the right one, sometimes 80% or 90% of programmers share a preference. The people with the strongest opinions are more often than not in the minority, because most programmers don't think so much about the programming language (nor, I would say, should they). All of the language differences between .NET and Java fall in this "non-consensus" zone, and at least in one area I was deeply involved with, virtual thread, I can say that we thought that whatever we do we mustn't do what .NET did and that what they chose didn't work out well for them at all.
    • nixon_why69 4mo ago
      Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.
      • gf000 4mo ago
        You can have a null int, it's called Integer. What was taken away is the other, identity-having functionality of Integer and similar (e.g. no synchronization).
      • tsimionescu 4mo ago
        This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.
  • pfannl 4mo ago
    C# often feels like Java with hindsight; Java feels like Java with 30 years of backward compatibility debt.
    • pjmlp 4mo ago
      Hence why so many .NET projects keep being .NET Framework instead having migrated to modern .NET.
      • donkeylazy456 4mo ago
        mostly they are sticking to .net standard 2.0 that is compatible both framework and modern.
  • pjmlp 4mo ago
    Given the mess of some .NET frameworks currently, and how bad it has taken for non nullable references to be widely adopted, I don't see those correct decisions on the last releases. It is all about having AI on the framework, Aspire, multiple Web and Desktop frameworks all over the landscape. Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.
    • drdexebtjl 4mo ago
      >Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either. Yeah. Even when they add new grammar nowadays, it's always just something that trivially sugars away into previous grammar (see: records, `with` clones, extension properties, required, etc). The moment they need something that it's slightly more complex... Out of scope. Even when it's completely necessary for the thing to be useful in practice. For example, they added `required`, `record`s and property initializers, giving us good reasons to write `new Foo { A = a, B = b }` instead of `new Foo(a, b)`. A and B must be positive, so you'd write: public required int A { get; init => field = value > 0 ? value : throw ... ; } public required int B { get; init => field = value > 0 ? value : throw ... ; } This is pretty standard C# code that you might see in an example for records. But then the requirements change: A and B must be positive, or they must both be zero at the same time. This cannot be expressed at all with initializers. You simply cannot add code that runs after all initializers are called. You're stuck chasing every single initialization of Foo and using a constructor or factory method instead. Shipped it as a public API? Too bad. Should have seen it coming! The new features are filled with this sort of thing. As if Microsoft never used them beyond the most basic examples. Or maybe they did, and explicitly chose not to fix it and solve later.
      • pjmlp 4mo ago
        I have this idea, that since they went open source, but failed to gain the adoption on UNIX shops they were expecting, there are tons of features to try to make it cool again somehow. The reality, and I can see this on my bubble, is that the .NET shops are mostly former Microsoft shops now saving Windows licenses by deploying on Linux. Stuff like MAUI remains pretty much constrained to former Xamarin customers. Thus minimal APIs, aspire, Blazor, and whatever comes up to support those use cases first. There are some podcast interviews from David Fowler and Maddy Montaquila where they touch the adoption issue among newer generations.
  • PaulHoule 4mo ago
    .NET made different decisions. I was at a conference on scientific programming in Java very early on that Geoff Fox put on up at Syracuse and we had a list of requests from Sun that they didn't give us but Microsoft gave many of them right away. On the other hand I really like Java's all-virtual approach to inheritance because the .NET model gives programmers more ways to screw up and get confused. Both languages slipped in generics after 1.0. Java used type erasure in a way that made it so a List<String> is really a List so generics could be retrofitted easily to existing code. .NET's implementation of generics let you do more but caused a rift in the ecosystem between generic and non-generic collections. I'd say long term Oracle's stewardship of Java has been very good. JDK 8 puts lambdas on your fingertips with a very fluent syntax that belies the idea that Java is terribly verbose. Since then Java has gotten steadily better release after release while maintaining great compatibility. I work with people who are conservative about updates because they are worried about breaking things but for the last few LTS releases I've said "it ought to be really easy, let's give it a try" and it is really easy and we get performance improvements we can feel.
    • rjrjrjrj 4mo ago
      Java stagnated for quite a while. Seemed like everyone was stuck on Java 6 for about a decade. But JDK8 was a huge step forward. Lambdas, streams, and a date/time API that is the best I've seen.
    • to11mtm 4mo ago
      I think DotNet had a bit of benefit, in that the language was still new enough to do the hard breakage. It was only about 3.5 years between NET1.0 and 2.0 (Where generics were added.)
      • PaulHoule 4mo ago
        I was annoyed by it back when I was doing Silverlight/ASP.NET Thing was a lot of Microsoft APIs for GUIs and whatnot used the List and if you wanted to use the List<X> you had to copy the list or make a wrapper or something. You might say, "just use the List" but at that point (circa 2008) I had to also use the List<X> for some API so I always had to do some conversion.
  • drzaiusx11 4mo ago
    I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.
    • Zardoz84 4mo ago
      Type inference was on DLang far before that Kotlin even existed. The only difference it's that reuses "auto" keyword.
      • gf000 4mo ago
        I mean, type inference goes decades before Dlang.
      • drzaiusx11 4mo ago
        not claiming kotlin invented anything, just that after kotlin adopts something and it turns out to be useful, java will come along in a few years and implement it (or avoid it, depending on how it goes)
  • dingi 4mo ago
    As someone who works with Java on a daily basis alongside a dozen other technology stacks, let me go out on a limb and say that I believe Oracle has been a stellar steward of the language. Java has been evolving quite nicely and at a reasonable pace, all without breaking the ecosystem or causing fragmentation. It certainly has its drawbacks, but doesn't everything?
• rzmmm 4mo ago
  This is mainly for performance and memory layouts, it would not have improved safety guarantees of java.
  • rf15 4mo ago
    It would have implicitly brought some null-safety to java with primitive-like classes that can not be null.
• _kidlike 4mo ago
  so your complaint is about the blogger, not the Java language? also, null markers are coming too: https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099 Its just that they have to deliver things incrementally. This PR that introduces value classes/objects is already 200k lines long.
  • rf15 4mo ago
    I agree, but I have seen the previous proposals/jeps and the discourse around them is rather discouraging. I hope this one can find it's way out of Draft, but I'll only believe it when I see it.
• 21asdffdsa12 4mo ago
  Nullable is just a different loadout state in Railway Orientated Programming. So, no reason to put different flavours of state into the language directly, when its a solved thing since (checks slides) 2012. There is just rails - going to A or going to B, depending on the trains loadout. If you have language-wars about a concept going in and out of existence, that is a hint that there is demand and the language does not properly handle the demand or when it handles it, it creates mental overload. > Value > Errorstates > Null > IoExceptions > WeirdOsStatesNeededToHandleUpstairs https://fsharpforfunandprofit.com/rop/ https://fsharpforfunandprofit.com/rop/ As the pythons said: Get on with it!
• pron 4mo ago
  > it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly. I think you've missed what this is referring to. It isn't about null safety (which is orthogonal) but about having reference/value projections analogous to Integer/int. What the Valhalla team ended up doing is, instead of having two projections for each type, one with identity and one without, value types never have identity and so Integer and int are synonymous, and the memory layout is determined automatically based on context and optimisation decisions. This is why the semantics of == for the primitive wrappers (like Integer) were changed, as they now don't depend on whether the "reference projection" or the "value projection" is used. > There is no reason to reduce the optional(!) safety guarantees you can offer with the excuse of "too mentally taxing". This is not what happened here.
  • tsimionescu 4mo ago
    > and so Integer and int are synonymous Except they're not, as I can do Integer x = null, but not int x = null. So an Integer is forced to occupy more memory, for very very unclear reasons. And this is also deeply weird - there is no other (mainstream?) language that allows null value types.
    • pron 4mo ago
      That's not quite how it works in Valhalla. Because Integer and int already exists, your declarations above will be interpreted with those meanings, but (assuming some TBD nullability annotation), they will be equivalent to `int? x` and `Integer! x` respectively. In other words, the nullability of a variable is a separate concern from the data type, and other than the different defaults on variable declarations (as these types already exist), Integer and int become the same type.
      • deleted 4mo ago
        [deleted]
      • tsimionescu 4mo ago
• imtringued 4mo ago
  Yes, in this respect Java is 100% doomed. They've made a terrible decision and they're sticking with it for the sake of "consistency".
  • groundzeros2015 4mo ago
    I think “Doomed” is slightly dramatic for preserving some decades old null ability conventions?
• jmyeet 4mo ago
  Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and the issue of value classes in generics is the second phase so is being pushed far into the future. But a huge mistake (IMHO) was not having nullability part of the type system. You can still do this with type erasure. Anyway, I read your comment as "nullability isn't complex" (paraphrased) but that's not the author's point. What's complex is having a value class and a regular class of every class and you don't necessary know which one you're dealing with at the language level. C++ is a great example of this. You can create an object ont he stack or the heap and that's really what we're talking about with that proposal. And that's a nightmare. Combined with pointers it meant you never knew if you could free something or not and that ownership had to be passed around with vague comments like "// retains ownership". Anyway, the whole article is a great tale of how difficult it is to retrofit things later and how difficult it can be to fix mistakes later (eg java.util.Date).
  • inigyou 4mo ago
    How would a non-nullable class field work in Java when it can be initiqlized by arbitrary imperative code that can read it while it's being initialized?
    • jmyeet 4mo ago
      The type erasure version of this would look a lot like Hack [1]. So generic arguments would simply have a ? if they allow nulls eg List<?Point>. The list itself couldn't be null unless it was ?List<?Point>. Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List<Point> if you're so inclined because the JVM doesn't know the difference, hence type erasure. So this is no different. I'm no JVM expert but from reading the article it seems like the chosen solution for value classes is to treat them all as a single L-type in the JVM where each primitive type is its own L-type. If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List<Point>. Obviously we need to be concerned with fuzzing (moreso in C++) but here really we're just trying to have sensible defaults that aren't guaranteed because we can't design the language how we want from the ground up without making a new language. Oh and there is a prosopal for this [2]. Personally, I prefer the Hack version. [1]: https://docs.hhvm.com/hack/types/nullable-types/ https://docs.hhvm.com/hack/types/nullable-types/ [2]: https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099
• drzaiusx11 4mo ago
  They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that. That said, we've been gnawing on this limb for a while...
  • arein3 4mo ago
    Ill be old when null safety will finally arrive This takes longer than game of thrones books
    • drzaiusx11 4mo ago
      I still recall when java first came out, its all relative--but sure, a decade can seem like eons in software.
• groundzeros2015 4mo ago
  > very little faith that Java can be steered in a sensible direction here. What? It’s been getting better with each release. Valhalla brings features that address key problems, and they didn’t rush to it either.
• lowbloodsugar 4mo ago
  Like yeah, every field is final but omg non-null is a bridge to far! Wtf?
• theptip 4mo ago
  > a single type would have two projections: a value variant (flat, never null, behaving like a primitive) and a reference variant (a box that allows null). Across various iterations this was written as Point.val/Point.ref, and later they experimented with the Point! and Point? syntax. This seems heavier? Having two representations and manually having to refer to .val or .ref? You can argue that the extra flexibility lets you write safer (non-nullable) code but naively it seems more complex at the language level.
• moomin 4mo ago
  I mean, I appreciate the huge engineering and design challenges here, but C# had non-null value types in 2002. It had generic value types in 2005 and it gained not-null “types with identity” in 2019 and no-one has batted an eyelid. (Indeed the type system support for value types still includes stuff Java isn’t even considering yet.) Saying the mental model is too hard is basically saying your userbase is stupid. This stuff is not tricky.
• hyperpallium2 4mo ago
  The non-nullability issue seems to be about performance, not cognitive load (search the article for "writes atomically"), though not articulated.