Hacker News Reader

Comment by rr808 | Hacker News Reader

I've ditched Spring, am using Vert.x with Java 17, reactive & functional styles, records. Seems like a completely different language.

If only project Loom will get out there so I wont be coding everything like Javascript I'd be happy. :)

View on HN

Weird Spring is the reason why i am sticking to Java

Spring would be my only reason to ditch Java.

I just can't get past annotations as a thing. Seems like a crime against programming to me.

Well it is just another design pattern, i love annotations but it might be better even without it, Spring boot takes care of most of the things and it only needs very minimal annotation which makes sense.

I don’t know, I think it’s closer to some LISP magic macro than Lispers would like to admit. They are extremely powerful, and thus can be responsible for some very ugly code, but when used responsible, they are huge productivity wins.

Agreed. I hate digging through a mountain of annotations to try and decipher what additional side effects some method might have (additional to any existing side effects). I have never seen a codebase where annotations were some necessary compromise; I feel like whatever crucial parameters is being passed through an annotation could have just as easily been put into the arguments and made a part of the method signature like they're supposed to be. Annotations were a mistake.

Try CDI! much cleaner, faster, and without the Factory Factory Factories.

I’d rather write Spring than Vertx callback or observable hell.

The time I used vert.x in my day job was by far the best Java experience in my career. Completely different language. And the vert.x maintainers have been all around great wrt to responding to issues and/or accepting contributions. Great framework. It has it's quirks and limitations but overall I absolutely loved working with it.

Hmm Javascript has async though, no?

That's exactly what was meant. With Loom Java will hopefully not have the same function split as languages like JavaScript (or C# for that matter) where you have to add lots of async/await everywhere; and instead will have something like Go (where everything is async).

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Async stuff in JavaScript light years ahead of Java's Future madness. Loom might help but I'm not optimistic about it. For example Spring already kind of deprecated blocking http web client and new reactive WebClient is terrible. Will they create yet another BlockingWebClient? No they'll ask you to call `block` everywhere and write reactive nonsense filters if you need to enhance it.

Spring is worst thing happened with Java.

That may be true, but JavaScript forces you to bisect your libraries (and functions) into Those that Understand Async and Those That Don't [0]. There appears to be no path forward if you want to avoid that.

It's very difficult to write generic, reusable higher-order code that shouldn't care if it's doing a sync or async operation. Java at least is building a foundation in the right direction.

[0] - https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

If you mean that you can't write `map` which would work for sync and async functions with the same code, that's extremely rare problem IMO. If you really need that and don't want to write two versions of code, you can wrap blocking code with promises and use promise API from now on.

It's not at all a rare problem if you work in codebases involving async code. Many `Promise` APIs exist solely to work around that wart. Higher-order functions are the bread and butter of JS, and increasingly Java (especially modern Java).

But async stuff is a must in JS due to it being single-threaded (yeah I do know about webworkers).

Just spawning a thread with a scope which will fork them at the end is just better from every conceivable way. Easier to grasp, easier to maintain, easier to debug - all of which are quite important when concurrency is at the table.

I don't understand the part about go, does that mean go doesn't require async but gives you the functionality of async? (I never tried go)

The problem with async is that we can separate when to start a task and when to ask for its result. The compiler can just add await everywhere an async function is called, it is trivial, but you don't get the flexibility of async. If everything is treated as async, you will need to await everything (perhaps some syntactic sugar to allow for immediate await)

> If everything is treated as async, you will need to await everything

In go you work rather differently. You let tasks go off and do their thing, and provide a channel to communicate. Pulling a response from the channel is the 'await'. A good part of go's magic is that these tasks - goroutines - don't result in large amount of blocked threads.

Java will soon have the building blocks of something rather similar to goroutines.

OK I see, but I think these two approaches address different problems? The approach used by go is more powerful than async but also more verbose. The implementation is also different, async can be implemented with a generator but goroutine can't.

I guess I was confused because right now you do not code Java like that.

Reply on news.ycombinator.com