JDK 20 and JDK 21: What we know so far
infoq.com
infoq.com
I'd like to propose a very simple JEP for JDK22: Let me omit the useless {} at the end of a record declaration.
I get that records are technically classes and that sometimes, you want to add helper methods, additional constructors, etc. But the canonical - and most common - usecase for records is a dumb immutable data structure, and for that you shouldn't need anything except the fields and generated methods. That's the whole idea behind them.
I always found it strange that Java has you write an awkward empty class block for the standard usecase here, while reserving the more natural syntax for exotic uses.
It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.
Perl 5 seems to have all these annoying boilerplate lines that you need to add to every file in order to get “Perl The Good Parts”. But I think (I read) that they managed to boil it down to just one line.
I still disagree though. First, there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon.
Second, the point here is that you almost always leave the body of a record empty, while you rarely do so for a class or method.
They are worried that if you use arcane constructs like non-static initializers, the syntax might become confusing - but are fine if you have clutter in the common case. That seems backwards to me.
Edit: You can construct the exact same confusing situation that the thread warns against already today, with abstract methods:
public abstract void foo(); {
System.out.print("I don't have anything to do with foo!");
}
The email exchange didn't talk about that kind of confusion; in fact, it said `;` was an option. It just said that saving one or two keystrokes isn't worth it to break the rule that type declarations end in `}` while statements end in `;`.
> there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon.
Abstract methods aren't type declarations and they have no body. Also, they've been in Java since day one. It's conceivable that down the line, people will be so used to records that we'll allow `;` to terminate the definition. It's just that we've gone down from a page of code to one line, and adding another rule to save one character isn't worth it at this time.
I think it's not really about the keystrokes (though { } is harder to type on my keyboard than ; ) but more that this technically opens a new class block, which gets treated as such by build tools, IDEs, etc.
E.g. formatters want to put the braces on different lines by default and are generally tuned to put class blocks front and center - because with all the other occurrences of class blocks, that's the sensible thing to do. With records, it just undoes the neat "just one line" property.
Yes, you can add custom formatting rules to stop that, but that's additional effort - you also have to ensure everyone uses the new formatting, etc.
It's also more cognitive effort to parse the code: Imagine the GROUP BY clause were mandatory in SQL and if you didn't want to use grouping in your query, you'd have to write something like "GROUP BY 1". Certainly doable but makes queries harder to read.
> type declarations end in `}` while statements end in `;`.
That rule already has lots of exceptions, e.g. methods are not type declarations (like you said) and neither are initializers. Nevertheless, both use braces and leave out the ; at the end.
I am not an author of that particular feature, but I work with them on OpenJDK.
> Yes, you can add custom formatting rules to stop that, but that's additional effort ... It's also more cognitive effort to parse the code
Perhaps, but using `;` has its own downsides (it's different from all other type declarations both for readers and for the language's grammar). The choice is never between something good and something bad, but between two things that are both good and bad.
Given that a record can save you tens of lines, on the whole it was decided that it's not worth it to add a new rule that saves a single additional character at this time. It can always be added later.
> That rule already has lots of exceptions, e.g. methods are not type declarations (like you said) and neither are initializers. Nevertheless, both use braces and leave out the ; at the end.
That's not the rule, though. I didn't mean that only type declarations use {}, but that all type declarations use {}. I don't think there are any exceptions.
Meh. Pet peeve warning: I hate this. Sneaking in stuff like this that might save 1 or 2 characters every hundred or thousands of lines is just frustrating.
If I'm regularly discovering cute one-off things like this in a language I work in then I'm gonna hate the language. And unsurprisingly, I hate most modern languages.
To turn it around, what languages do you love?
I also rather enjoy Elixir - it has elisions like this, but there tends to be deeper fundamental underpinnings as to why it works, why it was included, and it's more broadly applicable. So rather than memorizing minutia you can understand those underpinnings.
Once I got past some of the weird syntax rules of Erlang, I really liked it. It was actually the first non-C-like language I "got".
I also somewhat enjoy Golang. I don't think baking concurrency into the actual language was necessary to get the ergonomics it provides (repeating a mistake Java made), but overall it's better than most others.
I think Java does an OK job of not being too susceptible to this. For people that want it there's always Kotlin, but I'm happier not using it. The evolution of Java seems to have a broader logic behind it, and they seem to be adding things with an eye towards the sum being greater than the individual parts.
Of course, for work, I'll use whatever is necessary for the project. Which is currently C# because we're doing stuff with Unity.
Alas.
Come to think of it I don't really understand why they had getters at all. Just go with a .foo attribute syntax. I can't imagine if I define a record and start overriding the foo() getter to do something other than returning foo I'm going to have a good time come PR time ... I've certainly never seen code that does this.
Most of the time your getters will just return the attribute, but there are situations where you don't have an attribute backing your property:
1) You're renaming the field, and you can't update all uses at once. You can create a synthetic property with the old name which delegates to the new name.
2) You want to lazily compute the property only when requested.
3) You want to perform a side-effect every time the field is accessed
I just wish that instead of Streams they’d made something more like
https://github.com/paulhoule/pidove
With the possibility of making something more fluent and less lispy.
https://github.com/paulhoule/ferocity
which is about developing a lispy DSL in which it is possible to write Java-in-Java to transform it to make syntactic macros. It's kinda crazy
https://github.com/paulhoule/ferocity/blob/main/ferocity0/sr...
and somebody might think it combines the worst of Java and Common LISP but I did enough work on it to be sure there were no major barriers. ferocity0 is a bootstrap implementation that it's possible to write a code generator that can generate code to make stubs for the standard library and write ferocity1 in ferocity0 and write ferocity2 in ferocity1 with the full power of code generation to hide the accidental complexity of Java... But other projects got in the way.
It’s got the difference though that they are using (mostly) strings to write the method bodies and my approach builds those up with the lispy DSL. The class/method/field definitions are basically the same. (ferocity contains three languages, one of expression trees, one of class definitions, another of compound statements that doesn't exist yet)
Mine can also run ‘lispy Java’ in an interpreted mode (as well as writing code that goes through javac) and I discovered the interpreter has a type system which is a little richer than the Java type system, namely I discovered (not invented) ‘quote’ and ‘eval’ so that expressions are a first class data type that can be manipulated…. I have to define some set of operators to make it easy to traverse and work on expressions which would make it easy to metaprogramming, probably taking back some of the verbosity that comes with the lispy java-in-java embedding.
Pure slowness in how java develop feels like you have to wait 5 years to get something that other languages have, only to get it in the most aesthetically unpleasant way.
It seems like devs add unnecessary verbosity whenever they can.
Java adopted lambdas after many other languages, yet still decided that allowing to move last parameter closure {} outside of () is too radical, even though it is much more visually pleasant choice and quite common in other languages.
default methods in interfaces instead of static extensions. This one is controversial as static extension methods were not really common when java came up with this, but end result does not look impressive.
Same with their new sealed classes. They just chose the most verbose version they came up with.
Some inconsistency of choices also kinda baffles me. First they added support for skipping necessity of mentioning generic type inside <> during instantiation, only to introduce local vars later that require you to mention generic types within the same <>. Now you either mention generics by their full type always, or embrace the inconsistency and have it skipped when type mentioned in prefix and type it when using local vars. Or do not use local vars and have consistent codestyle with increased verbosity.
Java is still a good language, but it feels dated in syntax. TBH I have no idea why would anyone chose java in 2023 when there's kotlin, which not only fully covers the same functionality(okay, no pattern matching and no loom/valhalla until java merges it), but does it while being much more concise and readable.
This was by design for Kotlin, and is probably their smartest/best feature. All existing Java code/libs just work in Kotlin. Conversely, most Kotlin code/libs just work in Java, although some care needs to be made there.
Kotlin is amazing to use and read. For most things, the Kotlin version is easier to read and comprehend than the Java version in my experience.
As Java adds language features, Kotlin either gets them for free or already had them (and now can use native features instead of their own custom features).
(Same thing with Groovy, but that one is even worse than Kotlin)
On the other hand Scala looks nice.
Other than Android, there are no reasons for additional complexity in development tooling.
> Kotlin adds Jetbrains only as IDE
Not true, you can use any IDE you want. Of course IntelliJ is the "blessed" IDE, but really, Kotlin is just a bunch of libs, any IDE will work.
> additional build plugins
I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins.
> an ecosystem of Kotlin libraries for more idiomatic code
Which are optional.
> stack traces completly unrelated to Kotlin as JVM only understands Java
I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical...
> needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes
You do not write the boilerplate though. That's the difference. Of course all higher level languages with High Order functions are going to suffer this same issue. It's abstractions all the way down..
You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.
This is the biggest issue, in my opinion. Although, if you have a java developer that really likes the higher order features that are being added, Kotlin might be a very easy switch (after some basic syntax learning).
The nice part is everything you already know about JVM performance still applies within Kotlin. So you're not starting over from square-one like you might assume.
No I can't, because InteliJ is the only one that actually supports Kotlin.
Otherwise I would just be using Notepad++.
> I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins.
It shows you don't work as build engineer.
> I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical...
Try to debug a Kotlin stacktrace with free functions and co-routines, and then try to tell the world it looks like what the Java compiler would generate.
> You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.
No I don't, because at my level libraries are validated and only internal repos are allowed in the CI/CD pipeline.
Also I no longer do native Android for work, other than mobile Web.
You can indeed use notepad++ to write Kotlin. Nothing is stopping you.
Kotlin is not limited to mobile development either.
And even despite of it, they were forced to update Android Java to keep up with the JVM ecosystem.
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.
-- https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
Subjectively, a lot of Kotlin features are implemented in a kind of ad-hoc way because they're designed to be as easy to use up-front as possible, at the cost of consistency. So the language has a kind of "technical debt" - it's hard to evolve it in the future. Add in the fact that the language lacks the higher-level abstraction facilities that would let you work around these incompatibilities (e.g. Scala has its own Option that's different from Java Optional - but this isn't a big problem because you can write a generic function that works on both. But you can't write a function Kotlin that works on both Java Optionals and Kotlin nullable types), and I'm really skeptical about its future.
An extension value clears this up in my Kotlin code, something like:
val <T> Optional<T>.value: T? get() = orElse(null)
repository
.findByFoo(bar)
.value
?.doSomething()
Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.
You can convert at a boundary, which is fine if you have a line between Java and Kotlin parts of your codebase. But you can't seamlessly mix Java and Kotlin and use the same functions with both, which is what some Kotlin advocates try to claim.
> Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.
I would bet they'll need incompatible changes, because there are subtle differences in the models. (Or they could keep the same API but with subtly different thread safety guarantees - but that would be a whole lot worse, breaking existing code in nondeterministic ways).
2. Even if there were inconsistencies, and certainly when it comes the the concrete complaints, people not only disagree on what's a preferable feature (I, for one, strongly dislike extension methods -- and consider them an anti-feature with a negative overall contribution -- and much prefer default methods) but they also don't pick a language based on one feature or another but based on a gestalt of properties. The languages mentioned by the commenters make different tradeoffs that have significant downsides alongside their upsides (e.g. they don't match the evolution of the platform; they add implicitness that makes it harder for some to read code; they have a lot of features that need to be learned, each of which is pretty underpowered), and it seems that more people prefer the overall tradeoffs Java makes.
BTW, languages also have important meta-features. For example, every language needs to adapt over time, and the question is how it does so. The three languages that have managed to successfully support large programs that can evolve over time, maintained by changing teams -- C, Java, and to a lesser extent C++ -- have shown they take evolution seriously. They maintain compatibility and choose their features carefully (well, C++ maybe less so). Kotlin has lots of features, but it already has more outdated large features than Java because it adds features to address a certain problem and then the platform addresses them in an altogether different way (data classes, async functions), and as a result it's showing its age quicker, too. Java has proven that it evolves well, and many think it evolves better than most other languages.
I just came across this as a potential footgun the other day. I had a var list = new ArrayList<>(), then later added a bunch of Foo's into the list, and then when I called an overloaded method with the signatures log(Object obj) and log(List<Foo> fooList), it was calling the Object version. I would think some better type inference should be possible there, but if not, making programmers declare the type(s) at least once is a necessary constraint.
Is that somehow bad thing?
https://www.infoq.com/articles/data-oriented-programming-jav...
Before jumping into writing new code we should develop the discipline to start by researching what has been done before in similar domains. Even if the old code isn't reusable we can often apply the same design patterns or at least avoid making the same mistakes.
We need government/grant supported researchers and tech writers who can do this work and create a curated, focused bunch of books describing the best methods and designs. I found the Architecture of Open Source Apps to be amazing, but we need something regularly maintained for all software domains.
One of the surest of tests is the way in which a poet borrows. Immature poets imitate; mature poets steal; bad poets deface what they take, and good poets make it into something better, or at least something different.
—T. S. Eliot
Despite its flaws, Scala isn't a bad language necessarily. It will still continue to see niche use. But it no longer seems like the obvious path forward for general purpose application coding.
While Scala is perhaps not a “bad language”, it contains many flaws and I don’t see much of a bright future for it. (Also, Scala 3 brings new single-use features, and an entire alternate Python-style syntax, because learning one syntax is apparently not enough.)
I'm working in Java now, but I thought Scala was fantastic. The problem was that it attracted functional programming puritans and the category theory astronauts -- both groups had some really good ideas -- but pragmatism is at odds with elegance and focusing on delivering business value versus developing knowledge of theory can be a tough balancing act.
I predict Scala will see an upswing for the same reason that OCaml has been on an upward trend in recent years; even if a language is no longer unhyped, if it's well-designed then it still ends up being the best way to get things done.
(The XML thing is a ten-years-out-of-date talking point, FTR)
Sure, and they either follow extraordinary development practices, or they have outages basically all the time (e.g. the famous Twitter "fail whale"). Like I said, in some lines of work (probably far more than people on HN would like to think, frankly) you can get away with that.
I'll tell you the answer: because the language is comparably well designed, with a lot of foresight, and the fundamental features work well together. Also you are totally right about XML. This was a total mistake and in fact already has been removed from the language - I think a few years ago.
Maybe you still have the old Scala in your head? That would explain your post a bit I guess.
> Programming language features aren’t “stolen”, since they aren’t really “owned” by any given language
I agree with that though and I think it's great that Java is progressing. There is no shame in copying the good things.
Scala 3 improved the situation a bit by breaking the "implicit" concept down into a few discrete concepts, but the language is still incredibly expansive, despite the "look how few keywords we have" talking point.
Honestly, I do think that modern Scala is very well designed. But unfortunately the ecosystem and tooling and corporate support for it never really got to the point where it feels like a practical choice for most teams.
Are the two specs comparable? Looking at the Scala 2.13 [0] (I can’t find a Scala 3 spec) and Java 19 [1] specs, while the Java spec is much longer page-wise, it is also much more formal and detailed:
* The Java spec sometimes defines things that might count as part of the standard library (eg. how threading and wait/notify work).
* The Scala specs just says “Scala source code consists of Unicode text.”, but the Java specification says what Unicode is, and talks about UCS-2/UTF-16 and why chars have surrogates (over almost two pages).
* The Java specification also talks a lot about the JVM and bytecode. The Scala spec does not include any details or assumptions about the underlying execution environment.
* Scala also delegates a lot of things that you would consider part of the language (e.g. the + operator for integers) to the standard library. Also, how do I figure out how large an Int can be in Scala without reading stdlib docs or writing a program to query Int.MaxSize?
* Similarly, comparing the keyword count of Java and Scala doesn’t necessarily yield sensible results, since Java considers `int` to be a keyword, but in Scala, this is just the name of a standard library class.
Also, the size of the language specification has nothing to do with how easy a feature is to grasp. Implicits may take 8 pages in the specification, but they are difficult to understand and tricky, especially if the implicit keyword meant 4 semi-related things in Scala 2.
---
> Maybe you still have the old Scala in your head? That would explain your post a bit I guess.
Which “old” Scala? Scala 3 still has ~all the features of Scala 2. It also has two separate syntaxes, a Java-like and a Python-like syntax, to add even more confusion and even more things to learn.
> This was a total mistake and in fact already has been removed from the language - I think a few years ago.
From the Scala 3 docs [2]:
> XML Literals are still supported, but will be dropped in the near future, to be replaced with XML string interpolation[.]
[0] https://scala-lang.org/files/archive/spec/2.13/spec.pdf
[1] https://docs.oracle.com/javase/specs/jls/se19/jls19.pdf
[2] https://docs.scala-lang.org/scala3/reference/dropped-feature...
And reasons are for example that the language just has less exceptions. Like the + "operator" which is just a method. And Int just being a datatype - no need to put this in the spec. Or that "int" is not a keyword in Scala - well, I think that is totally a good thing and also comparable, why not?
> Also, the size of the language specification has nothing to do with how easy a feature is to grasp
Sure, but your original claim wasn't just "it's hard to learn Scala" because with that claim I would agree.
> Scala 3 still has ~all the features of Scala 2
Scala 3 has removed a lot of features. In particular powerful features like Scala 2's macros. So what you say is just wrong (the tilde in front of the all really doesn't make it better).
> It also has two separate syntaxes, a Java-like and a Python-like syntax, to add even more confusion and even more things to learn.
That's a valid point, but if this is your level of complaint, then you must hate Java much more than Scala. It has way more warts and confusions than Scala. I know both languages in and out.
> > XML Literals are still supported, but will be dropped in the near future, to be replaced with XML string interpolation[.]
Careful here. XML literals are still supported (even though deprecated), but that is not xml support. XML support has been completely removed from the compiler and is now in a library that needs to be imported. This is different from before, where XML was really built into the language.
In other words: try to use XML without that library and it will simply not compile.
Sure, macros were removed, but they were an experimental thing in Scala 2 (and another case of language bloat IMO). If you look at features used in day-to-day programming (in [0] or [1]), the list of removed features is quite short, and many of them are very minor things that can be usually automatically replaced, and some of them were still supported in Scala 3.0 (perhaps with a compatibility flag).
[0] https://docs.scala-lang.org/scala3/guides/migration/incompat... [1] https://docs.scala-lang.org/scala3/reference/dropped-feature...
> Scala 3 still has ~all the features of Scala 2
to "Scala 3 has most of the day-to-day (from a language-user's point of view) programming features". I'm fine with that. :)
You linked to a page that has several actual dropped features from Scala 3. If Scala 3 didn’t drop features, it would still be Scala 2. What exactly is the point of all this edgelordery? We get it, you think Scala is uncool, but that’s just like your opinion man. Did you really jump onto a comment about Scala just to shit on Scala? I’m horrified to think of using a language that someone like you might actually think is cool.
I started by commenting on the OP’s statement calling Scala “cool” and talking about the feature bloat in Scala (that makes it uncool and hard to learn).
* introducing Java developers to the world of FP about ten years ago (i.e. before JDK8 and Kotlin) with a lot of that knowledge transferable to Kotlin in particular
* significantly influencing Kotlin and evolution of Java itself
Don't forget that it also made Spark (and to a lesser degree Flink and Kafka) possible.
https://github.com/scala/improvement-proposals/pull/44/files
Java has gone through a lot of changes, and is actually a very nice, streamlined language now.
You'll probably be very surprised to hear it even comes with a jshell and jwebserver these days!
Source: Me, Java coding professionally since Java 1.0 when it was "streamlined" in 1997, and Typescript for the last 5 years.
Typical node apps will ship with megabytes of extra files for functionality that would be present in the Java standard library. Even if I take your claim as fact, programming languages are about trade offs. While Java might suffer from download latency it will more than likely beat TS on execution time and gc latencies.
https://rosettacode.org/wiki/Hello_world/Text
You can see that some languages are simpler than others (even JS can be beat by this useless metric, check out APL). But it gives you no idea how the language scales up for complex tasks.
In both cases for anything more complex you will end up with a truckload of libraries, so even there there isn't much difference.
I think that were Java is not streamlined at all is in memory usage, because you will probably be able to get the same result with a fraction of memory in Javascript (and many other languages). I'm not sure if the problem is more on the JVM (heavyweight objects and no value types?) or the libraries, I suspect both.
Value types are being worked on with project Valhalla, but also the VM doesn’t give memory back to the OS. It holds on to it up until -Xmx, which by default if i recall correctly is 25% of the machine, so it’s hard to really know how much your program is actually using. It’s actually one of my biggest gripes about the JVM.
Java has a lot of required infrastructure, typically Spring these days, which brings with it all the boiler plate. Spring Boot is an "opinionated stack" (Google it) which basically is needed because _there is so much configuration required_ due to its enterprise level design, you can't just strip Spring out and have Java serve a basic 200 RESTful endpoint in the same footprint as other modern languages.
Additionally most projects typically include a lot of legacy mis-steps or third party Apache libs that have added bloat (3-4 logging libraries in a single project not uncommon, 2-3 Date apis, numerous XML or JSON parsers etc etc). So while code on the surface seem compact, in actual fact it's built on bloat. And my God the stupid FactoryFactoryFactory antipattern and similar over-engineered crap (I'm ashamed of the neckbeards of my age that actually thought this was a good idea).
In contrast TS (or JS), for server side do not require boilerplate, and the syntax lends itself to near native JSON handling removing the need for heavyweight parsing of RESTful or GraphQL endpoint arguments and responses. Then there's Serverless... Java cold starts in themselves are still a joke, Java is clearly better when it comes to batch work and warmed up, but need a quick small AWS Lambda to do something, a true one purpose "microservice" and TS will be both shorter to write and quicker to start, moreover it's half the cost owing to memory and CPU overhead (there are cloud metrics out there to prove this) but Java is more performant and we're talking about streamlining here so I've gone off topic.
If you're a Java fanboy, like I once was, you'd do well to spend some time in other languages, not just to play in some small projects, then you'll come back to Java with a different perspective.
Spring is not Java. It is not a required dependency. In the last 10 years I haven’t worked on a single Spring application. There are plenty of alternatives with modern apis: Play, Quarkus, Micronaut, Helidon, Javalin etc.
> Additionally most projects typically include a lot of legacy mis-steps or third party Apache libs that have added bloat (3-4 logging libraries in a single project not uncommon, 2-3 Date apis, numerous XML or JSON parsers etc etc).
Left pad, right pad, isNumber, isArray?
I’ll give you serverless, but I’ll repeat what I said in other comments: languages are about trade offs and use cases. They don’t have to be the one language to rule them all.
And more often than not you do want to have a whole toolbox available. How long will it take for you to add X to your TS microservice? Finding a dependency that looks somewhat stable (which will already bring in half of npm packages) is already hard enough, and my experience has never been too great with the JS ecosystem. It has a few gems among a trillion low-quality, always breaking shit.
Also, most newer project definitely don’t bring in datelibs, as the java.time package is very great (and was actually “brought into” the standard lib from a popular library, which is how it should be).
That overengineered bullshit actually comes from C++ of the time, it just probably didn’t segfault in java and thus higher levels of abstractions could have been achieved in the latter, sticking the concept to java, but I fail to see again, how it has any relevance.
Come on, JSON parsing is like one library - that not being available as is is not a problem at all..
Re: serverless. Honestly, is it really as popular a deployment method as I see it mentioned all around? Like, I can’t imagine a serious web app using it for anything besides converting images, videoes/etc, any you ain’t gonna use TS for that either. Coldstart still matters, but it is way overhyped.
So.. how exactly TS is better? If you claim to “spend some time in other languages” at least mention something on the language side that would somehow cause a difference. TS is not a paradigm-changing language at all..
While, Java EE is a pivot from Objective-C framework, from the collaboration between NeXT and Sun, Distributed Objects Everywhere.
It is like people don't get history of programming languages.
I would understand any other language to be better than Java, but Javascript is in same line as PHP of bad.
Steal the bits that work, don't steal the bits that don't work, get cooler but slowly without adding a bunch of useless rough bits along the way.
The guest languages are just that, guests that eventually leave the party.
are there things i don’t miss? yes. implicit. execution context on every future method. slow compiles. sbt
i couldn’t do java without records and “var”.
i don’t think scala has a real future. the binary incompatibility crushed scala for so long. sure scala 3 fixes it but not much has moved to 3. java is iterating at a faster pace than scala. they aren’t the same. scala was designed to be more terse and flexible and always will be.
but i don’t think that has made my programs worse in java. in some ways the lack of flexibility makes the code more predictable and easier to maintain
C style fork() seems insane for any gc-type languages, so ?? Threading in Java post virtual threads has been so pleasant that I'm like why would one bother?
The vast majority of applications use third party logging and many have the ability to call out to syslogd.
I'm not entirely interested that every language fits perfectly into the UNIX classical "everything's a process / pipe" style model.
I said datagram, not stream.
> C style fork() seems insane for any gc-type languages, so ??
java daemons have no way to signal systemd their readiness. The unix way is to fork and exit. The systemd specific way is to use dbus to tell systemd that the process is ready.
java supports none of that natively. So if you have a service that depends on a java daemon, you can't sort them properly.
The normal way is to hack the java daemon to be launched from a bash script, that will test if it's ready using curl or netcat, and will in turn tell systemd about it.
As it is, doing a sane daemon in java is impossible without having some JNI fun.
> I'm not entirely interested that every language fits perfectly into the UNIX classical "everything's a process / pipe" style model.
Ok, how do you propose to tell systemd that your daemon is ready to accept connections?
And there is a brand new Foreign Memory, Function API in Java (from project panama), which makes it quite possible and ergonomic.
I don't want to use dbus as that'd be an extra external dependency.
Equivalent of syslog() is still a problem without using external dependencies.
Just because you don't know about something and never learnt how to use it, it doesn't make it irrelevant.
https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-l...
That thing monitors journald.
Systemd is obsolete… let's use systemd!
Embarrassing :)
In theory, containers, application containers, and serverless language runtimes only need a type 1 hypervisor or bare bones kernel to execute.
In practice, there is still some kind of kernel underneath as convenience to the infrastructure people.
Actually, when we deploy VMs, it is mostly Windows ones, as Windows containers still have a couple of gotchas, so no systemd there as well any way.
Finally, systemd is a Linux thing, and there are more UNIXes to choose from.
Ah you're a windows developer… Perhaps talk to someone who works on servers before completely dismissing valid input that is completely outside of your expertise next time?
> Finally, systemd is a Linux thing, and there are more UNIXes to choose from.
And all of those report readiness with a fork(), which java can't do.
Nope, I am a Java, .NET, nodejs and C++ developer.
Cross platform languages.
> And all of those report readiness with a fork(), which java can't do.
fork() is legacy, it can't even handle modern UNIX workloads with threads.
You don't know unix things, yes. I can't understand how can someone be so proud of not knowing something.
Python and C++ are cross platforms and both support the things I listed that java doesn't support.
> fork() is legacy, it can't even handle modern UNIX workloads with threads.
Lol, ok. Next you're going to tell me file descriptors are obsolete?
Just a curiosity, what do you use instead of fork()?
Some education for you about fork(),
https://dl.acm.org/doi/10.1145/3317550.3321435
https://thorstenball.com/blog/2014/10/13/why-threads-cant-fo...
A person can live for decades before creating an HN account.
> I have used more UNIXes in my life that you probably know about.
I've used 5 different unix kernels. I've even read manpages instead of taking pride in not reading documentation, like some HN users with a large ego.
> Some education for you about fork(),
I'm perfectly aware of the issues of fork() when threading is in use. There are a lot of issues to keep track of when using threads. One more, doesn't really make much difference.
How do you do this? https://man7.org/linux/man-pages/man3/daemon.3.html
Do you plan on replying to my question? What do you use instead of fork()?
https://azure.microsoft.com/en-us/products/kubernetes-servic...
https://cloud.google.com/kubernetes-engine/
https://cloud.google.com/appengine
https://azure.microsoft.com/en-us/products/app-service
https://aws.amazon.com/lambda/
https://azure.microsoft.com/en-us/products/functions/
https://cloud.google.com/serverless
If you insist in calling fork() as matter of existial crysis, by all means do, Java doesn't stand in your way, learn JNI.
https://github.com/luben/process-jni/blob/master/src/main/ja...
On what exactly do you think the containers run on?
What kind of system call do you think happens on a machine to create a new container?
Again, you're so proud of not knowing something. The fact that you write very high level code and have other engineers figure out how to run that code for you, doesn't mean that their job is unimportant.
In fact, it might be the case that they might replace you, but not viceversa :)
I feel it is you that don't have a clue about how Cloud infrastructure works.
Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now.
Flip side is that this is true for everyone. If you're only doing trivial things that could have been done 20 years ago, you really don't have much competitive advantage. It's difficult to be competitive in the area of solving easy problems.
A lot of the work on the web/API side is I/O bound (e.g. waiting for network I/O to database) so unless throughput is your game (e.g. Stackoverflow), it seems that Node is "good enough" for most web/API work.
Modern hardware is insanely powerful. Like it's absolutely bonkers how much you can do on a modern computer. Although most modern applications have capabilities on par with a 2006 flash game.
Feels like a lot of the AI hype is the sudden discovery that modern computers are actually pretty fast and squandered doing book-keeping in small-to-medium SQL tables (not that you need LLMs to do interesting things with them).
Basically anything that required a data center in the year 2000 you can do on a powerful desktop PC today.
Nothing like IntelliJ crashing during a video conference and then indexing your entire project from scratch... Encoding video in real time is CPU intensive, indexing a hundred libraries adds oil into the fire.
And that's why every single Electron app is slower on a modern 4.7 GHz 8 core CPU than a (although not as pretty) native app on a single core CPU in 1999. Spotify is slow as molasses and has less features than foobar2000, MS Teams is slower than any messenger I used in 2005, and all those Postman-like apps are just a horror to use compared to a simple bash script with wget.
Case in point: I cannot use MS Teams on my state of the art computer when I'm compiling. It's just so slow to type and switch chats.
Personally I like having collections of requests, automatic formatting of responses, dedicated fields to enter headers into, automatic parsing of cURL / HAR etc, the ability to generate code in various languages...
There's a lot more to most of these Postman-like apps than just making requests!
Though I have seen Insomnia just completely choke up on large responses (10s of MBs) that Sublime renders in a flash - so you're not completely wrong, just throwing the baby out with the bathwater :)
What were you missing? Java had threading, task, threadpool capabilities for ages. It comes with all kinds of concurrent collection classes and running something in parallel could be just one .parallelStream() away. There are also countless reactive frameworks that minimize thread count. Java Loom / green threads are available since Java 19 (hidden behind a flag).
Vertx is way better than Node in a lot of ways, and faster, and easier to debug. Lock the event loop? You immediately get a log that you did something bad.
The whole ecosystem feels super fragile. It hurts productivity and moral. This just doesn't happen with Java.
https://developer.okta.com/blog/2022/08/26/state-of-java-pro...
"What Andy [Moore of Intel] giveth, Bill [Gates of Microsoft] taketh away."
* https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
See also:
> Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster.
If they're really concerned about performance they'd not go wrong by using Deno which often has at least double the performance of Node https://medium.com/deno-the-complete-reference/node-js-vs-de...
Deno for a lot of operations is actually comparable to Java level performance: https://programming-language-benchmarks.vercel.app/java-vs-t...
Java AWS Lambdas are typically 2-3x heavier in memory usage than a TS/JS equivalent, and the benefit of that warmup is negated if the Lambda shuts down due to idle time.
"Give it up when asked" !== less streamlined, it means expanding heap is required for normal operation. Too little heap, it buckles, GC is almost constant, and performance goes out of the window.
This sentence doesn't make any sense. It can't be both slower and just as fast, developer productivity is a totally different concept to performance. And being single threaded just means you have to spend more RAM to saturate your CPUs (threads are cheaper than processes), nothing stops you running many single threaded JVMs and load balancing across them, it's just inefficient.
I wouldn't use Javascript and developer productivity in the same sentence.
And libraries like Quarkus [2] that leverage it that can launch in < 0.016s with < 12MB of RAM.
[1] https://www.graalvm.org/22.0/reference-manual/native-image/
My biggest hope when generics were announced was that we'd finally get an alternative to writing `if err != nil` 10+ times per function, but it doesn't support generic method type parameters. That alone kneecaps it severely by making type-safe method chaining useless in most scenarios (unless you never need to map to another type, ever, I guess. Lucky you.)
I watched the talk, thought I understood it "enough", then completely fell on my face trying to write a JSON parser.
Could be me though, maybe I should try it again now that it's been a few months
Java needs set of microservice libraries reimagined from the ground up. Optimized for size and RAM consumption. Optimized for GraalVM compilation (it's bad, but it's not that bad, libraries make it that bad). Also preferably including new tool for building because Maven and Gradle are bad.
I'm in the same boat. I love Java, but I hate Java ecosystem. I hate golang, but I love its ecosystem. And I think that it's possible to write golang-like ecosystem for Java. After all there're people who wrote deno and bun to oppose node.js. Hopefully vaja will appear.
Which has pretty much already happened.
Maven and Gradle are not bad at all, hell, Gradle is probably one of the few build tools that can actually handle more complex tasks correctly. Sure, that fancy new build tool definitely is more ergonomic to use for that hello world with 3 dependencies listed, but can it actually be used for generating locale files and whatnot? Not everything is running the compiler.
Java’s ecosystem is one of the best and I can claim that quite objectively.
If you want performance, stick with Golang. If you want rapid prototyping/dev, go with Python, 3.11 is much better in performance than older versions.
The issue with Java is that right off the bat you are presented with bloat. Just to have a main function requires a class (and people realize this is wrong, which is why Kotlin and Groovy fixed this).
Want a build system? You have to learn a whole another language essentially, like ant/maven/or gradle.
Want to have logs? You have to use a library that has its own xml configuration files that specify behavior, in their own format. Oh and that library may have glaring vulnerabilities where logging something results in FETCHING CODE FROM THE INTERNET AND EXECUTING IT, BY DESIGN. Same goes for most any other public library that is widely used.
Oh and btw, its bad practice in making your class members public, you should make them private. But its also bad practice in writing getters and setters - instead use a library that hacks the AST and writes functions there that are not visible in the code, for which you need special plugins for every IDE to recognize.
I honestly don't know how people deal with this and remain so ignorant to it to continue using Java.
They managed to create a more verbose Java 1.1 (yes, this is objectively true), with even more footguns than it had at the time. Oh, and it is absolutely not more performant than Java for most use cases - sure, it is a good choice for very basic server applications that barely allocate anything, but complex applications where allocations are significant will absolutely run faster with Java.
public class Main {
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 60; i++) {
System.out.printf("%d\n", i);
Thread.sleep(1000);
}
}
}
Unfortunately I didn't save the flags I used.
That's more or less on par with the equivalent Node.js program on my PC (Node.js actually uses a bit more RES memory, 44MB).
So I guess as long as you can (and want to) spam a lot of flags, it's feasible to lower memory usage.
Disclaimer: Not a Java dev.
If you want a lean, native-compilable microservice framework, there is Quarkus: https://quarkus.io/
Is there a performance consideration here? When using sealed classes, can the JVM do a better job optimizing pattern matches for switch? Are there also considerations with how it interacts with Project Valhalla?
The team evolving Java seem pretty good at evolving the language with higher level goals in mind, so I wasn't sure if there were interrelated factors here.
Yes! In the Pair<I> example from the JEP, if the number of subclasses of I is large enough, it may be worth generating a perfect hash function [0] to match the pattern in O(1) time instead of the naive O(n^2). This is only possible in the general case for exhaustive switch statements, which sealed classes allow for with instanceof-style patterns.
I also can't do nested record destructuring because it causes an ArrayIndexOutOfBoundsException in the Eclipse Neovim LSP. The "bleeding" part of bleeding edge!
I'm glad it's not just me! I was implementing Either<T, U> the other day, and found writing Left<T, U> and Right<T, U> a little dirty. Progress is progress though.
Im convinced that Java exists solely to create positions within Software Engineering industry. It requires you to write more code than necessary by design.
It doesn't help either way. Kotlin definitely has its quirks and issues. Multiplatform means they're trying to re-invent everything and yet don't have all the resources to. With Kotlin moving to KSP for annotation processing this has been another source of pain with library developers having to maintain 2 variants. Not everything is KSP supported either. It's not quite so straight forward.
It turns out that being unable to use Java libraries is a big issue when one doesn't want to re-create the Java world in Kotlin.
Also, Java is far, far simpler to code in compared to Kotlin. Modern Java is quite pleasant. The language advantages of Kotlin frankly aren't enough to switch. It may have been supreme in 2016, but Kotlin has lost most of its head-start now. Java has caught in both mature language features and lean libraries.
And folks do prefer simpler languages. There is a reason that Go is popular.