As much as I love Java, everybody should just be using Rust. That way you are actually in control, know what's going on, etc. Another reason specifically against Java is that the tooling, both Maven and Gradle, still stucks.

▲

jayd16 6 hours ago | parent | next [-]

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code. The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times.

Gradle does suck and maven is ok but a bit ugly.

▲

ActorNightly 4 hours ago | parent | next [-]

Lets look at Java in modern day.

* Most mature Java project has moved to Kotlin.

* The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java.

* Log4shell, amongst other vulnerabilities.

* Super slow to adopt features like async execution

* Standard repo usage is terrible.

There is no point in using Java anymore. I don't agree that Rust is a replacement, but between Python, Node, and C/C++ extensions to those, you can do everything you need.

▲

dionian 6 hours ago | parent | prev [-]

LLMs take the whole argument away. Yes, maven/gradle/sbt suck to work with. But now you can just generate it.

	▲	dionian 12 minutes ago \| parent [-]
		I've been using maven for 20+ years, gradle for 10? ant for 5 before that. sbt for 15. I've written custom plugins for all of them. I know them quite well, unfortunately. I use LLMs to maintain them now. I keep the build files simple. It was an inconvenience before, but a trifle now.

▲

piva00 7 hours ago | parent | prev | next [-]

Gradle does suck, it gives too much freedom on a tool that should be straightforward and actively design to avoid footguns, it does the opposite by providing a DSL that can create a lot of abstractions to manage dependencies. The only place I worked where the Gradle configuration looked somewhat sane had very strict design guidelines on what was acceptable to be in the Gradle config.

Maven on the other hand, is just plain boring tech that works. There's plenty of documentation on how to use it properly for many different environments/scenarios, it's declarative while enabling plug-ins for bespoke customisations, it has cruft from its legacy but it's quite settled and it just works.

Could Maven be more modern if it was invented now? Yeah, sure, many other package managers were developed since its inception with newer/more polished concepts but it's dependable, well documented, and it just plain works.

▲

koakuma-chan 6 hours ago | parent [-]

I would disagree that either "plain works" because to even package your app into a self-contained .jar, you need a plugin. I can't recall the specifics now, but years ago I spent many hours fighting both Maven and Gradle.

	▲	piva00 6 hours ago \| parent \| next [-]
		Well, yes? It's a feature provided by a plugin, like any other feature in Maven, you declare the plugin for creating a fat-jar or single-jar and use that. It's just some lines of XML configuration so it plain works. Like I said, it's not hypermodern with batteries included, and streamlined for what became more common workflows after it was created but it doesn't need workarounds, it's not complicated to define a plugin to be called in one of the steps of the lifecycle, and it's provided as part of its plugin architecture. I can understand spending many hours fighting Gradle, even I with plenty of experience with Gradle (begrudgingly, I don't like it at all) still end up fighting its idiocies but Maven... It's like any other tool, you need to learn the basics but after that you will only fight it if you are verging away from the well-documented usage (which are plenty, it's been battle-tested for decades).
	▲	looperhacks 6 hours ago \| parent \| prev [-]
		You "need a plugin" in the sense that every component of maven is a "plugin". The core plugins give you everything you need to build a self-contained jar - if you wanted to, you don't even have to configure the plugins, if you want to write a long cli command instead.

▲

shermantanktop 6 hours ago | parent | prev | next [-]

I’ll never understand the impulse to tell the entire world what to do based on your own personal preferences and narrow experiences.

It gets a reaction, though, so great for social media.

▲

pjmlp 6 hours ago | parent | prev | next [-]

Rust has no place other than deployment scenarios where any kind of automatic resource management, be it tracing GC or reference counting, is not wanted for, either due to technical reasons, or being a waste of time trying to change people's mindset.

▲

6 hours ago | parent | prev | next [-]

[deleted]

▲

krona 7 hours ago | parent | prev | next [-]

> That way you are actually in control

Programming in Rust is a constant negotiation with the compiler. That isn't necessarily good or bad but I have far more control in Zig, and flexibility in Java.

▲

koakuma-chan 7 hours ago | parent [-]

Yes, there is a learning curve to Rust, but once you get proficient, it no longer bothers you. I think this is more good than bad, because, for example, look at Bun, it is written in Zig, it has so many bugs. They had a bug in their filesystem API that freezed your process, and it stayed unfixed for at least half a year after I filed it. Zig is a nice C replacement, but it doesn't have the same correctness guardrails as Rust.

▲

krona 6 hours ago | parent [-]

Assuming we're talking about the same bug, The filesystem API freeze wasn't caused by Zig's lack of correctness guarantees, but a design flaw in Bun's implementation.

▲

dryarzeg 6 hours ago | parent | next [-]

Maybe I'm stupid, but I never actually understood people who blame programming languages for bugs in software. Because sure, it's good to have guardrails, but in my opinion, if you're writing a program and there's a bug, unless this bug lies somewhere in implementation of compiler/interpreter/etc, you can't blame the tooling, It's you who introduced this bug. It was your mistake.

It's cool when your tooling warns you about potential bugs or mistakes in implementation, but it's still your responsibility to write the correct code. If you pick up a hammer and hit your finger instead of the nail, then in most cases (though not always) it’s your own fault.

▲

chuckadams 6 hours ago | parent [-]

When millions of users constantly make the same mistake with the tool, there may be a problem with the tool, whether it's a defect in the tool or just that it's inappropriate for the job. Blaming the user might give one a righteous feeling, but decade after decade that approach has failed to actually fix any problems.

	▲	dryarzeg 6 hours ago \| parent [-]
		That's why I say "in most cases" - so not always, actually. There might be problems with tools, I'm not trying to deny that. And by the way, what if some (or even most) of the users just don't have enough skill to use the tool properly? Again, there could be a problem with tool, yes, but you can't always blame only tools for mistakes users make.

▲

koakuma-chan 6 hours ago | parent | prev [-]

https://github.com/oven-sh/bun/issues/18192

I am talking about this bug. It looks like it is still unfixed, in the sense, there is a PR fixing it, but it wasn't merged. LOL.

Regardless of whether this specific bug would be caught by Rust compiler, Bun in general is notorious for crashing, just look at how many open issues there are, how many crashes.

Not saying that you cannot make a correct program in Zig, but I prefer having checks that Rust compiler does, to not having them.

▲

j-vogel 7 hours ago | parent | prev [-]

I'm a fan of Rust too. But there are millions of Java applications running in production right now, and some of them are running these anti-patterns today. Not everyone has the option to rewrite in a different language. For those teams, knowing what to look for in a profiler can make a real difference without changing a single dependency.

▲

koakuma-chan 7 hours ago | parent [-]

I think that right now it is easier than ever to rewrite your app in Rust, due to LLMs. Unfortunately there are still people out there who dismiss this idea, and continue having their back-end written in much inferior languages, like JavaScript or Python. If your back-end is written in Java, you aren't even in the worst spot.

	▲	kykat 42 minutes ago \| parent [-]
		"You think" is cheap, try doing it, rewrite an existing library in rust and see how it goes. Doing a rough prototype is easy, but the real work starts after that.