I didn't use Java since 7, but from people that do - nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".
Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack.
And then there‘s also Micronaut, if you prefer compile-time setup to Spring.
There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
There's a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.
A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.
That's weird. Back when Java 7 was a new thing, people used Spring (Boot wasn't there yet) even more to compensate for the lack of language features. Also back then most projects still used XML configuration, so you actually write more Java code in modern Spring. Because Spring Boot uses Java configuration classes by default (although you can still use XMLs if you need for some reason).
> Nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".
Subjective experience, but largely agreed.
Vague rant that summarizes my own experience: major version updates kind of suck, even if Spring Boot is still better than regular Spring (I've gone through the XML hell, was not fun, even less so with a separate Tomcat instance that we had to deploy to, instead of an embedded one). In practice their huge effective pom.xml also leads to conflicts when your package needs something else and it feels a bit arcane to override things. There are things that have underlying technical reasons for being the way they are but seem stupid from afar - like how @Transactional doesn't work when called from within the same bean. Personally I also prefer code over convention for configuration and initialization so the whole annotation driven setup feels quite annoying and difficult to debug when things go wrong - but even the code configuration isn't always great and sometimes it feels like they have abstractions for the sake of abstractions. Spring Boot also often brings friends like MapStruct or Lombok or Mockito which add even more dynamic behavior and issues when you update JDK, alongside slow testing with JUnit and unpleasant debugging of jumping through numerous abstraction layers. You don't strictly have to, but people will.
I probably should have written down every complaint with exact details (so those could be picked apart as user error) over the years that I've been unfortunately maintaining and building shitty software with Java, but I will say this - modern Spring Boot isn't wholly horrible, it has a pretty rich ecosystem and you can do a lot of things with it, but the overall vibe I get from it ofen can be summarized with "Eww." I'd end up using it because I have to, or because it's a means to an end ("Hey, we need to build an event-driven system to integrate with a bunch of others, you have two weeks"), not because I want to.
For the sake of comparison, I believe that for plenty of the folks even Dropwizard would be worth a look: https://www.dropwizard.io/en/stable/ it is more or less like some glue around a bunch of idiomatic packages in the Java ecosystem and it's not horribly hard to integrate something that you want yourself (e.g. Dagger 2 for DI, at this point I'll take anything that does as much as possible at compile time https://dagger.dev/dev-guide/).
Or, for a more modern spin, Quarkus isn't too bad either https://quarkus.io/ or maybe Micronaut https://micronaut.io/ or perhaps Helidon https://helidon.io/ with neither of those being strong recommendations - figure out what you like for yourselves. For people that have been luckier than me, that might as well be the very same Spring Boot, just on better projects. JVM is a pretty cool piece of tech though, and so are the JetBrains IDEs with their refactoring features and nice Maven integration.
Because it isn't a "supported" language. The source and target languages are just a text field with a drop down for recommendations. You can write anything you want in those text boxes. I've used it for Lojban too.
Sorry that I am too stupid to understand what Moment is.
It is a collaborative markdown file that also renders very fast. So far so good.
And then... it somehow adds Javascript? And React? And somehow AI is involved? I truly don't understand what it is, and I am (I think) the end customer...
edit: I tried it and I just get "Loading..." forever. So, anyway, next time.
Hey karel-3d, I'm one of the engineers working on Moment and would love to help figure out the issue you're running into. Would you mind reaching out via our Discord or email (trey@moment.dev)?
unfortunately I cannot reproduce the "Loading..." issue. Now everything works. (I still don't fully understand Moment. But reading Agents.md ironically helps me understand it a bit.)
How is Ceno making sure someone is not poisoning the cache?
edit: I try to read the paper and it's just referencing some RFC, which is not making me smart at all.
Again, how am I sure that when I am reading something from the cache, it's really serving what the site was serving somewhere else, and the person saving it there didn't modify it? Is it signed by the original page SSL cert?
edit2: ahh the "injector server", which is run by Ceno, retrieves the page and signs it. So you are moving the trust to Ceno and the central Ceno server actually does the browsing...? So the injectors can just see all the traffic? But that's inevitable I guess, someone needs to see the traffic
800 lines config to compile code that's later interpreted is wild. I get the general idea behind having a script instead of a static config, so you can do some runtime config (whether or not we should have runtime changes to config is a different conversation), but this is absurd.
I'm a big believer in fully reviewing all LLM generated code, but if I had to generate and review a webpack config like this, my eyes would gloss over...
Oh yeah, I got that - my comment is a bit confusing reading it back. The fact we used to built trash like that blows my mind. Makes me content having been on the backend.
People fought to replace the tools of the era with this. It had some advantages over time - ES6, a good plugin ecosystem, react adoption - but quickly it just became "the standard" which everyone is afraid to question.
I used to maintain a build workflow library [1] a lifetime ago; while our frontend build needs have evolved way beyond it, I can't avoid the feeling that we overengineered a little too much.
wikipedia used to be under FDL and they lobbied FSF to allow an escape hatch to Commons for a few months, because FDL was so annoying.
reply