modern java is a huge improvement over old java. switch pattern matching will be huge, this has been in preview for a long time
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.
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