261–270 of 327 posts
Happy with the number of comments on this release. HN is a funny place.One day you are convinced no smart person on HN is still writing Java and the next day you see droves discussing about a java release.
Man, I hope the migration to Java 11 that my infrastructure team started 18 months ago is going okay.
Can't read whether this is sarcastic or tongue in cheek ;-) Java 11 is the newest LTS release. The next LTS release will be Java 17. Many companies won't touch anything that isn't LTS. There are still a large number of companies staying on Java 8 :shrug:
Do you think the "Run anywhere" marketing behind Java is rarely important? Java programs normally sit on a server, or many servers of the same arch. The decent thing is that someone can build a JVM for a new architecture and lots of /other/ languages that target the JVM work. But this seems different from "my program can runs on lots of architectures".
In the 1990s it looked very much as if desktop and server heterogeneity would be the norm. That you'd pick between alternatives like Solaris on SPARC, HP-UX on PA-RISC, Irix on MIPS, Windows on Alpha / MIPS / x86 / PowerPC, MacOS on PowerPC, OS/2 on PowerPC / x86 etc etc. The designers of Java, as well as software community at large, had dealt with the pain of moving large codebases across platforms and so the WORA p…
Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?
Yes. It feels out-of-place. All other keywords are like one word: enum, class, public, protected, native, sealed, ... But looks entirely different: Two words, connected by a hyphen. But I think, it was done because of backwards compatibility. If they would have called it "closed", it would maybe break hundreds of programs that have methods/variables called "closed"
Earlier quoted context omitted.
We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc. While it's good for C#/Java, it does make it harder to push for adoption for a language such as Scala and F#. Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?
I can only comment on C# / F#. The C# versions of F# features tend to be pretty clunky compared to the F# versions. This is because F# was designed for them from the beginning, rather than having them tacked on. Functional programming is getting easier in C#, no question about that, but honestly, it still kind of sucks. And the OOP-minded C# devs on your team still won't be able to make sense of your code that levera…
I think some things about functional programming make code feel cleaner, but I don't like it enough to use F# or Haskell.
Earlier quoted context omitted.
I think it's interesting to discuss how many are stuck on java8. It was a long time many of us were stuck on java6 or 7, and finally got up to java8. But then when 9, 10 and 11 came no one made an effort to upgrade. Why? And now we're at 15 and people are starting to feel the heat. We only migrated our main service from 8 to 15 a month ago (AWS deprecation), but still have lots of 8 code laying around (luckily some o…
> I think it's interesting to discuss how many are stuck on java8. [...] But then when 9, 10 and 11 came no one made an effort to upgrade. Why? A lot of things broke in Java 9, which was short-lived (both it and Java 10 lasted only six months each), and then Java 11 broke many other things (for instance, it removed all of J2EE). As late as last year, I was still seeing changes in libraries to fix issues with Java 9 o…
runtimeOnly 'org.glassfish.jaxb:jaxb-runtime:2.3.2'Earlier quoted context omitted.
> Records (...) are borrowed from Scala. I think records already existed in FORTRAN and other languages like ALGOL-60. C has structs, too.
Yes you are right, records have been around for a long time. COBOL was a popular, very early language supporting hierarchical data of different types. This dates back to approximately 1960. FORTRAN didn’t have records other than I/O “records” (at least for the first 20 years). ALGOL-60 didn’t have records. Algol-68 did have records, however Algol-68 wasn’t in very widespread use. I never had an opportunity to use it;…
Earlier quoted context omitted.
Because while in the end project valhalla will not call them value classes, it is a sort of an overloaded term. Structs/value types can be mutable, records are not. They are basically tuples with names. And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.
> Structs/value types can be mutable, records are not. Fair point about record fields not being reassignable (not the same as immutable for others reading this). > And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference. Well, sure. All non-primitives are passed by reference. That doesn't stop them from being referred to as value typ…
Earlier quoted context omitted.
For a couple decades, x86 was absolutely dominant and there were no new architectures of any importance outside specific niches. Once you dealt with the OS specific oddities (which java also helped with), C++ was highly portable.
> For a couple decades, x86 was absolutely dominant On the desktop and servers, maybe. But there is more in heaven and embedded than is dreamt of in your philosophy.
If you wanted the full fat SE Sun/Oracle JVM you were pretty much stuck with power or ARM, and even then you had to be careful. Remember the portability disaster that was symbian and Java ME? These ISAs weren't exactly the low end of the embedded market at the time either. The farther away from x86 you got the less portability you could actually take advantage of.
Earlier quoted context omitted.
>Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly? because if you know exactly what you want to do there's no reason to settle for the second best thing. If you want F#, no harm with going exactly with F#. I talked to a bunch of Jane Street engineers once and the consensus seemed to be that Ocaml, despite its very small footprint,…
> actually helped them attract the kind of people who were super enthusiastic about building really good stuff with a good technology, so it actually made recruiting for them easier. Sounds like a strong case of selection bias. There is no shortage of people who are super enthusiastic about building really good stuff with good technology, and it's hard to believe that it's easier to hire Ocaml engineers than other la…
On the other hand, if you see someone took the time to learn OCaml, I think you can be reasonably well assured they legitimately love programming. Signal value jumps from "this person has ever programmed" to "maybe this person has a real passion for it."