Spring-rs is a microservice framework in Rust inspired by Java's spring-boot

Java and Spring = an effort multiplier. It makes you spend more effort to obtain the same you would with other tech stacks.

Massive amounts of boilerplate and slow build times.

There are better ideas out there.

Hmm actually it's very intuitive with latest versions. Maybe you're stuck on the old ones where they used to use XML still lol

Spring is for when doing projects with teams of several digits team size, with offshoring and several consulting agencies.

Don't use it when WordPress does the job.

Spring Boot is indeed quite usable! I'd compare it to something like modern ASP.NET, good runtime performance, okay ecosystem, good tooling, okay languages.

The old Spring, not so much - I've never had a bare Spring project that was pleasant to work with, especially when you don't have embedded Tomcat and the application server is configured separately from the deployable .war or whatever, what a mess. Thankfully, you can put those legacy projects into containers and make things slightly more palatable.

That said, even Spring Boot can feel a bit much sometimes, something like Dropwizard is still very idiomatic as far as the Java ecosystem is concerned and is both stable and usable in those cases: https://www.dropwizard.io/en/stable/ (not as fancy as Vert.X or Quarkus or whatever, but it's been around for a while and is decently documented)

ASP.NET Core + ecosystem of packages for it are likely more comparable to Active-J and Vert.X in terms of focus on reducing boilerplate and offering good performance. There are more similarities in the API esp. with minimal API within the former. It is a much more focused package and Spring Boot performance really isn't up to par vs all these.

Spring is for large scale industrial systems that run critical business applications. Its for hundreds of developers building complicated software

> developers building complicated software

That's why I left Java and joined other large orgs with hundreds of developers that build simple software.

Why even use spring when you have spring boot which lets you get up and running with an orm and automatic migrations under 100 loc?

I guess I am an old dog that never bothered with Spring Boot, so hard to answer.

Yeah, I’ve done Spring stuff for the last 16 years, going from XML config (which, frankly, was nice in that there was a central place to see the structure of the app) to the more modern Java/annotation/magic-based config. I find it very intuitive and straightforward to set up, Spring Data is damn near magical and at one point, the app that I joked about (three lines of Java, 20 lines of annotations) became reality for a program that was populating RabbitMQ from change data written to a DB2 table.

Maybe it’s because my programming days date back to the era of 7-bit ASCII and every language implementation was a little different from the others in what aspects and extensions of the language it provided, but I find Java/Spring a pretty comfortable place to work (which is not to say that I eschew other languages). In general, I find that most of the time when developers express hate for a language or platform it really boils down to: “this isn’t what I’m used to and I don‘t want to change.”

> Spring is for when doing projects with teams of several digits team size, with offshoring and several consulting agencies.

It’s a better fit for smaller teams, especially with temp staff joining and leaving frequently, so the fact that you can hire Spring skills on the street becomes helpful.

“Several digit team sizes” have different needs, but larger teams often are polyglot + microservices based, and Spring adds less value there.

I still remember when all those teams were deploying EARs, most of the shops I work for have a policy of allowed languages.

So even with microservices, most likely, they will be some Java framework.

The enterprise is more polyglot now, at this point insistence on “one language” is a sign of immaturity (not gonna mince words).

Also, enterprises were never “single language” — many have blends of COBOL/RPG among other things. Today they have Python in production already. Because data science and data ops (Scala makes an appearance here as well, in some places). Node is extremely likely among the front-end focused “digital” teams (insert analog jokes here). Mobile has meant teams have had to shore up on Kotlin and ObjC/Swift talent too, and if you’re gatekeeping “this language goes here but not there” you’re introducing fault lines in your teams and across your codebase. The best teams cross pollinate.

I’ll be blunt (and this is a F50 enterprise perspective, not a startup perspective): polyglot is real and teams that want to operate in the 2030s will have to deal with it. Even Oracle knows this — hence Graal.

I’ll also say: senior devs and architects need to take a steer from the actual current JVM and JDK designers over 2005-era practices. I have nothing but respect for the JVM and JDK teams who’re doing their best to keep Java relevant in spite of some very old-style thinking among Java devs.

More polyglot, yes, but that N has an upper bound, usually not bigger than 3 or 5.

From a similar Fortune space, offically Java, C#, JavaScript/Typescript, eventually C or C++ for native libraries, anything else is bound by specific customer requirements, or Partner products SDKs that require exceptions to the golden rule, like Python for ML stuff, C++ for CUDA, Go for DevOps, and so on.