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.

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 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.