Spring-rs is a microservice framework in Rust inspired by Java's spring-boot(github.com)
github.com
Spring-rs is a microservice framework in Rust inspired by Java's spring-boot
https://github.com/spring-rs/spring-rs
88 comments
Nobody here was saying you should always write your own framework, which is what your engineers were trying to do. Vert.x is a a low-level framework when compared to Spring, so it doesn't provide much organization for your code. This is betrayed by the fact that there are higher-level frameworks written on top of Vert.x, like Quarkus.
What you are describing above is a skill issue. If the developers are bad, they'll be bad with any framework. As a proof, I can give you dozens of bloated, slow, buggy and hard to maintain Spring projects I've seen during my career. I can also list a bunch of successful projects we've built with Vert.x and a custom framework. At the same time, we also have a bunch of successful Spring projects. This has more to do with the skills of the team involved rather than the framework selection.
But when it comes to selecting your framework, there are good reasons we avoid Spring. Spring shines when it comes to having a bunch of built-in modules for everything: authentication, configuration, dependency injection, monitoring, various template engines and databases - whatever you want. The advantage is that you don't need to spend time investigating and arguing dependencies - they're all right there. It's also easy to structure your projects and to hire developers who claim to know Spring (whether they actually do understand how Spring works is another story).
But Spring has a lot of issues too:
- Performance: This is the main reason we avoid it for most projects. Spring is slow. This appears to be the main reason OP has created a Rust version of the Spring framework. Of course, Rust has less overhead than Java, but there are many Java frameworks that are faster than Spring. Spring is just proudly underoptimized. Almost anything else I could say about Spring or you could say about other frameworks may be subjective or anecdotal — but speed is easy to quantify. If you look at the TechEmpower benchmarks, there is an order of magnitude of difference between Spring and lightweight frameworks like Vert.x and Jooby and even some optimized heavyweight frameworks like Quarkus[1]. If you care about performance you just cannot use Spring.
- Inscrutable Magic: Spring has a lot of annotation-based magic. A lot of Spring enthusiasts like it, since it gets stuff done and reduces boilerplate. But it also makes your framework behavior hard to understand and scrutinize. If you want to know what an annotation does, you can't just click "go to definition" in your editor and look at its source code. You need to find out where all the possible annotation processors are and then read all the relevant code until you find how that particular annotation is processed into generated code or wrapper classes or whatever.
- Security: I beg to differ here. Spring Security can save you from the bugs that you would have if you wrote your own authentication code, but the code that Spring itself brings to the table does not have a very good track record. The sheer amount of CVEs found in Spring[2] is staggering. A lot of is due to popularity and exposure, but this is also due to Spring's desire to include everything under the sun and do as much as possible behind the scenes, with automagic. A great example of this approach is how Spring Actuator used to expose a lot of sensitive endpoints (including a full heapdump endpoint) by default, on a standard path. This needed you to add the actuator module, but a lot of servers included it because this is the standard way to enable health checks in Spring, and almost every cloud infrastructure nowadays requires health checks. The end result is that if you wanted your Spring Boot 1.5 web server to be secure, you'd had to explicitly disable these endpoints[3]. Even with modern Spring versions, the sensitive "/actuator/info" endpoint is still exposed by default.
[1] https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
[2] https://spring.io/security
[3] https://docs.stackhawk.com/vulnerabilities/40042/
What you are describing above is a skill issue. If the developers are bad, they'll be bad with any framework. As a proof, I can give you dozens of bloated, slow, buggy and hard to maintain Spring projects I've seen during my career. I can also list a bunch of successful projects we've built with Vert.x and a custom framework. At the same time, we also have a bunch of successful Spring projects. This has more to do with the skills of the team involved rather than the framework selection.
But when it comes to selecting your framework, there are good reasons we avoid Spring. Spring shines when it comes to having a bunch of built-in modules for everything: authentication, configuration, dependency injection, monitoring, various template engines and databases - whatever you want. The advantage is that you don't need to spend time investigating and arguing dependencies - they're all right there. It's also easy to structure your projects and to hire developers who claim to know Spring (whether they actually do understand how Spring works is another story).
But Spring has a lot of issues too:
- Performance: This is the main reason we avoid it for most projects. Spring is slow. This appears to be the main reason OP has created a Rust version of the Spring framework. Of course, Rust has less overhead than Java, but there are many Java frameworks that are faster than Spring. Spring is just proudly underoptimized. Almost anything else I could say about Spring or you could say about other frameworks may be subjective or anecdotal — but speed is easy to quantify. If you look at the TechEmpower benchmarks, there is an order of magnitude of difference between Spring and lightweight frameworks like Vert.x and Jooby and even some optimized heavyweight frameworks like Quarkus[1]. If you care about performance you just cannot use Spring.
- Inscrutable Magic: Spring has a lot of annotation-based magic. A lot of Spring enthusiasts like it, since it gets stuff done and reduces boilerplate. But it also makes your framework behavior hard to understand and scrutinize. If you want to know what an annotation does, you can't just click "go to definition" in your editor and look at its source code. You need to find out where all the possible annotation processors are and then read all the relevant code until you find how that particular annotation is processed into generated code or wrapper classes or whatever.
- Security: I beg to differ here. Spring Security can save you from the bugs that you would have if you wrote your own authentication code, but the code that Spring itself brings to the table does not have a very good track record. The sheer amount of CVEs found in Spring[2] is staggering. A lot of is due to popularity and exposure, but this is also due to Spring's desire to include everything under the sun and do as much as possible behind the scenes, with automagic. A great example of this approach is how Spring Actuator used to expose a lot of sensitive endpoints (including a full heapdump endpoint) by default, on a standard path. This needed you to add the actuator module, but a lot of servers included it because this is the standard way to enable health checks in Spring, and almost every cloud infrastructure nowadays requires health checks. The end result is that if you wanted your Spring Boot 1.5 web server to be secure, you'd had to explicitly disable these endpoints[3]. Even with modern Spring versions, the sensitive "/actuator/info" endpoint is still exposed by default.
[1] https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
[2] https://spring.io/security
[3] https://docs.stackhawk.com/vulnerabilities/40042/
I think you're leaving something out.
- the affinity for 'traditional' java guys to make code seem so complicated and be wrapped in so many layers.
the JVM is an excellent platform bar none. But if you work on a java codebase with the traditional guys - I feel sorry for you. there has to be so many "best practices" - Impl, Factory, Wrapper what what . what was supposed to be a simple endpoint - then a simple function for business logic is now wrapped in 5 or so classes.
then you add the magic of "Spring" and productivity & everything else slows down to molasses.
End of day if you're working on web services or internet stuff - you take in JSON, transform JSON, spit out JSON. That's been my experience. & that's not complicated to do. maybe other people can differ.
- the affinity for 'traditional' java guys to make code seem so complicated and be wrapped in so many layers.
the JVM is an excellent platform bar none. But if you work on a java codebase with the traditional guys - I feel sorry for you. there has to be so many "best practices" - Impl, Factory, Wrapper what what . what was supposed to be a simple endpoint - then a simple function for business logic is now wrapped in 5 or so classes.
then you add the magic of "Spring" and productivity & everything else slows down to molasses.
End of day if you're working on web services or internet stuff - you take in JSON, transform JSON, spit out JSON. That's been my experience. & that's not complicated to do. maybe other people can differ.
The performance argument I cannot subscribe to. We did extensive load testing in the past on different products, and the bottleneck in the end was always the DB (or more recently, getting screwed by OpenSSL v3). Sure Spring might not be the fastest in its class, but it's a cheap problem to solve, just fire up more or bigger VMs (as long as you've kept it stateless).
The security concerns about actuator I cannot subscribe to either. Why are your endpoints exposed to the outside by default? Why is the management port reachable from the outside? Why are devs not reading the docs and only enabling the endpoints they need?
The magic annotations part can definitely be a problem. Would recommend to stay away as much as possible and keep that simple. Only use it as a last resort, but boy can it be powerful. Need your own request scope that is bound to transactional commit/rollback? You can have that to for example only send out side effects when the transaction succeeds, or to build transparent caching solutions on request scope.
The security concerns about actuator I cannot subscribe to either. Why are your endpoints exposed to the outside by default? Why is the management port reachable from the outside? Why are devs not reading the docs and only enabling the endpoints they need?
The magic annotations part can definitely be a problem. Would recommend to stay away as much as possible and keep that simple. Only use it as a last resort, but boy can it be powerful. Need your own request scope that is bound to transactional commit/rollback? You can have that to for example only send out side effects when the transaction succeeds, or to build transparent caching solutions on request scope.
Spring’s security record prior to 6 was pretty interesting. They had a bunch of RCE causing vulns they wouldn’t even recognise as vulns (eg due to Java deserialisation issues), which wasn’t a great look for something in use in many large companies.
To be fair, Spring devs did say “don’t use it like that”, but devs of all skill levels use Spring, so that’s not great advice.
It is much better now, but of course the latest thing is that it’s now owned by Broadcom. So if you as a contractor are foisting Spring upon your clients, I hope you’re ready with a security/fixes strategy, because don’t expect Broadcom to support old versions of Spring forever. Or else you could just pay Broadcom $$$.
Good time to mention: users of open source Spring 5, it goes end of life this month. Hope you’re ready!
To be fair, Spring devs did say “don’t use it like that”, but devs of all skill levels use Spring, so that’s not great advice.
It is much better now, but of course the latest thing is that it’s now owned by Broadcom. So if you as a contractor are foisting Spring upon your clients, I hope you’re ready with a security/fixes strategy, because don’t expect Broadcom to support old versions of Spring forever. Or else you could just pay Broadcom $$$.
Good time to mention: users of open source Spring 5, it goes end of life this month. Hope you’re ready!
> Inscrutable Magic ... need to find out where all the possible annotation processors are
or you read the documentation.
or you read the documentation.
I don't think this is a good take.
Magic doesn't belong in software, and a well-designed library or framework doesn't need it to succinctly express the program logic in a way that isn't boilerplaty and bloated, not even in Java.
Magic doesn't belong in software, and a well-designed library or framework doesn't need it to succinctly express the program logic in a way that isn't boilerplaty and bloated, not even in Java.
I may be as old and cynical as House MD but if there is anything decades in the business taught me it's that customers and documentation (esp. code comments) always lie.
> You'll get it when you make it to true Senior level :)
This and the following lines have so many opinions presented as truisms, it’s difficult to take the poster seriously.
2-4 “senior” devs were spending time on tech-only features without delivering actual end-user / business features. Ookay. Seems like a failure of engineering management, but let’s press forward.
2-4 engineers replaced with 1 “true Senior” engineer, who rewrote the microservices nightmare into a monolith powered by Spring. And he had C Suite backing for this. All’s well now.
I mean, that’s a great result. But it feels like there’s also some great people/motivation backstory we’re not getting. Also, maybe lessons from a one-person monolith don’t apply everywhere, even if that monolith serves millions of users?
This and the following lines have so many opinions presented as truisms, it’s difficult to take the poster seriously.
2-4 “senior” devs were spending time on tech-only features without delivering actual end-user / business features. Ookay. Seems like a failure of engineering management, but let’s press forward.
2-4 engineers replaced with 1 “true Senior” engineer, who rewrote the microservices nightmare into a monolith powered by Spring. And he had C Suite backing for this. All’s well now.
I mean, that’s a great result. But it feels like there’s also some great people/motivation backstory we’re not getting. Also, maybe lessons from a one-person monolith don’t apply everywhere, even if that monolith serves millions of users?
You don't have to take me serious to derive value from the post. It's obvious anecdotal, just shares a story. I skipped some of the details to focus on the topic of Spring. But I think I can add some as you have rightly spotted they are missing:
The major problem was imho indeed engineering management of that specific team, which was also swapped out at the same time I was put on the team (which was before we got the buy in to rewrite it). There were actually at least two dev generations of the team building the software before ours. The first one caused the most damage by the demented infrastructure decisions, while the second iteration was not able to successfully challenge that, even though they had the right ideas already. New engineering management was awesome in that they supported devs with most of our radical ideas, but also pulled in resources from other departments to help deal with the largest pain points such as adding Spring Boot quite early in the mending journey, with the heavy lifting being done by an expert from another team temporarily joining us.
Forgive my judgy wordings in the direction of seniority...our org has (had?) an issue where complexity is rewarded over simplicity. Some senior people here all they could do is build something so clusterfucked noone can understand it. Funnily enough, this project was originally launched to replace a legacy system noone was able to (or unwilling to) maintain.
Forgive my judgy wordings in the direction of seniority...our org has (had?) an issue where complexity is rewarded over simplicity. Some senior people here all they could do is build something so clusterfucked noone can understand it. Funnily enough, this project was originally launched to replace a legacy system noone was able to (or unwilling to) maintain.
that team is probably telling a story how someone convinced management to ditch their best in class product which would conquer market share, with a lame cookie cutter version that didn't even validate jwt tokens or something at launch and now they're one of the bottom also-run in the market.
Hehe, the original pitch for this project contained lots of mentions of AI =)
Heh, my personal complaint about Spring comes from the other side of this. I came into a company where Spring Boot was already deeply entrenched, in a Senior DevOps/Sysadmin type of role. I spent a significant amount of time untangling all of the voodoo reflection magic that the teams who had created the services couldn't seem to debug on their own.
To be fair to Spring Boot, the developers in question didn't have any real operations mentality, which complicated things. A service would crash/500 and would have a 0-byte log file documenting everything that led to the crash. It was pretty surpassing though to discover that a lot of the visibility things I'd come to expect from the large variety of other non-Java frameworks didn't seem to be included by default (eg request logging/exception logging) and had to be turned on explicitly.
To be fair to Spring Boot, the developers in question didn't have any real operations mentality, which complicated things. A service would crash/500 and would have a 0-byte log file documenting everything that led to the crash. It was pretty surpassing though to discover that a lot of the visibility things I'd come to expect from the large variety of other non-Java frameworks didn't seem to be included by default (eg request logging/exception logging) and had to be turned on explicitly.
> Heh, my personal complaint about Spring comes from the other side of this.
What did your example have to do with Spring? It sounds like it'd have been the same if replaced with something else. It was the developers...
What did your example have to do with Spring? It sounds like it'd have been the same if replaced with something else. It was the developers...
Just like the original comment praising Spring, too. It's always the developers. Whether you use one framework or another or nothing.
Mostly that the whole annotation-based dependency injection part can be a mess to debug and that it seemed to (at the time, unsure about the present) have very odd defaults around logging.
The annotation-based DI seemed to do a really good job of turning what should have been a compile-time error into a runtime exception instead.
The annotation-based DI seemed to do a really good job of turning what should have been a compile-time error into a runtime exception instead.
> Mostly that the whole annotation-based dependency injection part
Right, but DI isn't Spring specific, so point still holds.
Within Java there are plenty of other annotation frameworks...
In other languages there are annotation usages and sometimes EVEN worse behavior exists...
And yet for reasons I'd like to know people aren't blaming those (at least not in the same capacity). That's the crux of the issue.
Right, but DI isn't Spring specific, so point still holds.
Within Java there are plenty of other annotation frameworks...
In other languages there are annotation usages and sometimes EVEN worse behavior exists...
And yet for reasons I'd like to know people aren't blaming those (at least not in the same capacity). That's the crux of the issue.
I'm explaining why I have had a bad experience with Spring. Spring is the only framework I've used that does weird stuff with annotation-based DI and can silently fail in production by default due to those annotations not being resolved correctly at runtime (heck, even if they can't be resolved at compile-time, please make them fail at startup instead of later!).
I've had other issues with other non-Java frameworks too, but I'm not giving a comprehensive write-up of the pros and cons of every web framework I've ever used here... just pointing out the pain points I had with Spring.
I also didn't mention LOMBOK because that doesn't seem like it's necessarily part of Spring by default but wow did that also prove to be another source of painful bugs.
I've had other issues with other non-Java frameworks too, but I'm not giving a comprehensive write-up of the pros and cons of every web framework I've ever used here... just pointing out the pain points I had with Spring.
I also didn't mention LOMBOK because that doesn't seem like it's necessarily part of Spring by default but wow did that also prove to be another source of painful bugs.
Spent a good day debugging, to learn that some (most?) annotations don’t work when the method is called from inside the same class (no proxy is setup).
Sounds like you ran into a bad "not invented here" culture, which can seriously slow down a product. Even worse, they are often so passionate about the tech that they can scare management into agreement with their priorities. Kudos to you for having the backbone to stand up and fix it!! Also: I am no fan of Spring ;) -- I just have ptsd from the early xml config days. If it were already in place though, I'd roll with it.
Great comment! I been developing web applications for almost 20 years. I've been working on several frameworks within PHP, Python, Ruby, Elixir and Java.
And after all these years I have settled on Spring Boot. Because it is mature, stable, fast and well documented. There are other frameworks that claims they are faster, but I've spent 10x more time just getting my stuff to work. I really do not have time for that as my focus is delivering business value. One Spring monolith scales really well on a Epyc server.
And after all these years I have settled on Spring Boot. Because it is mature, stable, fast and well documented. There are other frameworks that claims they are faster, but I've spent 10x more time just getting my stuff to work. I really do not have time for that as my focus is delivering business value. One Spring monolith scales really well on a Epyc server.
this new project, spring-rs is a wrapper for various other projects, gluing them together. (and thats totally fine!)
But naming it after the Spring Framework might be slightly exaggerating its ambition.
Even its homepage uses marketing thats not really on point for Spring i think?
i.e. Lightweight: The core code of spring-rs does not exceed 5,000 lines
I dont think anyone can honestly call Spring with its 8 million Lines of Java Code ... lightweight?
But naming it after the Spring Framework might be slightly exaggerating its ambition.
Even its homepage uses marketing thats not really on point for Spring i think?
i.e. Lightweight: The core code of spring-rs does not exceed 5,000 lines
I dont think anyone can honestly call Spring with its 8 million Lines of Java Code ... lightweight?
This is like the renaming to JavaScript to ride the coattails of Java.
I suppose Spring is still a popular, widely known framework. Other than desired popularity, there's no resemblance and is antithetical. Anything I see associating with Spring, I would assume to be outdated and inefficient.
I suppose Spring is still a popular, widely known framework. Other than desired popularity, there's no resemblance and is antithetical. Anything I see associating with Spring, I would assume to be outdated and inefficient.
> I suppose Spring is still a popular, widely known framework. Other than desired popularity, there's no resemblance and is antithetical. Anything I see associating with Spring, I would assume to be outdated and inefficient.
Spring is a battle tested, robust, optimized framework, that has scaled the largest brands in the world. It is literally what fortune five hundred companies trust their fortunes with. Spring is far from being outdated or inefficient, and will likely continue to dominate the market for years if not decades to come.
Spring is a battle tested, robust, optimized framework, that has scaled the largest brands in the world. It is literally what fortune five hundred companies trust their fortunes with. Spring is far from being outdated or inefficient, and will likely continue to dominate the market for years if not decades to come.
> Spring is a battle tested, robust, optimized framework, that has scaled the largest brands in the world. It is literally what fortune five hundred companies trust their fortunes with. Spring is far from being outdated or inefficient, and will likely continue to dominate the market for years if not decades to come.
I spit my coffee out on part of this one!
I’ve been a Spring developer for the better part of the last 10 years, and it definitely has warts, bugs, undocumented behavior, and plenty of source code diving for half-implemented features.
It does allow corporate middleware to easily be inserted, making management feel better and devs lives’ harder.
Don’t get me wrong, it has a placed in “corporate” development, but there are much more streamlined frameworks out there. In today’s day and age where SDKs are readily available and APIs are mostly sane, I think it has less of a place.
I spit my coffee out on part of this one!
I’ve been a Spring developer for the better part of the last 10 years, and it definitely has warts, bugs, undocumented behavior, and plenty of source code diving for half-implemented features.
It does allow corporate middleware to easily be inserted, making management feel better and devs lives’ harder.
Don’t get me wrong, it has a placed in “corporate” development, but there are much more streamlined frameworks out there. In today’s day and age where SDKs are readily available and APIs are mostly sane, I think it has less of a place.
> I spit my coffee out on part of this one!
I don’t know if the Spring team have dev evangelists, but I got a chuckle out of it too. Such a dev evangelist thing to say.
I do agree with your assessment, btw.
I don’t know if the Spring team have dev evangelists, but I got a chuckle out of it too. Such a dev evangelist thing to say.
I do agree with your assessment, btw.
> but there are much more streamlined frameworks out there
Which ones would you recommend instead of Spring?
Which ones would you recommend instead of Spring?
The answer is “it depends,” but personally I like ktor/micronaut better or golang’s stdlib. I do a lot of REST work right now, and I try to keep my services small.
I've also used Go without ORM-like libraries. For Java/Kotlin I've been trying out Javalin + JDBI which isn't too bad. You just have to roll your own things (or do the integration with what's available) sometimes. My apps start in 1/10s of seconds.
I wouldn't recommend it for a team that's used to copy/pasting from StackOverflow to get things done.
I wouldn't recommend it for a team that's used to copy/pasting from StackOverflow to get things done.
I refrained from replying as different folks have different experiences and views. I'll just leave this picture[0] of what I consider not optimized. Most of my beef is with JPA/JPQL/but-most-of-all-Hiberhate--it's a 2000's solution for a 1990's problem.
[0] https://ptrthomas.wordpress.com/2006/06/06/java-call-stack-f...
[0] https://ptrthomas.wordpress.com/2006/06/06/java-call-stack-f...
> It is literally what fortune five hundred companies trust their fortunes with
You’re overstating what “trust their fortunes with” means to a corporation. A framework is just technical detail. Often it’s tech debt if the framework is no longer fashionable. As has happened with J2EE.
Also: robust, heh. Spring has plenty of footguns and bugs. If you’ve deployed Spring anywhere, we should count the number of CVEs in production for your code.
And optimised? No. God no.
For devs new to the industry seeing this: a framework isn’t a runtime and isn’t a language. Learn how to write decent code without the training wheels of a framework. Then when it’s warranted, use a framework when it fits your needs. But don’t get into a situation where you’re totally dependent on the framework.
> likely dominate the market
They said that about J2EE as well. Didn’t work out so well. Again, knowing good programming technique > knowing a framework and better for career growth.
Specifically for Spring, its new owners Broadcom will probably look to making money off it. It’s already begun in a sense, a bunch of Fortune 500s are realising that Spring 5.x goes end of life in August 2024 (yes, this month) so it’s now time to pay Broadcom for sec fixes or upgrade to Spring 6.
It doesn’t mean Spring is dead but its proponents will have to work just a bit harder to justify the cost.
You’re overstating what “trust their fortunes with” means to a corporation. A framework is just technical detail. Often it’s tech debt if the framework is no longer fashionable. As has happened with J2EE.
Also: robust, heh. Spring has plenty of footguns and bugs. If you’ve deployed Spring anywhere, we should count the number of CVEs in production for your code.
And optimised? No. God no.
For devs new to the industry seeing this: a framework isn’t a runtime and isn’t a language. Learn how to write decent code without the training wheels of a framework. Then when it’s warranted, use a framework when it fits your needs. But don’t get into a situation where you’re totally dependent on the framework.
> likely dominate the market
They said that about J2EE as well. Didn’t work out so well. Again, knowing good programming technique > knowing a framework and better for career growth.
Specifically for Spring, its new owners Broadcom will probably look to making money off it. It’s already begun in a sense, a bunch of Fortune 500s are realising that Spring 5.x goes end of life in August 2024 (yes, this month) so it’s now time to pay Broadcom for sec fixes or upgrade to Spring 6.
It doesn’t mean Spring is dead but its proponents will have to work just a bit harder to justify the cost.
> For devs new to the industry seeing this: a framework isn’t a runtime and isn’t a language. Learn how to write decent code without the training wheels of a framework. Then when it’s warranted, use a framework when it fits your needs. But don’t get into a situation where you’re totally dependent on the framework.
For devs new to the industry seeing this: Master Spring, Java, and the JVM, then coast and have fun, while counting your ever growing bank account. Don’t get caught in the vicious cycle of endless hype, “up and coming” languages, microservices, or K8s. Fads, like skinny jeans and man buns, will eventually just disappear back into the void that they came from, but at the end of the day, you’ll have a great career, work life balance, and no problem finding a job. You’re welcome.
For devs new to the industry seeing this: Master Spring, Java, and the JVM, then coast and have fun, while counting your ever growing bank account. Don’t get caught in the vicious cycle of endless hype, “up and coming” languages, microservices, or K8s. Fads, like skinny jeans and man buns, will eventually just disappear back into the void that they came from, but at the end of the day, you’ll have a great career, work life balance, and no problem finding a job. You’re welcome.
Wait isn't Spring Framework all under "Apache License 2.0", so anyone could fork it and use it? Why wouldn't there be a group other than Broadcom contributing updates and providing support?
You can absolutely try. There are companies which provide support for out of support frameworks like Angular 1.
In reality there’s not enough Spring committers who don’t work for Broadcom for it to happen widely. (Also Broadcom has other options, eg follow Elastic and Cockroach Labs and change license.)
If you’re a senior dev, you need to be commercially astute — like finance folk can read balance sheets, you should be able to glean commercial implications from a project’s commit history.
PS. I’m a big fan of ensuring engineers get paid. If you actively choose to use Spring, buy a darn support contract and support its development. Given how many of you are on Spring 5.x or earlier even now, you’ll have to do so anyway if you want sec fixes. It’s a bit late to be looking for options in the short to medium term.
In reality there’s not enough Spring committers who don’t work for Broadcom for it to happen widely. (Also Broadcom has other options, eg follow Elastic and Cockroach Labs and change license.)
If you’re a senior dev, you need to be commercially astute — like finance folk can read balance sheets, you should be able to glean commercial implications from a project’s commit history.
PS. I’m a big fan of ensuring engineers get paid. If you actively choose to use Spring, buy a darn support contract and support its development. Given how many of you are on Spring 5.x or earlier even now, you’ll have to do so anyway if you want sec fixes. It’s a bit late to be looking for options in the short to medium term.
[deleted]
>Compared with SpringBoot in java, spring-rs has higher performance and lower memory usage, allowing you to completely get rid of the bloated JVM and travel light.
My HelloWorld program also has higher performance and lower memory usage than SpringBoot. Rust moment.
My HelloWorld program also has higher performance and lower memory usage than SpringBoot. Rust moment.
Spring framework can be seen as a wrapper for other projects and technologies creating a cohesive development platform.
No, Spring Framework is a singular repository which serves as a core for the larger Spring ecosystem. But even the other projects like Spring Boot, Spring Data, Spring Security are centrally developed / coordinated.
[deleted]
To be honest, 8 million of java code lines is equivalent to like 50 thousand lines of code in other languages
I don’t get all the spring hate here. Spring is a great framework, and the sheer developer mass means it’s easy to hire developers that can quickly be onboarded. It’s definitely opinionated, but a lot of the opinions are correct.
I think that rust is missing something like the above, and the attempt is appreciated by me.
I think that rust is missing something like the above, and the attempt is appreciated by me.
> I don’t get all the spring hate here.
It's popular to hate on Java. It's become a sad trend.
The funny thing is most people that hate it go on to re-invent or use something vastly similar eventually (even if they don't see it that way).
Spring does it for you right at the start. People hate to read the documentation or understand how things (including how Java) works and just blame it.
It's popular to hate on Java. It's become a sad trend.
The funny thing is most people that hate it go on to re-invent or use something vastly similar eventually (even if they don't see it that way).
Spring does it for you right at the start. People hate to read the documentation or understand how things (including how Java) works and just blame it.
It’s not about Java hate.
Historical context: Spring was a lightweight alternative to J2EE. It started and became popular in financial services because no one wanted the boilerplate hell that was J2EE.
By your logic we should all have stuck to J2EE as that was what the vendor (Sun) was pushing.
Today Spring has become the new J2EE. It’s no longer lightweight. It has a gravitational field at this point. (Except less boilerplate than J2EE because the Spring devs cared about dev ex more than J2EE’s creators did.)
Like J2EE back then, today, once you step out of the “framework == language” mentality, you’ll see there’s a bunch of ways to achieve what Spring does for you. Often with less code, less magic, and faster.
This is not to say Spring is always bad. Use it if it makes sense — for some small teams it may make a lot of sense. But don’t sleepwalk into it because “Java means Spring.” It doesn’t.
Historical context: Spring was a lightweight alternative to J2EE. It started and became popular in financial services because no one wanted the boilerplate hell that was J2EE.
By your logic we should all have stuck to J2EE as that was what the vendor (Sun) was pushing.
Today Spring has become the new J2EE. It’s no longer lightweight. It has a gravitational field at this point. (Except less boilerplate than J2EE because the Spring devs cared about dev ex more than J2EE’s creators did.)
Like J2EE back then, today, once you step out of the “framework == language” mentality, you’ll see there’s a bunch of ways to achieve what Spring does for you. Often with less code, less magic, and faster.
This is not to say Spring is always bad. Use it if it makes sense — for some small teams it may make a lot of sense. But don’t sleepwalk into it because “Java means Spring.” It doesn’t.
It's a 29 year old language. It has done an amazing job adapting over time and is a technical marvel (and I still think it is a better than average language overall) but there are tons of valid criticisms of it and I don't begrudge someone not loving the language.
The language is old, the JVM is not. As a human i am happy that my language is well understood, independent of how old i am. I can express myself, and thats what counts. From time to time we get new words. But i do not have to ditch the old stuff. Is it not astounding how old many of the programming languages have become?
They do a great job of keeping the language fresh, on many levels. Java streams, encryption, syntax updates. It doesn’t feel old to me.
Yeah. But people will be like
“Java sucks. Ruby/Python/Haskell is the shit”
“Java sucks. Ruby/Python/Haskell is the shit”
There literally like 1 straight up bigot-yish opinion but that too gives an explanation.
I will show you true spring hate. During my second summer in college I had a PM recommend me some stuff to try so I could maybe contribute free labour to their organisation. This very unenthusiastic person told me to first learn "spring", I said ofc I will learn some spring and get back to you in a 1-2 weeks.
Context, I had already written many small PoC apps in Rust using Rocket, Diesel and Postgres, I was naïve but not completely inexperienced in the Rest/we server space.
Every tutoria for spring that I'd find would first want you to setup the Spring IDE because it's very difficult to learn and work without. The IDE is super simple and should be a breeze to setup and start working. I had recently paused by distro hopping on PopOS! so I started so I followed the Spring IDE installation for Linux.
I spent 2 weeks trying to install Spring. I reinstalled by OS multiple times because I was very inexperienced in Linux and would be paranoid that I had broken something in Linux (which I frequently did before). 2 weeks of debugging the Spring the IDE installation ended with me finding out that the certificate for the java installation I had installed through the PM was invalid or expired, someone had pushed a broken package, which was preventing springs ide from verifying any of the sources it would need to download and install packages from. You needed to download the official tar from javas website and change the certificate from there. Everything worked and I had spring setup after 2 weeks of tinkering.
I gave up on learning spring after that, for atleast till my graduation I did not formally every work with Java because of the unhealthy reliance on editor integrations for newbies. Those 2 weeks had traumatized me, they were most probably my fault. I could had switched OS's been windows to make it easier, you could think of many solutions. But the fact that I was able to learn and work with pre-async rust did not give me much confidence in the Java ecosystem.
I am wiser now and understand the utility of Spring, but it's heavy reliance on IDE features I still do not appreciate.
I will show you true spring hate. During my second summer in college I had a PM recommend me some stuff to try so I could maybe contribute free labour to their organisation. This very unenthusiastic person told me to first learn "spring", I said ofc I will learn some spring and get back to you in a 1-2 weeks.
Context, I had already written many small PoC apps in Rust using Rocket, Diesel and Postgres, I was naïve but not completely inexperienced in the Rest/we server space.
Every tutoria for spring that I'd find would first want you to setup the Spring IDE because it's very difficult to learn and work without. The IDE is super simple and should be a breeze to setup and start working. I had recently paused by distro hopping on PopOS! so I started so I followed the Spring IDE installation for Linux.
I spent 2 weeks trying to install Spring. I reinstalled by OS multiple times because I was very inexperienced in Linux and would be paranoid that I had broken something in Linux (which I frequently did before). 2 weeks of debugging the Spring the IDE installation ended with me finding out that the certificate for the java installation I had installed through the PM was invalid or expired, someone had pushed a broken package, which was preventing springs ide from verifying any of the sources it would need to download and install packages from. You needed to download the official tar from javas website and change the certificate from there. Everything worked and I had spring setup after 2 weeks of tinkering.
I gave up on learning spring after that, for atleast till my graduation I did not formally every work with Java because of the unhealthy reliance on editor integrations for newbies. Those 2 weeks had traumatized me, they were most probably my fault. I could had switched OS's been windows to make it easier, you could think of many solutions. But the fact that I was able to learn and work with pre-async rust did not give me much confidence in the Java ecosystem.
I am wiser now and understand the utility of Spring, but it's heavy reliance on IDE features I still do not appreciate.
First, I never use Spring IDE (which is nothing but Eclipse + some plguins). I use IntelliJ ultimate version which supports Spring pretty well.
I wonder why you had to re-install the OS when you mess up the IDE, esp. in Linux. In Linux, Spring IDE, IntelliJ, jdk ... are zipped files. You download them, unzip them in your home directory. If you think everything is messed up and you want to restart from scratch, create a new account in you Linux machine and start again.
Second, you can write a Spring-based app without a Spring-support IDE (e.g. IntelliJ community edition doesn't support Spring, i.e. it doesn't understand any Spring feature but of course, it understands Java). Many places where I worked were too cheap to buy the InterlliJ licenses for us and we were still fine (although we weer not happy at all).
IntelliJ Ultimate is a steal. It is less that my spotify abonnement. It is time for them to increase prizes.
Don't write Rust like it's Java: https://news.ycombinator.com/item?id=41198358
Huh, the name collisions won't be confusing at all...
Here's hoping for a cease & desist of the use of the name, because I don't feel like having to filter through all the Rustian examples when I search for how to solve something in the actual Spring context.
Here's hoping for a cease & desist of the use of the name, because I don't feel like having to filter through all the Rustian examples when I search for how to solve something in the actual Spring context.
should've name it something like 'rusty-coil', and not name clash with spring!
For what it’s worth, I thought the same thing when Rails added a component called “Spring”. I thought it would lead to needless search conflicts since they’re both used for web development. But, it’s mostly been a non-issue.
Spring sucks. Decorator magic non-debuggable garbage that chokes under performance limits with inscrutable error message misattributing overflows with the location it overflowed at.
Wouldn’t touch this project with a ten foot pole despite it not matching spring in any meaningful sense.
Wouldn’t touch this project with a ten foot pole despite it not matching spring in any meaningful sense.
Because debugging Rust macros is soooo much better.
In my opinion this needs more examples. Currently I’m not sure why I would use this over Axum or ActixWeb.
Agreed. I’ve never used spring-boot, so telling me this is like spring-boot is less informative than the author might think it is.
Java world is huge, so for Java developers who want to try Rust it makes perfect sense. It may bring more users than targeting developers who already use Rust.
I always thought, if there is a contender for becoming Rust's Spring (in a good sense) it would be Pavex.
https://news.ycombinator.com/item?id=34195291
https://news.ycombinator.com/item?id=34195291
Okay, something interesting about this is that you don't need to mount routes but has the option to apply them as is. It may help cut down boilerplate.
(Not sure if the underlying Axum also has this feature)
(Not sure if the underlying Axum also has this feature)
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.
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.
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.
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.
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.
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.
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.
[deleted]
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 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)
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.
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.”
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 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.
That's why I left Java and joined other large orgs with hundreds of developers that build simple software.
I'm waiting for Rust to get a Dependency Injection framework, on par with CDI (I don't care much for Spring).
> spring-job(integrated with tokio-cron-scheduler)
Does this work well with cpu-bound tasks?
Does this work well with cpu-bound tasks?
[deleted]
Don't Java my Rust, please... Nor Go for that matter... ;) on a more serious note, we should try of different stuff and adopt what works, not sure Spring approach is worth pasting to Rust.
It’s going to be awesome to look for help about it on search engines, in case of issues
What is great about Rust and Go is that you don't need frameworks. Let's keep it that way.
I mean, they're both excellent languages, but people regularly use frameworks for both (eg Axum for Rust and Fiber for Go), and in Rust you get the excitement of choosing an async runtime. They both have important advantages but this isn't one of them.
On a different note though, when I was a Junior, building my first few projects, I didn't get it either. You'll get it when you make it to true Senior level :) Just last year I took over a project at work where 2-4 engineers (including "Senior"s, especially the one who came up with the infrastructure) were very busy reinventing their own framework/platform instead of building the actual product, for about 3 years. They had their own protocols and their own transaction management and two webservers (cause they were trying to use VertX websockets in addition to HTTP but due to a skill issue couldn't serve them from a single webserver) etc etc. What they did not have, was a working product. I got buy-in from management up to C level to rewrite that burning garbage dump. Now, about a year later, after management moved those people off and me in, the product is actually live with all the missing features, has about 50% less LoC than at its peak, and does no longer exist as a distributed stateful microservice agglomeration. Instead it's a Spring Boot monolith. Including Spring Security. It was the first time any of my software got a security bug found by external researchers and only because I did not add Spring Security immediately along Spring Boot because I thought we can go along with the homegrown auth code for a while longer.
Anyways, serious people who have built some serious (web) products will appreciate the battle proven tech that has integrations with just about any other relevant software on the planet and implements production ready patterns for you to immediately use.
If you don't, may I suggest you ask yourself: maybe you've just been building only toy projects, or solving too much leet code problems? Maybe you've only worked on projects meant for your resume or promotion dossier, rather than actually putting a product live to millions of users?
I applaud the Rust ecosystem taking one of the best pages from the Java ecosystem book, although the focus on "lightweight" does not make me optimistic that the author has truly understood what value, and how, Spring delivers.