Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

Post reply on HN
Print view View original

451–460 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#451

Post by al_mandi »

oflannabhra wrote: post #447
cutler wrote: post #416

Earlier quoted context omitted.

Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?

Yes, thank you. Spring Boot is annotation hell. Annotations are the worst part of Java—it’s what happens when a language can’t support a true DSL. Just as ridiculous is the HttpSecurity method chaining “DSL”.

Java annotations can support compile time validation (e.g. see micronaut or checker framework). DSLs don't.

Re: Don’t call it a comeback: Java is still champ

#452

Post by al_mandi »

cutler wrote: post #416
nick__m wrote: post #341

Earlier quoted context omitted.

Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode...…

Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?

Why write many lines of validation when one line can suffice?

    @Entity
    class User {
        @NotBlank
        String username;
    }

    // Use site
    public User addUser(@Valid User user) { ... }
as opposed to

    class User {
        String username;
        public void validate() throws ValidationException {
            if (username.isBlank()) throw new ValidationException("username is empty");
        }
   }

    // Use site
    public User addUser(User user) {
        user.validate();
        // ...
    }

Re: Don’t call it a comeback: Java is still champ

#453

Post by al_mandi »

kaba0 wrote: post #398
tomohawk wrote: post #363

Earlier quoted context omitted.

Java has reached the status of Cobol - it is immortal because it is everywhere and has been around a long time. Because of that, there are a lot of Java devs. Our team works in Go, and so we get a few Java devs in once in a while as new positions open up. The biggest change for them is to get out of archonaut mode and stop overdesigning everything. After going through a 3-6 month cleanse, it's fun to see them complai…

That’s funny because Go is much less expressive than even Java. If anything, their overdesign seems to come from their juniority and badly ingrained “best-practices”, nothing inherent in the language.

Having used both at different employers, I agree. The golang code I've seen was much worse on almost every level than other code I've seen.

Re: Don’t call it a comeback: Java is still champ

#454

Post by al_mandi »

lenkite wrote: post #167
jeroenhd wrote: post #29

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

> My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Might want to give some evidence of this. Also, C# has no plans of green threads. It went the async/await way which is a pain.

Not to mention the slew of GCs that are available on the JVM which are second to none.

Re: Don’t call it a comeback: Java is still champ

#455

Post by cutler »

ahartmetz wrote: post #445
cutler wrote: post #425

Earlier quoted context omitted.

.Net 6 runs on Linux with, for example, PostgreSQL so how is that tied to M$?

MS still controls it in practice, and MS is still playing a complicated game with Linux, with goals that have nothing to do with "MS <3 Linux".

Yes, the scandalous SCO lawsuit and subsequent Linux patent racket make it impossible to believe M$'s Linux fud.

Re: Don’t call it a comeback: Java is still champ

#456

Post by kmac_ »

kinjba11 wrote: post #450
bcrosby95 wrote: post #144

Earlier quoted context omitted.

What stuff does C# objectively do better than Java?

I'd say the two big ones are: - Mature support for async/await since 2012. Yes, Project Loom is coming, a decade later.. - Support for generic-aware value types (struct vs. class) and low-level features like stackalloc: very valuable for high-performance scenarios and native FFI. See for instance https://github.com/ixy-languages/ixy-languages . In comparison, Java doesn't even have unsigned integers. Yes, Project Val…

Let me continue: no type erasure, type safe generics, switch case guards, native tuples, async/awiat in loops and lambdas, the language becomes more and more functional with every version, and on top of that, .NET Framework has quite coherent API/interfaces and tooling is much better. The single type erasure is a huge difference that makes those two languages quite different.

Re: Don’t call it a comeback: Java is still champ

#457

Post by cutler »

al_mandi wrote: post #452
cutler wrote: post #416

Earlier quoted context omitted.

Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?

Why write many lines of validation when one line can suffice? @Entity class User { @NotBlank String username; } // Use site public User addUser(@Valid User user) { ... } as opposed to class User { String username; public void validate() throws ValidationException { if (username.isBlank()) throw new ValidationException("username is empty"); } } // Use site public User addUser(User user) { user.validate(); // ... }

