void main(String[] args) {
println("Hello world");
}
java --enable-preview hello.java
The next class was assembly programming, where the teacher didn't bother to show for 4 months and then resumed the class as if we "self-taught up until this point". We were utterly lost in that one.
I imagine things have changed greatly today but back then it was a complete roller coaster.
I wasn't good at getting educated, but I ended up at a community college to "get my generals" - my first class of the day was computer something or other, and the class was led by a man in extremely thick glasses who said that our general approach in the course was going to be:
* perform actions with the computer
* take a screenshot
* paste the screenshot into mspaint
* print out the screenshot as proof that we had completed the thing
* put that in a folder
* he would review the folder for completion While it was a significantly younger and less experienced me who quit this bullshit in an absolute huff, I don't know if I could go through it today.
Fast forward a few years later, and I was training folks on tech support(a random reversal) and I had a lady who should have taken his class... every time I told them to click on something she asked "is that right click or a left click?" and each time I would respond "its a left click unless I tell you otherwise" (she didn't last long.)
But what does this code even mean..? Isn't Java's whole simplifying model that everything lives in "Objects"? This seems to break that fundamental paradigm and makes the language more complicated. If you needed something like global functions then in vanilla Java as I remember you'd stick it into static final Objects that acts as a namespace of sorts. So you don't need to worry about functions floating around in a global namespace soup.
If you're gunna just have free floating functions in your file.. then why not just cut to the chase and have a
println("Hello world");
> you don't have REPL
I don't think people realize Java8 was until very recently the dominant java version in production software, and currently close to 90% of all java projects still run on java11 and earlier.
Edit: after checking New Relic's 2024 report on the java ecosystem, it sounds like java11 and earlier is now at slightly over 60%, with java17 being used in around 35% of the projects.
You don't sound like you work with Java. I know for a fact that even some FANGs, with their army of software engineers, still use Java8 for most of their Java projects.
From what I can tell, there are 4 main reasons why some don't upgrade.
1. They have legacy software and are afraid of breaking it, sometimes with good reasons.
2. The devs don't know or care enough about the new versions to bother with it. Noone is promoted because of an upgrade. Work to live, and don't live to work
3. The ones who don't have buy in from management to spend time fixing something that works
4. They are using version 11+ that should be much safer to upgrade than earlier versions, but they are still in the mindset of 1 or 2 above
There have been huge improvements not only in the language itself, but also performance and memory use. They could save money if they upgrade, but in some cases this is acceptable because they can make more money by spending time on a new feature, than an upgrade.
In my last 3 workplaces, they usually tried to use the latest LTS versions. But to be honest, some of the services were in maintenance mode and we didn't get enough benefits to upgrade, so we were sometimes falling behind. Today we have a mix of v17 and v21. Anyone can upgrade anytime they want but noone cares about a service that you seldom work with. I feel kind of bad for that, but not enough to bother. I focus mainly on the services that I work with daily, and make sure they are using the latest versions
You missed the most obvious reason to not upgrade: there is no good reason to do it.
> There have been huge improvements not only in the language itself, but also performance and memory use.
That's debatable, and even if we blindly assume that then it's debatable whether the upgrade justifies the gains.
More often than not, it doesn't.
This is not debatable. It’s a factual truth. Every single actual performance review concludes that modern Java vastly out performs the decade old Java 8 runtime.
For an example here is a quote from Hazelcast when comparing performance of modern Java on data heavy workloads [0]:
> JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses.
This is from 2020 and the gap has only gotten wider.
[0] https://hazelcast.com/blog/performance-of-modern-java-on-dat...
I don't think you even bothered to read the sources you're quoting, and you're just trying to make baseless assertions.
The very first question on JetBrain's survey is "Which versions of Java do you regularly use?", and 50% answered Java 8 with around 2% mentioning Java 7 and 1% answering Java 6. On top of that, Java11 alone comprised around 38%.
And you're talking about Java21? It doesn't even register in the survey at all.
The data there clearly shows that the ecosystem has as many users running a modern version. Which directly counters your assertion that everyone is just running 8.
But, yes, with static imports, you can just write "println" like that and have it work.
did you know that every function in a python script is actually an attribute of that module (which is basically a class). so my point is: who cares.
You still need to know what a main class is, so that you can reference it in your build.gradle file.
But it's useful for little one-off scripts, where you just go `$ java foo.java` from the command line.
Basically, imagine a `class Temporary4738 {` and `}` written above and below the .java file's content, that's roughly how it will behave.
It not having a fixed name is deliberate, so if you decide to build a bigger system you won't use this mechanism in a hard to maintain way, and also it needed a good semantic model for "top-level" variables/fields.
But with this implicit class model, top-level definitions are just fields of the class.
The same strategy is also followed by C# with their top-level statements. And yes, it's syntactic sugar.
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
Welcome to the last 10+ years of Java. They're trying to play catch-up to other languages that made fundamentally different and better choices, making Java more and more complicated in the process. They are so deeply entrenched in the enterprise back end space that programmers put up with it, nay, even feel grateful for it. People who are stuck using Java for the rest of their careers are happy to see it grow to accommodate 21st century programming techniques, even if it means that it becomes so complicated and crufty that no beginner will touch it ever again.
eg want to run code for 6 months at a go managing hundreds of gigs of data, tens of thousands of threads, at high load, with sustained gigs a second of garbage generation? the jvm will just silently tick away doing just that while being nearly bulletproof. As much as I love ruby and python, you ain't doing that with them.
With hot code loading, introspection, etc. All the stuff that makes developing super-robust long-lived systems way easier.
And the flip side of the clunky language is your code from 20 years ago still works.
Scala mainstreamed a bunch of concepts that java was slow to adopt, but the end result was java only took the good ideas and didn't take the bad ideas.
10+ years ago I considered myself proficient at C++. It made sense, I didn't mind the pointers, and while the std library still felt clunky, it was fine. But I tabled these skills, and they indeed rusted a bit, but surely I could bring them out when needed again, right?
Smart pointers with multiple variants, judicious use of macros, rampant use of double colons to ensure proper namespace resolution (which IMHO makes the code an absolute eyesore), to name a few. I won't argue these changes aren't necessary, but it isn't pretty.
(My guess: It is.)
> So you don't need to worry about functions floating around in a global namespace soup.
Because having classes floating around in a global namespace soup is fundamentally different and should give no worries to anyone. Yet this was argument made in earnest back when arguments about Java's strengths and weaknesses were much more popular.
What really threw me for a loop is the article author mentions: "I knew plenty of professors who were bothered by [the public static void main thing]." I could have sworn that OOP die-hards in academia _wanted_ the formal class boilerplate in the original design. Maybe they aged out? Perhaps, times are changing.
SEMICOLON!!!
It’s the Python if __name__ == __main__ trash that was the worst. You’ll never understand it and it doesn’t fit in the language.
I use python a lot these days, and like it, but it's pretty funny seeing stuff like the above and type hints.
I hate not knowing what types a function takes and returns.
This seems true to me too. Examples:
* if __name__ == "__main__": main()
* Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature
* @staticmethod as a decorator instead of being a language feature
* Duck typing vs. abstract base classes
* Static type hints got retrofitted to the language gradually, one feature at a time
* Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true
* Having a GIL instead of being truly multi-threaded from day one
* Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references
* Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).
(I do realize that there was opposition on this, but that the Clearly Wrong side won out is baffling.)
> * * if __name__ == "__main__": main()
So, don't use it. Python is frequently run as a scripting language (something Java is fundamentally bad at) and this stems from that. All it does is box logic off when a file is being run directly vs imported. It's a user convention and not a language one....ignore it if you hate it so.
> * Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature
This is all very well explained in the PEP. The quick run down, Python doesn't do anything to hide logic from users. Contracts are just conventions and python treats it that way; so the developer can say "you shouldn't use this directly, here's a notation to let you know", but nothing will stop a developer from doing what they want. In Java they'll just write a wrapper class, inherit the base class, and expose that logic. Or worse, fork the library just to edit the class' functionality in some minor way. In Python they'll just call it directly.
> * @staticmethod as a decorator instead of being a language feature
@staticmethod is a built-in, it is a language feature. It just doesn't follow your preferred syntax.
> * Duck typing vs. abstract base classes
You can do both in Python:
https://docs.python.org/3/library/abc.html
The concepts aren't mutually exclusive or even directly related. Java just happens to be bad at one of them, due to it's weirdly non-effective (for a VM'd language, at least) reflection system; so you think it's bad.
> * Static type hints
You're complaining about reflective programming and then complaining about a feature that essentially exists because you can't reflect. It's circular.
> * Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true.
GC arguments have run for decades and everyone has their opinions.
> * Having a GIL instead of being truly multi-threaded from day one
Python was created in 1989. Java was created in 1996. Can you guess what major change in computer history was happening around the latter's time?
Everything was GIANT-locked when Python was designed, unless it was specifically intended for SMP mainframes. The entirety of the FreeBSD operating system had a GIANT lock on it at the time, for instance. Linux didn't even exist. Mac OS and Windows both were fundamentally single threaded and cooperatively multitasked. Commercial Unices that supported SMP were only ~4-5 years old and a very small niche.
You might as well be complaining about "why didn't the x86 architecture just have 64-bit capabilities from the outset?"
> * Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references.
In other words: "it's not Java, so it's bad".
Java is a pure-OO language; Python is a procedural language with OO as an optional feature. To that end, it exposes OO-features in an optional manner versus forcing you to use them against your will.
So if the basis of all your arguments is "OO is better in Java", well the the response is "yeah I'd hope so, since you have no other choice as it's the fundamental paradigm". Guess what? Haskell is much better at functional programming than Java; that also doesn't make a valid argument about whether either is good or bad.
> * Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).
Java was developed 7 years later and during a time that Unicode was becoming the standard over ASCII. Python was designed when everything was still ASCII and Unicode a mere glint to the general computer science realm.
As you pointed out, even Java made a bad decision here due to their premature adoption of the standards (as any modern designed language is quick to point out).
> Duck typing vs. abstract base classes / You can do both in Python
I'm saying that the original intent of Python was duck typing, but then people realized that abstract base classes play an important role - e.g. isinstance() testing, static type annotations. So they still ended up where Java started.
> Static type hints / I don't even know what that means.
I'm saying that Python was designed with no type annotations on variables (though values did have types), and then they realized that people wanted this feature... and ended up where C/C++/Java/C# have been all along. Python became "enterprisey".
And then, Python implemented type hints rather badly from 3.0 through 3.10 and beyond. It doesn't include types in the official documentation, so now you have to guess what open() returns (it's typing.BinaryIO/typing.TextIO). It doesn't have an official type checker, instead relying on third-party tools like mypy. It moved items between typing and collections.abc. It requires `from future import __annotations__` for non-trivial programs. It changed typing.List to just list in 3.9. It introduced the | (union) operator in 3.10. And a bunch more little things I can't recall; it just had a bad out-of-the-box experience and kept tweaking things over the decade. Documenting generics and especially protocols in Python takes effort.
> Python was created in 1989. Java was created in 1996
Wrong. Java was created in 1991, and the first version released in 1996. https://en.wikipedia.org/wiki/Java_(programming_language)
Python 1 was released in 1994, and 2 in 2000. They had their chance to make breaking changes. https://en.wikipedia.org/wiki/History_of_Python
While you're right that Python predates Java, it's not by as many years as claimed.
> Various OOP concepts that are much better explained in Java than Python
To exemplify, here is how you figure out how to override `==`: https://docs.python.org/3/library/stdtypes.html#comparisons , https://docs.python.org/3/reference/expressions.html#express... . Notably, there is no documentation for object.__eq__().
Here is the Java version: https://docs.oracle.com/en/java/javase/23/docs/api/java.base...
Now for __hash__() / hashCode(), the Java version is clearer: https://docs.python.org/3/reference/datamodel.html#object.__... , https://docs.oracle.com/en/java/javase/23/docs/api/java.base...
Python __del__ is buried in the "Data model" page: https://docs.python.org/3/reference/datamodel.html#object.__... . Java's finalize() is easily found on Object: https://docs.oracle.com/en/java/javase/23/docs/api/java.base... . Furthermore, Joshua Bloch's book "Effective Java" has a chapter titled "Avoid finalizers and cleaners" that explains in detail why finalizers are problematic.
Python explains a lot less about weakref than Java: https://docs.python.org/3/library/weakref.html , https://docs.oracle.com/javase/8/docs/api/java/lang/ref/pack...
> Java is a pure-OO language
Extremely wrong. Java has primitive numeric types, which do not have methods or fields, and undergo painful boxing/unboxing conversions to interoperate with the OO world. Whether the performance benefits are worth it or not is debatable, but what's not debatable is that Java is not pure OOP. Some say that Java is a bad copy of Smalltalk, which I heard is fully object-oriented.
> Python is a procedural language with OO as an optional feature
Wrong. Every Python value is an object that can be inspected (dir(), .__dict__, etc.). And in the CPython API, every Python value is a PyObject*. I have ample grounds to believe that Python is more OO than Java.
Gosling and others started working on it in 1991, but does it really matter? First public release is when you can learn about it and borrow ideas. It doesn’t make your point less valid, of course - Java made a lot of hype back then.
You're purposefully fudging dates to make the argument more favorable to your point. If you want to argue initial source release, then you can maybe make the point for 0.9:
> In February 1991, Van Rossum published the code (labeled version 0.9.0) to alt.sources
And say that Python had it's initial release just slightly before Java had begun design specs. But Python was in use before that and Rossum had developed the initial version well before that (again, 1989):
> The programming language Python was conceived in the late 1980s,[1] and its implementation was started in December 1989[2] by Guido van Rossum
It's ironic that you're trying to make that same argument for Java and dismissing it for Python, when Python was very much in public use pre-1.0 and Java was not (outside of internal teams).
> Wrong. Every Python value is an object that can be inspected (dir(), .__dict__, etc.). And in the CPython API, every Python value is a PyObject*. I have ample grounds to believe that Python is more OO than Java.
I feel like, just based on this point, you've done nothing more than open the CPython source code and searched for "object". This naming was in place well before Python even had any of the OO-functionality that exists today (new-style classes derived from the Object type). If you're going to argue for "old-style" classes being OO in any way but name, you're probably going to fundamentally disagree with any OO fundamentalists, the designers of Python itself, and the Java community/designers. You might as well argue that structs with function pointers in C make it an OO-language, as that's functionally all they are.
PyObject doesn't correlate to a Python class/Object. It's a container data structure to allow for their duck/dynamic typing. Object is a type of PyObject; but it contains an additional layer of functionality to make it a Python Object (specifically PyMethodObject and PyTypeObject, and their correlative functionality). Again, to allow for the reflection/introspection and GC that you so bemoan; and due to the lack of C generics at the time (or really, even today). Being able to introspect a type has nothing to do with it's "OO-ness", although it can be very useful in such languages (such as C#).
As to your other point, sure...using "pure" was probably going too far. But by that same argument, even Haskell isn't pure-functional (nor do any really exist) due to it's need to interface with IO. But Java is about 90% there and strives for it. Python most definitely isn't nor does it make any intentions to do so.
Again, fudging the history/facts/topics to try and make your point. It's not worth discussing with someone who so fundamentally converses in bad faith. Especially since I'm making no claims to which is better, just outlining the flaws in your complaints. I really don't care about "better" languages.
hello world in python is literally just print("hello world!")
Arguably you could be a happy Python programmer without this capability.
>>> 'hello world'
'hello world'The point was that by including that print(), people already do say yes to including "like you'd do in a real program" ceremony in their supposedly minimal examples.
#! /usr/bin/env kotlin
println("Hello world")
IMHO Kotlin is underused as an alternative to python currently for data science stuff. It's surprisingly capable out of the box even with just the standard library and there are a lot of nice data science libraries that make it more useful. Not for everyone; but fairly easy to get started with.
Kotlin scripting is unfortunately not necessarily very user friendly (e.g. imports can be a bit tedious and IDE support is a bit meh). But it can be a nice way to embed some kotlin stuff in a script. Generally, Jetbrains could give this topic a lot more love and attention and it wouldn't even take that much to level up the experience.
KTS works in jupyter as well (there is a kotlin engine for that). And that of course is nice if you want to use Java libraries in jupyter. And developing kotlin DSLs for stuff and then using them in a script is kind of a power move.
Kotlin has been pretty bad at scripting and REPL, and unfortunately the team decided to drop both:
https://blog.jetbrains.com/kotlin/2024/11/state-of-kotlin-sc...
I somewhat agree, but it was kind of exciting to learn what each of those previously meaningless words meant.
Kind of a sneak preview... Tune in for next week when we learn what static means!!
void main(String[] args) {
println("Hello world");
}
and the previous one ...
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
Should we allow somebody who cannot handle the second one, go on and programming because of the first one?
As the adage goes - Java programmers can write Java in any language.
Seems 'Java programmers' were already writing Java before Java's release ;)
from __past__ import JavaProgrammer
/usr/bin/python: error: line 0: not a chanceThe massive amounts of indirection which the IDE wouldn’t help you understand was the difficult thing. What encoding you use for that is pretty irrelevant. JSON would have been worse.
The problem with xml was that IDEs were unable to help you.
Java is designed with OOP in mind and it kind of makes sense to have the user to think in terms of lego blocks of interfaces. Every method or class needs to have clear understanding of its users.
public - software handle is for all users
protected - software handle for current and extending classes
default - software is exposed to current package
private - software is restricted to be used in current class alone and nowhere else
So, the beginning of java programming starts with interface exposed to the user or other programmers. Is it weird and extreme. Yes. At least, it is consistent.
void main() {
println("Hello world");
}
It makes it far far closer to the python experience.
you forgot surrounding class definition.
Goals:
Offer a smooth on-ramp to Java programming so that instructors can introduce concepts in a gradual manner.
Help students to write basic programs in a concise manner and grow their code gracefully as their skills grow.
Reduce the ceremony of writing simple programs such as scripts and command-line utilities.
Do not introduce a separate beginners' dialect of the Java language.
Do not introduce a separate beginners' toolchain; student programs should be compiled and run with the same tools that compile and run any Java program.
In collage, CS101 and 102 required me to learn and use JAVA, which I felt was a huge step backwards in usability and a lot of excess typing.
But as I reflect on it now, I think my feeling were because I came from knowing how to do some things and therefore not requiring the framework that JAVA offed to first time programmers.
1. The obvious excess incidental complexity
2. and more important, the enterprisey culture that's much less compatible with the intellectual curiosity, looking under the hood, etc attitude that's needed to become a decent programmer.
Although my high school programming class was c++, which is even worse as a first language.
These were some neat tricks. I've been using the `java myfile.java` approach for running the AoC problems. I didn't realize the "implicit class" thing where you could have top level statements and methods, though, with the automatic import of java.base. That's pretty slick for this.
record Node(int cost, int row, int col){}
var pq = new PriorityQueue<Node>(Comparator.comparingInt(Node::cost));Really? A whole generation of Java programmers wrong functor classes in-line.
During jdk 1.1 development, there was obviously no consensus on test suites (i.e., JUnit), and the JavaSoft JCK tests required a ridiculous amount of html documentation for tracing to specs. Mark Reinhold, the jdk tech lead, refused to have his team write tests in JCK form, so instead he wrote a small harness with a compiling class loader: point the harness at a directory tree of .java files, and it would run them all, compiling as needed. The test interface was just a main function, and if it threw an exception, it failed. Pure and simple.
But probably the best magic trick for Java programmers is debugger hot reload. You write some empty methods, start the debugger, and then code iteratively, reloading as needed. (Set up the data and interfaces right, and change method bodies as you wish.) It's so much easier than recompile-println when you're just getting started, and after you've grown up and out, it's easier than rebuild/redeploy when you're working on a big system.
Hey, that's (close to) the traditional Smalltalk introduction-trick! And this has been available since 1.1? How does one concretely do that in Java and why is it not widely known?
2. The JDWP protocol lets debuggers redefine nearly anything, but HotSpot doesn't implement the full protocol. In practice many kinds of reload don't work.
3. To fix those issues app frameworks went with classloaders for partial app reloads instead, or reimplemented hotswap logic themselves (see JRebel).
There's no fundamental reason these can't be fixed, and in fact the Espresso JVM fixes both 1 and 2:
https://www.graalvm.org/latest/reference-manual/espresso/hot...
You can write JVM plugins that are invoked after redefinition occurs, allowing you (really your app framework) to do something sensible like partially reload state. And it implements the full protocol, so many more kinds of redefinition work.
Using it is easy. Just install Espresso as your JDK, point your build system at it, then debug your app. Recompiling what attached will cause hot reload.
But the JVM still has a few tricks up its sleeve, e.g. the class loader can dynamically re-load a newly compiled version of a class at runtime - jrebel is a proprietary extension that uses both tricks, but this latter can also be used by spring for hot swapping many parts of a running system.
Basically, in the JVM a class is unique within the class loader, so with a new class loader you can load as many class instances of the same, or slightly different class as you wish.
Do you have any example you can point to for this ?
And because it’s not compiled, you can just whack a hashbang at the top of the file and chmod it to be executable.
But perhaps we can both agree that it shouldn't be in JS/Node. :p
Definitely one of those things where the comment section is only good at spouting ancient memes with little regard to the truth of them.
The JVM is a massive memory sink compared to the tiny (actual) runtime in Go or the total absence of a VM or runtime in Rust or Zig. I allocate at least 5x more memory for Java tasks, but sometimes its more.
Java is great compared to scripting languages or writing raw C, but not compared to modern compiled languages from a syntax (null, thrown exceptions, inheritance, etc..), library selection, CVE/security, memory usage or raw computer power perspective.
All in all, Go may take up a little less memory for similar performance, but the JVM is more flexible (and more observable), offering you better performance if you need it. And the footprint will continue dropping, as it has done for years [2].
C++, Zig, or Rust are not really an apples-to-apples comparison. Sure, they take up significantly less RAM, but their performance is more expensive per unit of effort, and it's not a one-time cost, either. It's a permanent tax on maintenance, not to mention Java's superb observability.
Don't get me wrong -- I'm a fan of Zig, and C++ is the language I still program in most, but you can't really compare them to Java. Java makes you pay for certain things -- especially in RAM -- but you do get your memory's worth in exchange, and in a way that translates to pretty significant time and money. If you can't spare the memory as you're running in a constrained environment that's one thing, but if you can, it's all a matter of what you want to use it for: do you want to use it all just on data, or do you want to spare some to reduce maintenance costs/increase development speed and improve performance?
BTW, I'm not sure what is actually meant by a "lack of runtime" for C++/Rust/Zig. They all have standard libraries, just like Java. Rust even has a (crude) GC in its runtime that most Rust programs use (and, like Java, it compiles down to a VM). I think what people mean is that compilation to native is typically AOT rather than JIT, but that has both pros and cons.
[1]: https://openjdk.org/jeps/450
[2]: E.g. https://openjdk.org/jeps/254
Yes, Rust's GC is used through Rc/Arc, and I never said it is used extensively by most programs, only that most programs do use it. It is because it is not used extensively that it can be crude and designed to minimise footprint rather than offer good performance.
> Also, Rc/Arc arent a part of any Rust 'runtime', but rather the standard library
What's the difference between a standard library and a runtime? In the three decades I've been programming, they've been used interchangeably. A language runtime means some precompiled-code that programs use but is not compiled directly from the program.
> rustc compiles to LLVM IR, but LLVM is not a JVM/CLR VM
I never said that LLVM was a JVM -- these virtual machines have very different instruction sets -- but like a JVM, LLVM is a VM, i.e. an instruction set for an abstract machine.
Now, it is true that Rust is typically (though not always) compiled to native code AOT while Java code is typically (though not always) compiled to native code JIT, but I don't understand why that difference is stated in terms of having a runtime. One could have an AOT-compiled JVM (and, indeed, that exists) as well as a JIT-compiled LLVM (and that exists, too).
It is also true that Rust programs can be compiled without a runtime (or a very minimal one) while Java programs can choose to have more or less in their runtime, but even the most minimal runtime is larger than the most minimal Rust runtime.
First of all, you're right. But despite its definition I think people tend to look at it differently.
A runtime is generally thought of as a platform on top of which your code runs on; it needs to start first, and it manages your code. Or perhaps it runs in a side thread.
A language that has a runtime is hard to embed into something via just the C ABI, because a function call wouldn't use just the standard platform calling convention; it would have to start that runtime, perhaps marshal the parameters into something supported by that runtime, and then finally the runtime runs your function's code.
Take for example cgo, for which you'd need to start the garbage collector first (among other things), hence why the cgo FFI is expensive. Take as another example an async Rust function, which would require e.g. a Tokio runtime to be started first. Another example is Java, for which you'd have to start the whole JVM first.
A language that has no runtime, or a minimal runtime, can be called via the C ABI directly. All the function needs is to follow the calling convention, and then its code starts running immediately.
This is just my opinion of other people's opinions, I may be wrong.
That's not a well-defined thing.
> A language that has a runtime is hard to embed into something via just the C ABI, because a function call wouldn't use just the standard platform calling convention
But Java can be embedded in native code or embed native code. It has a specified FFI in both directions.
> Take for example cgo, for which you'd need to start the garbage collector first (among other things), hence why the cgo FFI is expensive.
Well, Java doesn't quite work like that, and its (new) FFI is free in most important cases (i.e. same as a non-inlined C-to-C call). Also, "starting the garbage collector" is not well-defined. What "starts" Rust's garbage collector?
I understand what you're trying to get at, but things aren't so simple. There are, indeed, differences especially around JIT vs AOT, but it's not as simple as saying "having a runtime" or not, nor is everything similar in all languages (Rust and C don't work the same vis-a-vis the C ABI, and Java, C#, and Go interop with native code are all quite different from each other).
> A language that has no runtime, or a minimal runtime, can be called via the C ABI directly.
A Java program can easily expose any method via the C ABI to be called directly if the process has been started from Java -- i.e. it's easy for Java code to give native code a function pointer to Java code. Going the other way, i.e. embedding Java in a C program, is somewhat more involved, but even C++'s interop with C, not to mention Rust or Zig, is not always straightforward. Like in Java, certain functions need to be marked as "C-interopable".
Most languages have an FFI, but I am talking specifically about the C ABI and the platform calling convention; or more specifically, about starting from scratch, and what is necessary to do from there until your code can finally run.
Anything more complex than the C ABI is what makes people say there is a runtime. It's some layer between your code and the other language's code, inserted there by your language. There's usually no way to remove it, and if there is, it severely limits the language features you can use.
> What "starts" Rust's garbage collector?
Nothing; it doesn't start unless the function itself wants to start one, and the function can choose which one to start, through your code (rather than what the language's required runtime provides).
> A Java program can easily expose any method via the C ABI to be called directly if the process has been started from Java
In that case, the runtime has already been started, and is being reused.
> Going the other way, i.e. embedding Java in a C program, is somewhat more involved
That part is the most important part, and is generally why people say Rust has a minimal runtime; it can be embedded with very little setup. The code you write starts executing almost immediately. Java calling C may add a management layer on Java's side, but C/C++/Rust/Zig/etc need very little (hence, minimal runtime).
But Rust (or Zig, or C++ for that matter) don't use the C ABI, either, except for specifically annotated functions.
> In that case, the runtime has already been started, and is being reused.
True, but I'm trying to say that the notion of "starting" the runtime (or the GC for that matter) is not really well-defined. HotSpot does need to be "started", but, say, Graal Native Image, which is sort of an AOT-compiled, statically linked JVM, isn't really "started".
> Java calling C may add a management layer on Java's side, but C/C++/Rust/Zig/etc need very little (hence, minimal runtime).
In some implementations of Java this may be the case in some situations, yes. I would go further and say that that's the typical case, i.e. if you want to embed the stock HotSpot, you will need to call some initialisation functions.
If that's what's meant by "runtime", then it's mostly correct, but it's more an implementation detail of HotSpot. Even without it there will remain more important differences between C++/Zig/Rust/C and Java, and this matter of "runtime" is not the most interesting aspect. For example, that Java is usually compiled JIT and Rust is usually compiled AOT is a bigger and more interesting difference.
Not only that, but Rust, C, Zig also require some setup before their `main()` can start as well.
That is why people say they have a "minimal runtime", rather than "no runtime". There is still a bit of setup there, without which the languages cannot function, or can only function in a limited mode.
Otherwise agreed on all your other points.
True, but to make use of Rc/Arc in Rust comparable to the use of GC in Java, almost evrery value would have to be wrapped in one, something I would think is quite rare.
> only that most programs do use it
I would still be interested in seeing statistics for this though. I have only ever used Arc once, and it was only to share a Mutex containing the program's database across threads.
> What's the difference between a standard library and a runtime?
I would say there are three main differences: - A runtime is (usually?) not optional - see languages like C#/Java/Python that require some sort of higher 'power' to manage their execution (interpreting/JITing code, GC management, etc), or crt0 - compared to a standard library which is just some extra code - see the C standard library function strlen() - A standard library can generally be implemented in the language itself. I think this is where the distinction starts to get a little fuzzier, with languages like Roc (its standard library is implemented in Zig), and Haskell (I would assume much of the side-effecty code like the implementation of IO is in C) - The purpose of a standard library is generally to provide 'helper' code that you wouldn't want to write yourself, e.g. Vec<T>, HashMap<T>, filesystem functions, etc. On the other hand, the purpose of a runtime is, per the first point, to manage the execution of the language, etc.
> I never said that LLVM was a JVM
True again, my point was worded badly. I didn't mean to suggest you thought LLVM was a JVM, rather to draw a distinction between LLVM and a Java/.NET style VM. LLVM used to stand for Low Level Virtual Machine, and the JVM has instructions like instanceof (which, fairly obviously, checks if a reference is an instance of the named class, array, or interface type). They operate at quite different abstraction levels, and the JVM is a lot more similar to the CLR.
> Now, it is true that Rust is typically (though not always) compiled to native code AOT
I would be genuinely interested in finding about a JIT compiler for Rust.
EDIT: it's worth me mentioning none of this is backed by any formal education (I'm 18), so it is very possibly wrong.
Being a memory hog was not such a big deal in the pre-cloud era, but we pay real money for that (far too much!) these days, and leaner approaches are worth a lot in real monetary terms.
I wish push back on some of your other points. Java has evolved quite a lot lately, with improved syntax, much improved runtime (Loom!), better GCs, lots of libraries, etc. The community is a bit stale though, and it's viewed as the Oldsmobile of languages. But that old language still has a skip in it's step!
Memory safety isn't possible in Java (unlike Rust).
Tooling: they all have debuggers and observability tooling (pprof, pprof-rs, etc..). Rust even has zed now.
Libraries: Rust has really high quality packages. On the flip side, Go has almost everything built into the stdlib. Java requires a ton of third party packages of varying quality and guarantees even for basic things like logging or working with JSON. You have to constantly be on the lookout for CVE's.
In fact, 75% of the cloud-native foundations projects are in Go. K8s and docker are Go. Go is much more web-app or microservice focused than Java is actually. Most Java apps are deployed into the cloud using Go.
Meanwhile, Zig makes using the universe of C/C++ code easy.
I highly recommend you try Zig, Rust, or Go out. They weren't created out of ignorance of Java, but because Java and C++ had areas that could be improved.
This is obviously some strange use of the phrase "memory safety" that I wasn't previously aware of.
It is usually just as easy to write a program in a low level language as it is in a high-level one, and this is true not only for Zig and Rust, but also for C++. Even in 1998 it was just as easy to write a program in C++ as it was in Java. But the maintenance later -- when you have a large 10-year-old codebase -- is significantly more costly, and necessarily so. In a low-level language, i.e. one where there's more direct control over memory management, how a subroutine uses memory may affect its callers. Whether the correct use in the caller is enforced by the language, as in Rust, or not always, as in Zig, changes in low-level languages require touching more code than in high-level ones, and can have a bigger impact.
The low-level domain is, and will continue to be, extremely important. But the market share gap between low-level and high-level languages/domains has only grown over the past decades, and there are no signs of the trend reversing.
Now Go is a different beast altogether, and is a high level language. But it has both pros and cons compared to Java. The tools it includes in the SDK are more user-friendly, but they, like the language, are less flexible and more limited than in the Java world. Nevertheless, the out-of-the-box experience is nicer, something we should definitely improve in Java, but you pay for that simplicity later in lost flexibility. Performance also isn't quite as good as Java's, and neither is observability.
Java tends to prefer using available memory, before it has to clean it. This results in memory usage growing more than it actually needs.
Services often run in containers, so this is less than a problem today than it was before, because the allocated memory to the container is fixed anyway. Try configuring the JVM to only use 75% of the container memory. In many cases, it will trigger an early GC and run better with smaller memory instances
There are of course some overhead for objects compared to primitives, but the Valhalla project is working to reduce the difference significantly on many cases.
You can also reduce memory usage and startup time by compiling to a binary image
Python? Huge respect, huge ecosystem, however I don't know if it's just me but I find it mighty hard to read. PHP with the "->" and Python with the space-sensitivity... Not sure why but it's so hard for me to overcome.
I use Ruby for scripting because it has a big standard library (unlike javascript) and an expressive syntax. The syntax is also very readable and short. It's also easy to install gems globally and use them. Things only need to be imported once.
I wouldn't say these things are qualities for big projects though. I like Typescript for big projects.
JEP 495: Simple Source Files and Instance Main Methods (Fourth Preview) https://openjdk.org/jeps/495
The parent article mentions and links JEP 477 -- the 3rd preview of the same feature-set. JEP 495 is the 4th preview and is included in JDK 24 which is in "stabilization" mode for release in March 2025.
I thought they had just hallucinated `java.io.IO`, but apparently it's a new type, available in Java 23 with --enable-preview: https://docs.oracle.com/en/java/javase/23/docs/api/java.base...
The learning curve was not that hard, and I got comfortable with it.
In contrast, I find React, Next.js and other frameworks more complex, and it takes a lot longer to be comfortable
I still like to use Ammonite as a REPL, but scala-cli has replaced it for me in those cases where i get fed up writing bash.
I am currently a heavy user of JRuby for quick and dirty scripts but still want to be on the JVM, but I'll give Java 23 a go and see how far it goes.
Deno has been my go-to scripting tool lately. Similar benefits to Java as used by the OP, but it also allows you to import dependencies directly by URL, which means you can have your script self-define dependencies without a separate manifest file
You don't even need main methods and class wrappers, can import libraries with annotations with Grape, etc.
The real failing of cli and scripting in jaba and groovy is running cli commands with access to stdin stdout stderr streams. I have figured out the dark art for groovy but it takes quite a few stack overflows to get there.
It feels instant, no need for GraalVM.
You don't need to fool with Gradle or Maven or Ant if you'd like to incorporate third-party or your own custom dependencies in single-file "Java scripts".
Just copy some .jar files into ~/lib, and in your `.bashrc`:
export CLASSPATH=~/lib;$CLASSPATHIts a cli based artifact fetching tool for the JVM ecosystem, and you can have it just make up classpath strings for you, i.e., to use some Apache dependencies with the single file simplified java running you could just:
java --enable-preview --class-path (cs fetch --classpath org.apache.commons:commons-collections4:4.4) program.java
Also, maybe do have a look at scala-cli: https://scala-cli.virtuslab.org/ It does work just fine with Java files, and allows you to write single-file programs that include dependencies as special comments. The tool has some idiosyncrasies (like a background compiler server), but overall works extremely well if you need some of the power of a build tool, but without having a complex project structure.
I always disliked Java until I was converted by some developers of that group in a past job. I suppose it is fair to judge a language by the overall flavour of its ecosystem, but it is a bit disappointing. I wish more people could see how simple and _good_ it can be when you use the JDK itself, and not go through other overcomplicated systems to use it. For example, Spring Boot is basically a massive pile of hacks (regardless of whether you consider it good or bad), and Java only really serves as an underlying support technology for it.
Java is a fantastic "scripting" language as long as you're fine running it in an IDE. Clean and typed syntax, powerful standard library (especially for data structures), great performance. A better choice in these respects than say Python, Bash, or Go.
I've used it for scrapers, Advent of Code, plain ole data munging and of course programming interviews.
That being said, I would never write a webserver in Java in 2024.
I don't know, this just seems more like inertia. "I'd rather stick to what I know best than this popular thing." Which is fine, and I'm glad Java has made improvements making it easier to hit the ground running. But blaming the use of Java on the inadequacies of Python? The python API can do just about anything, it has regex toolings, I've never found myself needing anything else. And the typing complaints? Yeah it can be annoying if you're not good at keeping track of your own typing hints, but modern python supports type annotations and linters like mypy[1] catch everything related to that just fine. I've always admired many of Java's features, but let's not act like the reason for using Java for scripting is the pitfalls of Python. It's just because of an underlying preference for Java.
If you write all the code you deal with, then sure. My experiences on big projects tend to be typing problems introduced by libraries. The kind where documentation and the decorators suggest it'll only ever return some specific value type, but then very occasionally it'll return a tuple of that value type and a message.
Java has been great for larger projects for a while, but I think smaller things like one-off scripts have been firmly out of reach so far.
It's good to see that change, as being able to use it in the small has obvious synergies.
why specifically?
Having to compile every time (or at least there not being a convenient wrapper that compiles and runs at once), the boilerplate of having to define a class and main method, exception handling, and most of all having to deal with Maven.
Other pointers are either opinionated or minor. From another hand, if dev has experience in Java, benefit of not learning some new language/ecosystem is kinda huge.
result, err := callFoo()
if err != nil {
return nil, err
}
Go is good for middleware coding thanks to Go-routines and and excellent networking support in the standard library but is cumbersome slow and inexpressive for scripts.
Also go.mod does NOT separate dev/test/prod dependencies - unlike Java Maven or Rust Cargo. You don't want your script dependencies coming into production code.
Also, in many areas Java's standard library is more expansive.
Also, go run is almost like running a script.
package main
import "fmt"
func main () {
fmt.Println("hi")
}
// go run file.go
Adding dependencies with `go mod` is uneventful.
It will never be as 'scripty' as JS or Ruby, but the readability, safety and performance are totally worth it.
Is limited features (Go) gonna be better for AI generation then breadth of examples? (C#). I'm not sure.
puts "hi"
As I mentioned, yes, it's verbose, but simple and worth the effort and peace of mind. My primary language is JS, I've written a fair share of shell and Ruby but would still choose go a lot of the time, just because it doesn't pull in any extra complexity.
This is part of my standard Go build.sh script. You just never know who might want to run a given thing where.
It was really dumb, but that's what the client needed. So much cross compiling.
GOOS=linux GOARCH=amd64 go build
GOOS=linux GOARCH=arm64 go build
GOOS=darwin GOARCH=amd64 go build
Which again, let's me distribute a binary to my end user as a single file, without directing them to install java or python3 or whatever.
(The ARM question is kinda immaterial, but I'm curious)
Mac people, for a few years now.
Overall, I think Kotlin is a vastly superior language to Java and spanks Scala in discoverability and legibility (less magick moar bettar, IMHO)
Kotlin on the other hand had better IDE support in intellij for obvious reasons. That was not nearly compelling enough for me.
But, in short, you can write kts shell scripts; import any library you want, use anything in the JVM or the Kotlin or Java library ecosystem that you need, etc.
Works on the command line (you need a jvm and kotlin installed from your favorite package manager). The Kotlin Jupyter kernel also uses kts and this is a nice way to use Java stuff in jupyter.
I use Kotlin scripts (.main.kts) as a replacement for Bash scripts for years.
You can inline dependencies without additional tooling, and Kotlin is still much more expressive than Java.
- Top-level functions/main is supported - data classes are approximately as good as records - A scripting mode comes built in, and can use annotations to import and use dependencies within the same file - There's a repl - The keyword 'var' exists, and the keyword 'val' is more ergonomic than 'final var'
The only thing I remember missing from the article is the implicit imports which I don't remember Kotlin having. Regardless, I'd reach for Kotlin every time. I think funnily enough Java never fully clicked for me until I started using Kotlin, which in many ways is "Java, except many best practices are on by default".
I was also surprised when I looked at it again a year ago.
I would have used it for my latest Web app but django just beat Spring boot.
"Wow! It's even worse than I remember!"
"Wow! How many files and directories does this project NEED? It's like someone decided that it's easier to manage files than code..."
...and there's still XML everywhere :(
One nit:
> Python programmers often use ad-hoc dictionaries (i.e. maps) to aggregate related information. In Java, we have records:
In modern Python it's much more idiomatic to use a `typing.NamedTuple` subclass or `@dataclasses.dataclass` than a dictionary. The Python equivalent of the Java example:
@dataclasses.dataclass
class Window:
id: int
desktop: int
x: int
y: int
width: int
height: int
title: str
@property
def xmax(self) -> int: return self.x + self.width
@property
def ymax(self) -> int: return self.y + self.height
w = Window(id=1, desktop=1, x=10, y=10, width=100, height=100, title="foo")What do you do when another module needs ymin, inheritance?
OO is dead, leave it buried umourned.
And yet so many programming languages, including JVM languages like Scala or Kotlin, just don’t do checked exceptions, and the world hasn’t caught fire yet (and in fact, I can’t think of another mainstream language that does have them). Java could just drop them altogether and everyone (except maybe the most devout Java fans) would be happier.
> The file gets compiled on the fly, every time that I run the script. And that's just the way I want it during development or later tinkering. And I don't care during regular use because it's not that slow. The Python crowd never loses sleep over that, so why should I?
Java takes significantly longer to compile than Python does. My Python takes ~40 ms at first startup of a hello world script, ~20 in later attempts. `java hello.java` is in the 360-390 ms range.
There is nothing wrong with checked exceptions and there is really no difference between a Result and a function with a checked exception.
fn a() -> Result<String, SomeError>
String a() throws SomeException
Programmers across every language ecosystem are moving towards checked errors and away from unchecked runtime crashes. Even Kotlin, a language that shipped with unchecked errors, is planning on adding a form of checked error handling [1].
[0] https://docs.scala-lang.org/scala3/reference/experimental/ca... [1] https://youtrack.jetbrains.com/issue/KT-68296
That's still pretty negligible. I don't think he's making a strict comparison, just saying that in both cases it's barely noticeable.
Shame the link is broken, looked fascinating!
Postgres also had a long-held reputation for being slow and difficult, but it made incremental improvements for decades and now it's the default choice for databases.
I see Java in the exact same position, as the Postgres of languages.
It feels like these frameworks are now just falling away, which is great. I'm not even hearing about Spring anymore, and if there is any reason to not use it, it would be this cringe "how do you do fellow kids?" blurb I just saw on their front page:
> Level up your Java™ code
> With Spring Boot in your app, just a few lines of code is all you need to start building services like a boss.
I personally would reach for Go by default, but I have no ill-will to Java.
Given, they are still quite reflection-heavy and full of POJOs and annotations, it supports compile-time resolution for many things now.
Also, you would be hard-pressed to find a more productive developer than a well-versed Spring boot guru for typical backend jobs. You might dislike the framework, but credit where it's due, it is a workhorse and the amount of time someone makes a POC, you can make it with spring properly, in a way that you can build your prod app on top. Like, it's easily as productive as RoR and similar.
Pretty much any modern computing problem you have, Boot has you covered[1].
So while you may not have ever used a Streaming library before, if you know Boot, then the Spring Boot Streaming library will already be familiar.
The eco system is a huge force multiplier, and is constantly evolving. Spring Boot simplifies that a lot by simplifying the setup to the point where you often only have to add a single dependency, and everything is configured with default configurations (which you can change if necessary of course)
Just look at all the different projects under the Spring banner: https://spring.io/projects
One example is the new Spring AI, where they have abstracted a lot of functionality and you can change providers (OpenAI, Mistral, AWS, Azure, Google) easily.
It would be hard to convince some people of this, because "everyone knows Spring is enterprise". Unfortunately many only have experience with legacy companies, bad code or through reading old blog articles, and base their opinions on that.
It's actually something you need to have experienced yourself to recognize the possibilities.
It may sound strange, but I enjoy going through the long list of projects in the Spring web site. I almost always find something cool and is surprised at how much they can simplify complex functionality
The learning threshold is also relatively low, because they tend to use common best practices in the framework.
I like Kotlin, but the lack of checked exceptions really kills it for me. Exception safety is a bigger thing for me than null safety.
I agree with the sentiment, but I'd move up to a version with type inference at least. I have nothing against static types and in fact in a vacuum I prefer them, but the particular brand of OO and "weak" generics that Java and C# have feels like filling forms in triplicate. "var" alleviates that significantly.
Conversely, in Java you often use the diamond operator like in:
List<String> items = new ArrayList<>();
That doesn’t work with “var”. You’d have to write:
var items = new ArrayList<String>();
The loss of directly seeing the type information in statements of the form
var foo = bar(x, y);
I've wrought my hands over this and eventually came to the conclusion that developers in every language that started with local type inference have embraced it. So I've mostly ignored my concerns and gone with "var for everything".
If you have trouble with a type then rename the function or variable (AKA your "foo" and "bar" example. The names are bad, fix them. Context matters, we have none here. No one has an editor that displays a single line of code at a time.). But in general we haven't had issues on our projects.
Beyond that, my IDE (Intellij) makes it easy to uncover the inferred type if I really need to be 100.00% sure what it is. In general I don't, because in general I don't care, and even before 'var' I was generally ignoring the type anyways.
Even in your example, narrowing the variable doesn't make much sense - you are in a local scope, you control everything. Narrowing is more meaningful in fields, where var won't work by design.
Locally a well-named variable is often significantly more important than some long, somewhat useless type signature, especially when the right hand side makes it clear.
.NET has true generics with full type information and struct type parameter monomorphization which works the same way generics do in Rust.
Edit: C# does have type inference for generics, just not the full HM one. It is also quite more capable for lambdas which is a bit frustrating because it does not resolve nested generics otherwise. I miss it - F# does it the way it always should have been.
There are many other differences small and big that arise from the way Java does generics and the fact that primitives can't participate - you will never see `IntStream` kind of workarounds in C#. Some libraries abuse and misuse generics for no profit (looking at you Azure SDK), but it's not as widespread. Shallow generic types are always inferred from arguments.
You may not see that in Java in the future either. Java will have value objects from the Valhalla project, and part of the plan is to replace Integer with a value object. Then there will be less of a reason to use raw int primitives, because the JVM can treat value objects much more efficiently than normal objects.
All APIs and collection types build on this foundation, with standard library leveraging generic monomorhpization for zero-cost abstractions. Code that would have needed C++ implementation in the past is naturally expressed in pure C#. Generics are fully integrated into the type system at IL level, avoiding special-cased types or bespoke compiler handling (besides monomorphization).
This enables numerous zero-cost features: tuples (unnamed/named), structs with controlled mutability and record structs, pattern matching, stack buffers that do not rely on escape analysis, structs with byref pointers for slice types (Span<T> and friends) which a good two thirds of the standard library accepts. Numeric and vector primitives are used in a simple way without setup requirements like Panama Vectors.
While project Valhalla will get Java's foot in the door in some domains, it will remain a less optimal choice than C#, C++, Rust, etc. Java's evolution primarily serves its ecosystem's needs, whereas C# benefits from being a newer language that learned from both Java and C++ and got influenced by F# and other research projects inside MS. This makes C# more idiomatic and terse. The historical drawbacks - platform lock-in, being closed-source, and having relatively weak compiler - have been resolved over the past ~9 years.
Boot is something entirely different. You write very little code and get a ton done. The trade off is you are firmly now a "Boot" codebase, but once you learn how Boot works it's not a big deal.
Frameworks are frameworks, not libraries. You can't just start writing/understanding them - frameworks are different from libraries precisely because they call your code, not the reverse.
Some people hate to write the same basic things over and over. That's where a framework excels. Write only the glue/logic you need to make your app work.
The way you have described your experience with Spring Boot seems to imply you did not take the time to learn it at all, and therefore its' unsurprising to us you had a hard time of it.
You do this 18 times because you have 18 different apps with similar requirements but deal with different data/endpoints/whatever.
On your 19th app you decide to standardize how you cobble together all of these libraries so that you don't have to start at ground zero every single time.
Now you've invented a framework.
How else would you architect with this in mind? Given that literally every other framework is quite similar (RoR, PHP's solutions, etc).
There is another niche, the HTTP server libraries, but they are much more low level.
Hibernate eventually got entirely nuked, Spring we couldn't entirely unwind easily; it had caused a whole bunch of crappy architectural issues and was too much effort to rewrite from scratch.
Although the code looked simpler using the frameworks and annotations, it was actually a huge rotten mess that didn't work well at all, with workarounds for all kinds of weird things in it.
I do agree that new ecosystems (js for instance) makes you miss some of the old big languages development feel. less churn
The only thing I don't like is how there is no built-in JSON package which seems like a necessity these days.
Removing the public static void main(String[] args) business seems like pandering to a non-existent audience, or at least a miniscule and insignificant one. Anyone who is going to use Java for a real project is not going to be worried about that, and anyone who thinks that's too difficult to deal with is never going to be a good programmer anyway.
If you want to introduce someone to programming, you probably don't want them to worry about what all those 'magic words' do.
At least for their first steps, they won't need to know what a class is or what `public` and `static` mean.
About the first steps of a newcomer, there's always going to be some level of "don't worry about this now, we'll see what this means later" for any language. I remember this to be the case for every tutorial I read to learn a language. And it's fine, as long as you can try stuff and it doesn't get in the way.
I'd say it's more important for a language and its vocabulary to be well structured and well documented for a newcomer and Java does quite good on this front.
Sure, if you are incapable of learning what a couple adjectives mean you won't go far, but that holds for much more than software.
Rather it's not important that the ball is big and blue so much as that you can kick it across the field - learning what the ball means can come later, but it's just unimportant noise (to start).
Java is pretty bad at this, though, insisting on specifying unimportant details up front rather than allowing for qualification. This is OK for a large monolithic application with complex requirements and a litany of edge cases, but inappropriate for many smaller use cases.
I still feel like the author is missing the forest for the trees. Bash is not great to write e.g. a red black tree in or do complex image processing, but you don't have to maintain a Java install, download libraries, or setup an editor with an LSP (and really, calling java script.java 10 asdf? Why do I need to invoke Java at all? At that point, I'm probably going to wrap it in a script anyways...)
Python has its own issues but it's a small, embedded install that you don't have to accept 5 different licenses for and worry about it being able to get the same version...
And bash? That's what pacman -S jq is for - anything I can't easily do in bash or batch I just offload to a small utility written in python or rust.
Java is, at it's core, just too heavy, IMO.
There is also jre-openjdk-headless, for 140 MB. How is that any different than Python?
This "java too heavy" is like 30 years out of date, if it has ever been true.
"error: target not found: jdk-openjdk"
> And java has never done such a breaking change as python did.
I'm not really sure that's true? Java 8 to afterwards, there are breaking changes that mean a lot of old enterprise stuff can't easily move forward, or worse, bytecode incompatibilities mean source-code-less stuff can't be used anymore...
The whole thing about Graal is mentioned almost as an afterthought, my point is that the language etc. is so poorly designed as to be prohibitive to interface with unless...well you're on Java. Yes there are bridges etc, but a big point of the shell, bash, etc. is easy interoperability between many programs, etc.
Java is still today stuck in a mentality of "it doesn't exist if its not in Java", which is why yes, 30 years later, it is still "too heavy". Assuming you are the effective Operating System is an extremely heavy assumption.
Also, I neglected to touch on this point more, perhaps license is not the right word, as much as distribution - I don't know if you have ever tried building the JDK (not simple), or worked with the official JDK vs the open one (not the same functionality), or tried to access old versions of the SDK on the official websites, or had to deal with their installers, etc.
Giant headache and all around.
Not to mention, even if your pacman command works, this is still simply not comparable, the example I used was for installing a jq binary because JRE simply doesn't include this functionality by default...
And now you need the overweight pom/gradle mess to interface with the Java libraries because <insert technical debt reasons here>
Under Sun there were differences, but Oracle open-sourced every last difference and now there is only some Oracle branding logo as the only difference (and maybe some tiny proprietary codec, but your code will run on both the same way).
I learned Java when i was 15 or 16, reading some random book first and then I stole 35 euros from my mother's purse and bought a copy of "Java how to program" by deitel and deitel[1]. The recommended version at the time was Java 5, and the SJCP certification was still issued by Sun Microsystems.
I can tell you, "public static void main" is not going to be the problem.
[1]: looking back (i'm in my 30ies now) sometimes I wonder if i would have been better off buying weed or alcohol (or both)
Way to disparage a random person on the internet.
What other language would you start with?
And isn't it easier to introduce concepts one at a time? For that reason implicit classes makes sense, and also for the occasional scripting, as in doing something one-off, but it is not as trivial that I can do it with piping 3 commands together.
True. But you need to know too many of them to get anything to run.
> that is typed so many of your first attempts will be caught with helpful messages at compile time
But it doesn't feel that way. It doesn't feel "helpful", it feels nitpicky. It feels like I have to get everything exactly right before anything will run. For a raw beginner, that's very frustrating. It is (emotionally) better to have something run as far as it can run, and then crash. (I agree that exceptions pointing to the line number are very nice.)
Again, for a semester class, the startup overhead for learning Java is too small to worry about - it's maybe a day or two. But for someone on their own, not in a class, a day or two is a huge investment to put in before they can get something running!
What would I start with? Something with a REPL. (It could be a language that is normally compiled, but there needs to be a REPL. Raw beginners need to be able to get something, anything, to work as quickly as possible.)
Your csci 101 kids will not benefit from unpacking what it means to compile an object-oriented language down to bytecode to run on a virtual machine. It's not that it's not valuable knowledge, they just won't have the context to make meaningful heads or tails of it.
related: I still puke a little remembering the requirement that students work on assignments in emacs on terminal machines rather than their text processor of choice(which was fine for me, but why on god's green earth would you put usability warcrimes like 'hjkl' in the way of someone just starting to learn? No wonder nobody in the early naughts wanted to learn to program...).
Along with all the BS boilerplate text this specific post talks about eliminating, which is great, we simply forget how much legacy tech BS we just assume.
Beginner programmers should not have to know what a "file" is, or what an "editor" is, or that they need an "editor" to "edit" a "file". This is technical debt: these are implementation details which should be invisible.
This goes double for "compilers" versus "interpreters" and "source code" versus "binary code". FFS the noun _code_ means _a system for rendered text unreadable_.
You have a computer. You are talking to it in words, words which resemble English because that is one of the simplest world languages when you think about scripts -- writing systems -- as well as sounds. Hangeul is easier but only works for Korean which is harder than English. Grammatically Chinese is simpler, but spoken Chinese has tones which are very hard, and written Chinese is insane. Typed Cyrillic is no harder but handwritten gets weird and complicated and Russian is much harder than English. And so on.
English wins and so we talk to computers mostly in English.
So, you have a computer, and you type on it in English. That is all you should need to know: how to enter text, how to correct it when you get it wrong, and that is it.
BASIC has a great virtue which all the Unix and even the Lisp fans forget:
It's designed to work at a command prompt. Type a command, the computer does it. Give it a number, it remembers it for later.
This is a profound and important metaphor. It eliminates all the 1960s/1970s legacy BS about "files" and "folders" and "editors" and "compilers". Beginners don't need that. Let them learn that later if they prove to have real aptitude and want to pursue this.
Type a bare expression, the computer does it. Number it, the computer remembers it for later. That is all you need to get writing software.
And just like Python sorted out the problem of spoiled whiny little baby C programmers whinging about their pathetic obsessions with indentation patterns by making indentation semantic so everyone has to comply, line numbers in BASIC are a vital simplifying unifying mechanism, so lean on them: for beginners, make line numbers syntactic.
Don't force kids to learn pro tools like nomenclature and hierarchies. Give them a toy that they can get started with.
At first, they can structure their programs with line numbers, and they learn about leaving space, about RENUMBER commands, about LIST x TO y ranges, and stuff like that, because we are not using a bloody Commodore 64 any more.
But give them IF...THEN...ELSE and WHILE...WEND and REPEAT...UNTIL and named procedures so they can learn structure and not GOTO.
All the rest is baggage and should be deferred as late as reasonably possible.
On the other hand, viability, classes, and "staticness" are all fundamental structural concepts in Java. Hiding them for a special case is sort of like lying, and, in the long term, I can actually see this special case causing more confusion for new learners. It's sometimes better to be upfront and transparent and force your users to work with the paradigm and semantics they chose to adopt, rather than pretend it doesn't exist. If Java had been designed to allow for top-level functions from the start, it'd be a different story. I think special casing is a generally bad way to evolve a programming language.
You simply get an unnamed implicit class like `class Tmp367 {` written at the top, and the runtime loader has been modified to be more accepting of main methods. There was basically a tiny language change, and no bytecode change, java semantics are just like they always were.
The Main loader just simply will accept an instance method named 'main' for a class with an empty constructor with no args, instead of psvm.
Perhaps the audience doesn't exist because of that business. There are many times when I would have used Java over Python to write simple programs for no other reason than having the ability to create a GUI without resorting to third-party libraries. Yeah, Python has tk but it has never clicked with me in the sense that Swing does. Unfortunately, cramming every last thing into an OOP model means that simplicity is rapidly lost. (The same can be said of Python, except Python has not forced it. Java, historically did.)
Pretend you are a college student and you are taking your first programming class (e.g. CS 1) and your friends have told you that Java is "verbose". You start with "hello world" and you have to type `public static void` etc. One of your friends shows you the same code as a Python 1-liner.
Or similarly you're a beginning programmer in the workforce and your employer asks you to solve a problem using Java. You've heard Java is verbose and when you start with "hello world" you find that what you heard was true.
This is not a non-existent/minuscule audience. They should have fixed this decades ago. Better late than never.
I've been impressed with the modernization of Java over the last 10+ years. Simplifying "hello world" is a minor change relative to the others, but still an important one.
I watched most of my comp sci 101/102/201 classmates fail out because they didn’t want to understand how things worked, they just wanted to make a lot of money.
Edit: hn even helped me prove the point: https://news.ycombinator.com/item?id=42457515
Teach that to a 10 year old, where their primary keyboard experience is a phone.
More than that, if rust is the future, which I have seen espoused before, picking on the Java keywords and syntax is highly amusing.
Now, if one is learning java as a second language, that's a different story.
https://jakarta.ee/specifications/platform/10/apidocs/jakart...
If it's part of J2EE, it's in practice "part of Java" since the JDK comes with the J2EE packages built-in...
That is, it came with the J2EE packages built-in, until Java 11 decided to break everything, and force people to get each piece of J2EE from a separate upstream project, with AFAIK no "all of J2EE" uber-jar you could simply copy into your project to restore the status quo. It's no wonder so many projects are to this day stuck on Java 8.
Are you sure about that? I just downloaded the Java 8 JDK, and javax.json is not there. And the documentation doesn't mention it either. What am I missing?
Also, thank you for sharing! I do appreciate Java and I’m glad to see it can be used for scripting nowadays.
The difference is so stark it's no longer amusing. Performing setup for complex Java projects has me go through similar steps as if they were written in C++. Performing setup for C# projects of comparable complexity usually requires just cloning and hitting 'dotnet run', much like it usually happens with Rust or Go (some may claim I undeservedly bash it but credit is where credit is due).
I love your identity with .NET ecosystem, to the point of nothing else being in the way.
See latest JetBrains Developer Surrey about platforms.
.NET is a great ecosystem, but lets be real where it stands outside Microsoft shops, across everything that has a CPU on them, and the various ecosystem where sadly it doesn't even get a tier 1 support.
Programming languages are tools, a toolbox has space for plenty of them.
Meanwhile I can 'git clone https://github.com/ryujinx-mirror/ryujinx && cd ryujinx/src/Ryujinx && dotnet run -c Release' and it works on the first attempt (though takes a moment to pull nuget packages, it's a big project).
The Java ecosystem has incredible projects from the technical point of view (GC implementations, OpenJDK's JIT compiler), but the tooling and application packaging and distribution seem like the painful parts.
There is "gradle init" to scaffold a project, or of course IDEs offer a GUI over that.
Additionally, your "dotnet run" does require the dotnet tool to be installed and of the right version. The Gradle/Maven equivalents now no longer do, because they bundle scripts into your repository that will download and run the build tool itself of the right version. They just need some moderately modern Java installed. Everything the project needs including possibly a newer Java will then be downloaded.
I'm not sure what the point of naming individual projects is. I can point at dozens of projects off the top of my head where you can just clone and run them without incident.
There are painful parts of both Gradle and Maven. Absolutely. They are very far from perfect build systems. But this is partly because they do a lot more than tools like cargo does.
It only needs an SDK installed on the system. If you have the necessary framework dependency, it will just work. If it's missing - the command output will specify this, which is solved by doing `sudo apt install dotnet-sdk-{version}` or just `dotnet-runtime-{version}` (because newer SDKs can build most older targets). You can also usually roll-forward the applications without retargeting them or installing older runtime (which is trivial still). It's a reliable and streamlined process.
Probably one of the best approaches to managing the SDK and framework dependencies that does not rely on any form of help from external tooling or IDEs.
Gradle and Maven need JDK installed in either case. I had Gradle that shipped with the code crash on me because it was sufficiently old to have issues on newer OpenJDK versions. Solved it by installing properly, but you can see how it can be an error-prone process.
------------------------------------
Ultimately, if you're an expert and it's a long-term project - none of this matters, solving odd breaks and tooling issues is part of the job. It's nice when things work, it's not unexpected when they don't. Some languages have more of this and some less, but at the end of the day due to business constraints and company environment none of this is a showstopper per se - you just deal with it.
Do I think the CLI tooling, dependency management, packaging and distribution is painful in Java or Kotlin? Yes, it's what also precludes either from being productive scripting languages unless you have nailed the setup that works around all of these. Does it matter for writing complex applications? Not really, project and environment setup for such is mostly one-time thing. It's coincidentally where Java ecosystem shows its strength. My rant here is posted because I believe we can discuss pros and cons without stating that specific issues don't exist when they do or vice versa.
Among everything I tried Cargo, .NET CLI and Go had the smoothest experience of things mostly working and when they weren't - not requiring to dig through heaps of documentation, possibly dumped into a language model to catch the exact specific piece that would help to solve the puzzle. I heard good things about Python's uv. If actively maintained, Node.js projects also work reliably, not so much when they aren't though. Some C++ projects are kind enough to offer build scripting that works out of box on Unix systems - props to the maintainers, which is also the case with Java projects. But whenever either of the last two didn't work, it often took me the most effort and swearing to get either working, unlike other languages.
git clone https://github.com/...
cd somedir
mvn spring-boot:runhttps://learn.microsoft.com/en-us/powershell/module/microsof...
One thing to note is I find `dotnet fsi {some script name}.fsx` taking more time to start than ideal - up to 800ms is just too much, normal .NET applications usually start in a fraction of this.
I recently posted a submission here for "FSharpPacker" written by my friend that lets you compile F# scripts to standalone applications (either runtime-dependent, self-contained or fully native binaries, much like Go), it also has some comments on getting the best mileage out of it: https://news.ycombinator.com/item?id=42304835
Probably the best feature that also comes with scripting (both C# and F#) is "inline" nuget references e.g. #r "nuget: FSharp.Control.TaskSeq" which will automatically pull the dependency from nuget without ever dealing with manually installing it or tinkering with build system in any other way.
Some additional links:
https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp...
https://github.com/dotnet-script/dotnet-script (C# is also a quite productive language for scripting and small programs because of top-level statements, record types, pattern matching and many other functional features though perhaps not as strongly represented as in F#, it's just very unfortunately abused in enterprise world, with teams often going out of their way to make the code far more bloated than necessary, against the language design intentions)
Already disagree, haha
I have to say I find it an odd choice for small replacements for bash scripts. I think python or golang are probably better choices for that purpose. Java is one of those 'enterprise' backend languages which lend itself to making a team productive over making the individual productive, and I say this as a java / go dev who's most comfortable with java for most backend work.
I just loved his lectures, very dry sense of humor, and extremely funny.
He was just getting started writing books in the early 90s. He has this awesome way of thinking about programming, that I imparted to my own students when it came my turn to teach programming. I wish there some videos of his classes that I could go back to and share with people.
Good website also, https://horstmann.com/
The picture on the website with him in the row boat has a funny story with it. When asked why he is in a row boat, he would reply, "Students are in the row boat with me, learning to program. At some point I push them out of the boat into the eel infested lake. The ones who are clever enough to make it back to the shore will be good programmers." All of this said with a faint hint of a German accent and a sly smile.
If you happen to read this, Dr. Horstman. I made it to shore. Thanks! It has been an awesome journey!
What I remember most is his obsession with Emacs.
There was one time that I was grateful though, I had to buy a few of his books and one of them had a defect from the printer, so he helped me get a new copy from the publisher for free.
That's a really insightful way of presenting this. I think if that's how I'd been introduced to Java I might even have tolerated it.