I was thinking more about @RequestParam validation eg.

    fun calc1(@RequestParam @NotNull @Size(max=10) @Pattern(regexp = "^\\d{4}-\\d{1,2}-\\d{1,2}$") date:String,
              @RequestParam @NotNull @Size(max=5) @Pattern(regexp = "^\\d{2}:\\d{2}$") time:String,
              @RequestParam @NotNull @Size(max=40) @Pattern(regexp = "^[-_'A-Za-z/\\d]{2,50}$") zone:String,
             ): Map {
Why stuff everything in the param list? No other framework I can think of proliferates annotations like this. Spring annotations being Java-based means I must suffer Java's ridiculous inability to handle regex metacharacters - even after introducing raw string literals in Java 13. Kotlin handles this perfectly but once I'm in Spring annotation-land Spring's touted Kotlin compatibility goes out the window.

Re: Don’t call it a comeback: Java is still champ

#459

Post by neonsunset »

With Unity, Avalonia/Uno Platform, ASP.NET Core, NativeAOT and compact self-contained trimmed JIT deployments, the sheer cross-platform, cross-workload and deployment flexibility proposition of C# far surpasses Java even if we count in JVM + Kotlin for additional points of the latter.

Now let's talk performance of most commonly used web frameworks. I will save you the trouble of reading long text. Just check https://www.techempower.com/benchmarks/#section=data-r21&tes... and search the tabs for the more popular Java frameworks like Spring, Spark, Struts, Grails, Wicket, etc.

You may find yourself surprised, finding most of them in the bottom 25th percentile. Now scroll back to the top of the page and check where ASP.NET Core is. That's right, more often than not, in the top 10. All that performance, and you get it out of box just by using defaults and then some more. The only exception I see is Vert.X which is both mentioned across the web and also present in the top of the list.

Now, you may say that it's not very representative and there are entries of dubious usefulness in production scenarios (looking at you Just.js). And you would be right. However, the way to get most performance from ASP.NET Core is not by using tricks but rather simply writing code like in Node.js with app.MapGet("/users", delegate) and friends.

Despite all this, I still think JVM technologies like Hotspot or GraalVM have an upper hand over what .NET JIT/NAOT is capable of. However, keep in mind the out-of-ordinary performance gains that C# gets with each subsequent release. In areas with significant possibility of improvement like arm64 codegen quality, moving from .NET 6 to upcoming .NET 7 will yield you up to 40% performance improvement from JIT alone. And it was done in significant part by changing the code of JIT/Runtime that used to be x86_64-first to being cross-platform oriented (e.g. Vector codepaths becoming plat-agnostic, correct atomics being emitted for ARM, etc.).

.NET Framework used to be stagnant. After becoming OSS, .NET is the polar opposite, getting significant improvements in all of its areas with each release be it runtime code, standard library, language features or supported usage scenarios.

I think today, C# and .NET are mostly being held back by decades of legacy libraries and decisions, which you may consider avoiding in favor of newer solutions, regardless if those are in BCL or community-driven libraries. Still, sometimes people simply use code in such a way that unreasonably kills its performance. But as long as you avoid known gotchas, your C# code will easily perform in production at the speed of Rust, C++ or C.

Re: Don’t call it a comeback: Java is still champ

#460

Post by al_mandi »

kentonv wrote: post #349
kelnos wrote: post #332

Earlier quoted context omitted.

> I once worked on a Java-based server at Google that had to answer requests with millisecond latency. That's... not really normal, though, and sounds like the exception that proves the rule. For the vast majority of applications, Java will perform better, be easier to develop, and be safer to run, than an equivalent server written in C or C++. At my previous job we used to run realtime audio through a Java server (R…

> But I would not call writing distributed network servers "systems engineering", I would agree that a web application server is usually application engineering even if you are running 1000 replicas of it. I would not write these in C++. (Well that's a lie, I probably would but I would admit it was a terrible idea.) On the other hand, the container engine that orchestrates the web app server is systems engineering, a…

Kubernetes, a container orchestration engine, is written in golang, a language with garbage collection. Some database engines have also been written in golang.

Same with Java, several databases written in it, such as QuestDB, Pinot, Presto.

Post reply on HN