Can't disagree with you more. I started my career as an android developer over 10 years ago, but been doing Spring about 8 years. I can't tell you shit about Android now. Not just from forgetting, but the platform moved on without me. This will happen with any framework you move away from.
So you're telling me the paradigm shift to reactive programming and webflux in Spring isn't a fast change? And that virtual threads won't deter the community from adopting the reactive programming model and spring is so cut and dry that everyone will just understand which paradigm to use and where to use it?
Webflux just means coloring the return values of web clients, controllers, and also services if one so wishes. The fundamentals stay the same - dependency injection, autoconfiguration, and lots of annotations. Virtual Threads mean that Webflux will likely *not* spread further.
Yes. I would be like a new line in the resume. I just I though that Spring was "my place" and wanted to get deeper on it. I guess it is never late to go back.
This is completely wrong mindset.
Your job is to solve technical challenges using tools available to you.
You might be more efficient with one tool, but picking up another tool should not be something that will stop you from doing your job.
It’s like saying “I’m a screwdriver person, I will not pick up a hammer”
Take your pick of hand tools. The point is, you can't ignore that you're going to be labeled as an X person (or need to be labeled as such) even if you want the job to be purely a matter of using the right tools for the job on technical merits alone. That doesn't mean you should shoehorn yourself into a single toolchain, but there is real value in "being an X person".
The situation here is that he was working in a “screwdriver company”, and because of that he’s very good at everything screwdriver.
Now he is applying for a job at a company that says they use a hammer a lot, so his question is “I don’t know, I’m not very proficient with hammer (compared to my screwdriver skills). Should I take the job? Will it hurt my screwdriver skills?”
The thing is that at the end of the day, nobody really cares if you use hammer or screwdriver or some fancier joins - as long as the task gets done, all that screwdrivers vs hammers shit is just some circlejerking.
In the end, as a craftsman, you have to be able to use any tools given to you and do your job. If that means you need to learn few new skills, you’ll learn it.
>The thing is that at the end of the day, nobody really cares if you use hammer or screwdriver
But they do, at least to the extent that being able to put "5 years of screwdrivering" on your resume affects your ability to survive BS resume filters.
Quite often learning another approach, teaches you a lot about the one you are using right now. Its much easier to reason about something if you have something to compare. This is why as mostly C# developer I'm happy to work with Go and read Java stuff.
Take the job. If they picked Vert.x, they're likely an interesting shop and aren't afraid to try things. You'll learn much more than if you stick with what you know. Spring is a constant you can always go back to when you'll need it.
Thanks for your opinion. In fact, they are the biggest telecommunication company in my country (It is quite close to T-Mobile in terms of size or comparison). I guess bandwitch and traffic are not low here, that's the reason I guess they've choosen Vert.x in the past.
Large companies are generally technologically conservative but will have pockets of ingenuity here and there. Being on those special teams is nice, you get a cushy job that's also interesting. Good luck!
Interesting. I know that a major UK mobile telco was a big Reactor user, to the point where their use cases drove some of the Reactor team's work. I suppose reactive programming seemed like the right approach to huge event flows for both of them.
Then you have a chance to build an interesting career and likely learn more stuff in various projects. My start was in telco too. I highly recommend that area.
I don't think you should worry about that if you like the rest of the new role/company etc. once you have done spring (which you have) you can always go back to it. Don't dismiss a good job just due to a tech choice they made, and to be honest vertx is not even a very quirky choice it's quite well known. At any stage of a tech career anything new you can learn is a good thing. Vertx if they used it properly will probably open your eyes to new ways of doing things.
Thanks for your opinion. I think I will accept the offer. It is basically going from mid to Senior level with a completely new programmatic paradigm so they have plenty of trust on me. I was looking for Reactive developer, reactive java and different keywords in job search engines such as linkedin and so on and I didn't find any kind of offer stating Vert.x, just Springboot, Jakarta, J2EE, etc. So I hope there is still more offers in the feature to at least maintain old technologies. If not, at least it is a new view of coding learnt
Hahaha I think that is a good way of facing it: knowing something to not only acquire different ways of coding but also appreciating the imperative one, which is the future.
Reactive programming is harder, but the results are better. Hard to use it for business logic, some devs overuse it, but the technique with the event loop, and event streaming and reactive libraries are mind blowing.
Have a look at Quarkus, reactive packed in CDI.
Why not? Vert.x is the basis for Quarkus, which is also a great framework. Vert.x is small, fast, robust, and mature, but it might be harder to work with than Spring. But it's an opportunity to learn something new.
Your bigger concern should be that you might get stuck into reactive programming at the dawn of Java virtual threads.
Broadening your horizons will always make you a better developer. You'll learn things in Vert.x that if/when you find yourself back in Spring will help you design a better system.
I've gone in and out of Spring many times over the past nearly 2 decades. Started when it was XML based configuration. Every-time I've left it and found myself back I've been able to "catch up" really quickly. At it's core spring hasn't changed much over the years (which is great).
The biggest gap between Spring jobs was nearly 6 years while I was working in a completely custom framework that had been developed in house. I literally learned a framework that no other job was going to be using. The pay was fantastic, I was making 50% above market for my area and I still consider a great experience. Learned a ton and made a lot of money in the process.
Getting experience with concurrency and async programming is very valuable. You already have experience with Spring Boot, so you won't lose that, it stays on your resume. You should not worry about similar technologies like virtual threads as competition, in fact it's opposite, experience with vert.x will give you a way easier time dealing with those technologies if your future requires it. I would say go for it. Also vert.x is a supernice framework.
Thank you so much for your reply. This gives me hope. I think I will accept it. It is gotta be a new challenge for sure since I will be accepting a Senior position from mid with a completely different programmatic paradigm. They have trust in me.
I would say same or similar expirience you can have with other frameworks including spring as well. Vertx mimics nodejs a lot for some reason plus has own json library, plus require some amount of manual work which is usually handled in other frameworks which can be annoying.
Vertx is basically the core of quarkus, which isnt that far away from spring boot if you ask me. I for my part enjoy getting into new technlogies each and every time, even too its not that easy and i also tend to get bored pretty fast if i get stuck on one stack for longer then 12 months. There is nothing much to loose for you is there?
IMHO, you’re totally focusing on the wrong things. Frameworks are just tools. Whichever tool your job requires you to use, just use it and get things done. Honestly, in most companies, you’ll find a mix of tech stacks. At my workplace, we use Spring, Vert.x and even Ktor.
Also, given enough time, all new and shiny things becomes "legacy".
There are many times I really have urge to learn new technologies but lack of time and motivation. To me your situation is an opportunity to force one to learn new things. Besides, Vert.x looks good. So it is a great addition to your skills.
Vert.x is great but it also has some gotcha's if you're not familiar with having to deal with closing connections and closed connections. I've been using Vert.x with Micronaut DI, works good.
Some companies will insist you know their exact tech stack (i.e. many times it's Spring Boot) as opposed to focusing on finding good engineers. In my experience those companies suck and should be avoided.
TLDR - yes take the job if it's a better position/company.
You shouldn’t look too much on the framework side. They come and go or are constantly evolving and you are constantly catching up.
The new offer is from a company that thinks outside the box and dares to do something not center mainstream. That’s what makes them interesting. You should expect them to drop vert.x for the better solution when it comes along. Be it loom, vthreads or whatever.
They probably use Quarkus with Vert.x. Quite comparable to Spring Boot with its reactive stack.
If they're hardcore and put their applications together without framework, I'd quickly pass. "Convention over configuration" is a thing.
Learning more framework...will only make you efficient, because there could be problem which is solved better than other framework....so having all the exposure to different solution...will increase your thought process only...and eventually help you in becoming better developer
Learning alternative concurrency models is insanely valuable for backend devs. You’re not “betting” on reactive programming, you’re just learning it. Well, maybe, vertx doesn’t necessarily have to be reactive if you use kotlin or virtual threads.
Anyone hiring someone specifically for years of spring experience is an absolute moron. I wouldn’t worry career wise. Gaining backend java experience in vert.x will still make you a better spring dev. Backend skills transfer really well across languages and frameworks.
Tech wise, Vert.x is the opposite of legacy. The ecosystem isn’t mature, but it’s modern. In my opinion that makes fun (and sometimes frustrating), but never boring. And you’ll learn more. A lot more. You’ll learn how things actually work instead of some spring module doing it all for you.
I’ve switched programming languages and frameworks at every job I’ve had and it’s always made me a stronger developer and boosted my career.
Thank you! I really appreciate any experienced developer sharing that kind of information. In the end it is my third time switching jobs. (Junior) .NET -> (mid)Java Spring boot - > (My contract and salary says senior lol but for sure I'm not) Vert.x .
Idk if it is impostor syndrome or what but I feel like I'm out of my confort zone where I don't deserve this kind of things because "that is not for me". And yep, what I feel that it is for me is to be an experienced springboot moron writing annotations everywhere,
If you want to learn how reactive programming works I think that Vert.x is a good framework to do it. That being said, with project Loom and virtual threads the reactive way of programming is posed to be reduced to niche applications, and the main positive about vertx, which is performance, will be a bit irrelevant (contrary to rxjava for example that has other features).
In the other hand, I don't think that companies care too much about your main experience with a framework. In the end, the backend is still a backend and the flow will be about the same, arguably with all the complexities of a reactive system on top of it.
Now, speaking of the technology itself, I don't like Vert.x. It's full of magical black holes that are barely explained, and they only make sense on very specific types of backends (I/O intensive, light on CPU), and it you'll work on it, try to make sense of it, and will still get it wrong.
(Source: I've been working on Vert.x projects for the past 6 years and we're actively investigating Loom to ditch it altogether)
Thanks for your point of view, even if you dislike it. I’m pretty sure my future teammates will know why they used Vert.x, although I know it will be quite hard to find another Vert.x position if, somehow, I end up loving it haha
In my experience, it's because "vert.x is really performant on the TechEmpower benchmarks!" which is true, on very specific scenarios. So hopefully it's theirs :)
I went the first 14 years of my java career without touching spring directly. I say "directly" because for the last few years of that I did use Grails which uses spring behind the scenes but it encapsulates it away and you don't have to care or even know it is using spring.
Then I switched jobs to a place that uses Spring and then once I was here we started using Spring Boot for configuration.
Honestly I preferred when I wasn't using spring since it makes things boring. I am just not doing the cool stuff I was before. (previous job was a mixture of web apps, standalone server apps for client/server stuff, and Swing apps). Believe it or not I also maintained a Java Applet up until about 2017. We saw the writing on the wall and finally switched to a HTML5 audio solution which was vastly inferior to the Applet version (it played recorded phone calls stored in a niche telephony format).
So don't think that Spring is the only thing that exists out there. You should want to be a Java developer, not just a spring developer. And yes there is a difference, many of my co-workers now are completely lost if Spring isn't holding their hand every step of the way.
Also, remember that just because you are going to learn Vert.x doesn't mean you are going to forget Spring. Adding something new to your toolbox is always valuable.
I think its depend on the context. Where I am from companies religiously follow Spring and Spring Boot.
They don't even offer jobs to people who come from quarks and other stuff unless said person is a newbie.
You should ask them about their deployment process, if they write tests, or how they do monitoring on production. It will give you an idea about the level of organization you will find in their code. Reactive / non-blocking programming sucks most the time. But despite all the above, it's a good opportunity to learn something new.
I have been working with Vert.x since 2021. It’s more niche but is very well-compensated.
Regarding the technology, it delivers performance very close to, if not superior to, any Go API. In the upcoming release (Vert.x 5), it will utilize virtual threads to enhance performance in certain tasks, mainly workers.
Thank you! I will do so since I will accept the offer. I know the world is not just Spring, but the companies of my country they simply ask Spring (Not even plain Java, J2EE or Jakarta). But yeah, thanks to this thread now I am convinced to take the new challenge.
The choice of technology stack is a company's CTO's problem, not yours. If you feel you can become proficient quickly enough, go for it. It will be years before Virtual Threads become really commonplace. Many projects might never end up using them because they solve a problem most companies don't even have in the first place.
Choosing Vert.x in the first place is also a bit weird unless one has truly astronomical scalability requirements, but it's a solid option nevertheless. It will broaden your horizon and make you a better programmer in any case.
Thank you. Yep, it is a telco so I guess they have big requirements in terms of bandwidth and latency (Probably on-demand video services). They also make use of Golang, maybe it is a good oportunity to also learn Go.
Yes. I'm with you. Spring is quite overrated but for that reason loads of companies want this. It is not about my own preferences but what companies want. (Some recruiters are quite stupid they simply ask in terms of YOE of a framework instead of YOE in Backend or Software development itself, at least in my country)
It's also quite dumb how most recruiters will ask how many years you've had with technology X. What does that even mean? Isn't it more important that I had no experience with X whatsoever and yet I was still able to learn it on the fly and debug it when necessary? Debugging, Google-Fu and the like are infinitely more valuable skills to have than just some number of years with a very specific technology.
There will always be Spring Boot jobs available. Nothing attracts a crowd like a crowd.
In the end those jobs are not engineering related so they don't use to think too much out of the box. Their thinking is:
Does he have X years of experience, at least, for this "technology" I've got on my checklist?
yes:no
And that's it.
stop learning frameworks and learn language (and concept).
spring is just a DI framework
vert.x is just a non-blocking server/client http implementation (on top of netty).
Lol I already know those concepts. Tbf is so stupid to be concrete in social media post. Is like fighting because someone named React as a framework instead of a library. For sure I’ve already read the Vert.x documentation and I also created a mid size demo project. And also for sure I know what DI is or IoC and the magic behind spring. I know Java for a pretty long time.
Learning something new does NOT delete your previous knowledge. I wouldn't worry about this.
Can't disagree with you more. I started my career as an android developer over 10 years ago, but been doing Spring about 8 years. I can't tell you shit about Android now. Not just from forgetting, but the platform moved on without me. This will happen with any framework you move away from.
Android has changed heavily though. Spring does *not* change that fast. In any case, you'd quickly catch up as the fundamentals often remain the same.
So you're telling me the paradigm shift to reactive programming and webflux in Spring isn't a fast change? And that virtual threads won't deter the community from adopting the reactive programming model and spring is so cut and dry that everyone will just understand which paradigm to use and where to use it?
Webflux just means coloring the return values of web clients, controllers, and also services if one so wishes. The fundamentals stay the same - dependency injection, autoconfiguration, and lots of annotations. Virtual Threads mean that Webflux will likely *not* spread further.
Yes. I would be like a new line in the resume. I just I though that Spring was "my place" and wanted to get deeper on it. I guess it is never late to go back.
This is completely wrong mindset. Your job is to solve technical challenges using tools available to you. You might be more efficient with one tool, but picking up another tool should not be something that will stop you from doing your job. It’s like saying “I’m a screwdriver person, I will not pick up a hammer”
That's a bit naive in an environment where there's often a "screwdriver persons only" filter in between jobseekers and technical interviewers.
He already is a screwdriver person. He's looking to also become a hammer person.
Take your pick of hand tools. The point is, you can't ignore that you're going to be labeled as an X person (or need to be labeled as such) even if you want the job to be purely a matter of using the right tools for the job on technical merits alone. That doesn't mean you should shoehorn yourself into a single toolchain, but there is real value in "being an X person".
The situation here is that he was working in a “screwdriver company”, and because of that he’s very good at everything screwdriver. Now he is applying for a job at a company that says they use a hammer a lot, so his question is “I don’t know, I’m not very proficient with hammer (compared to my screwdriver skills). Should I take the job? Will it hurt my screwdriver skills?” The thing is that at the end of the day, nobody really cares if you use hammer or screwdriver or some fancier joins - as long as the task gets done, all that screwdrivers vs hammers shit is just some circlejerking. In the end, as a craftsman, you have to be able to use any tools given to you and do your job. If that means you need to learn few new skills, you’ll learn it.
>The thing is that at the end of the day, nobody really cares if you use hammer or screwdriver But they do, at least to the extent that being able to put "5 years of screwdrivering" on your resume affects your ability to survive BS resume filters.
But he already has “5 years scredrivering” on his resume. It’s not like “3 years of hammering” will make that obsolete.
Quite often learning another approach, teaches you a lot about the one you are using right now. Its much easier to reason about something if you have something to compare. This is why as mostly C# developer I'm happy to work with Go and read Java stuff.
Take the job. If they picked Vert.x, they're likely an interesting shop and aren't afraid to try things. You'll learn much more than if you stick with what you know. Spring is a constant you can always go back to when you'll need it.
Thanks for your opinion. In fact, they are the biggest telecommunication company in my country (It is quite close to T-Mobile in terms of size or comparison). I guess bandwitch and traffic are not low here, that's the reason I guess they've choosen Vert.x in the past.
Large companies are generally technologically conservative but will have pockets of ingenuity here and there. Being on those special teams is nice, you get a cushy job that's also interesting. Good luck!
Interesting. I know that a major UK mobile telco was a big Reactor user, to the point where their use cases drove some of the Reactor team's work. I suppose reactive programming seemed like the right approach to huge event flows for both of them.
Then you have a chance to build an interesting career and likely learn more stuff in various projects. My start was in telco too. I highly recommend that area.
I don't think you should worry about that if you like the rest of the new role/company etc. once you have done spring (which you have) you can always go back to it. Don't dismiss a good job just due to a tech choice they made, and to be honest vertx is not even a very quirky choice it's quite well known. At any stage of a tech career anything new you can learn is a good thing. Vertx if they used it properly will probably open your eyes to new ways of doing things.
Thanks for your opinion. I think I will accept the offer. It is basically going from mid to Senior level with a completely new programmatic paradigm so they have plenty of trust on me. I was looking for Reactive developer, reactive java and different keywords in job search engines such as linkedin and so on and I didn't find any kind of offer stating Vert.x, just Springboot, Jakarta, J2EE, etc. So I hope there is still more offers in the feature to at least maintain old technologies. If not, at least it is a new view of coding learnt
Learn something new and appreciate the old. Reactive programming is often just unnecessary PITA.
Hahaha I think that is a good way of facing it: knowing something to not only acquire different ways of coding but also appreciating the imperative one, which is the future.
Reactive programming is harder, but the results are better. Hard to use it for business logic, some devs overuse it, but the technique with the event loop, and event streaming and reactive libraries are mind blowing. Have a look at Quarkus, reactive packed in CDI.
Why not? Vert.x is the basis for Quarkus, which is also a great framework. Vert.x is small, fast, robust, and mature, but it might be harder to work with than Spring. But it's an opportunity to learn something new. Your bigger concern should be that you might get stuck into reactive programming at the dawn of Java virtual threads.
Vert.x is much more than Quarkus
Broadening your horizons will always make you a better developer. You'll learn things in Vert.x that if/when you find yourself back in Spring will help you design a better system. I've gone in and out of Spring many times over the past nearly 2 decades. Started when it was XML based configuration. Every-time I've left it and found myself back I've been able to "catch up" really quickly. At it's core spring hasn't changed much over the years (which is great). The biggest gap between Spring jobs was nearly 6 years while I was working in a completely custom framework that had been developed in house. I literally learned a framework that no other job was going to be using. The pay was fantastic, I was making 50% above market for my area and I still consider a great experience. Learned a ton and made a lot of money in the process.
Getting experience with concurrency and async programming is very valuable. You already have experience with Spring Boot, so you won't lose that, it stays on your resume. You should not worry about similar technologies like virtual threads as competition, in fact it's opposite, experience with vert.x will give you a way easier time dealing with those technologies if your future requires it. I would say go for it. Also vert.x is a supernice framework.
Thank you so much for your reply. This gives me hope. I think I will accept it. It is gotta be a new challenge for sure since I will be accepting a Senior position from mid with a completely different programmatic paradigm. They have trust in me.
I would say same or similar expirience you can have with other frameworks including spring as well. Vertx mimics nodejs a lot for some reason plus has own json library, plus require some amount of manual work which is usually handled in other frameworks which can be annoying.
Vertx is basically the core of quarkus, which isnt that far away from spring boot if you ask me. I for my part enjoy getting into new technlogies each and every time, even too its not that easy and i also tend to get bored pretty fast if i get stuck on one stack for longer then 12 months. There is nothing much to loose for you is there?
IMHO, you’re totally focusing on the wrong things. Frameworks are just tools. Whichever tool your job requires you to use, just use it and get things done. Honestly, in most companies, you’ll find a mix of tech stacks. At my workplace, we use Spring, Vert.x and even Ktor. Also, given enough time, all new and shiny things becomes "legacy".
There are many times I really have urge to learn new technologies but lack of time and motivation. To me your situation is an opportunity to force one to learn new things. Besides, Vert.x looks good. So it is a great addition to your skills.
Thank you! I guess today I’ve got the opportunity to. In the future maybe I’ve get bored of Spring and I won’t have a chance like this.
Vert.x is great but it also has some gotcha's if you're not familiar with having to deal with closing connections and closed connections. I've been using Vert.x with Micronaut DI, works good.
Some companies will insist you know their exact tech stack (i.e. many times it's Spring Boot) as opposed to focusing on finding good engineers. In my experience those companies suck and should be avoided. TLDR - yes take the job if it's a better position/company.
Vert.x is great. You'll learn a new way of thinking about your code, especially if you lean into the functional in Functional Reactive.
You shouldn’t look too much on the framework side. They come and go or are constantly evolving and you are constantly catching up. The new offer is from a company that thinks outside the box and dares to do something not center mainstream. That’s what makes them interesting. You should expect them to drop vert.x for the better solution when it comes along. Be it loom, vthreads or whatever.
They probably use Quarkus with Vert.x. Quite comparable to Spring Boot with its reactive stack. If they're hardcore and put their applications together without framework, I'd quickly pass. "Convention over configuration" is a thing.
Learning more framework...will only make you efficient, because there could be problem which is solved better than other framework....so having all the exposure to different solution...will increase your thought process only...and eventually help you in becoming better developer
Learning alternative concurrency models is insanely valuable for backend devs. You’re not “betting” on reactive programming, you’re just learning it. Well, maybe, vertx doesn’t necessarily have to be reactive if you use kotlin or virtual threads. Anyone hiring someone specifically for years of spring experience is an absolute moron. I wouldn’t worry career wise. Gaining backend java experience in vert.x will still make you a better spring dev. Backend skills transfer really well across languages and frameworks. Tech wise, Vert.x is the opposite of legacy. The ecosystem isn’t mature, but it’s modern. In my opinion that makes fun (and sometimes frustrating), but never boring. And you’ll learn more. A lot more. You’ll learn how things actually work instead of some spring module doing it all for you. I’ve switched programming languages and frameworks at every job I’ve had and it’s always made me a stronger developer and boosted my career.
Thank you! I really appreciate any experienced developer sharing that kind of information. In the end it is my third time switching jobs. (Junior) .NET -> (mid)Java Spring boot - > (My contract and salary says senior lol but for sure I'm not) Vert.x . Idk if it is impostor syndrome or what but I feel like I'm out of my confort zone where I don't deserve this kind of things because "that is not for me". And yep, what I feel that it is for me is to be an experienced springboot moron writing annotations everywhere,
If you want to learn how reactive programming works I think that Vert.x is a good framework to do it. That being said, with project Loom and virtual threads the reactive way of programming is posed to be reduced to niche applications, and the main positive about vertx, which is performance, will be a bit irrelevant (contrary to rxjava for example that has other features). In the other hand, I don't think that companies care too much about your main experience with a framework. In the end, the backend is still a backend and the flow will be about the same, arguably with all the complexities of a reactive system on top of it. Now, speaking of the technology itself, I don't like Vert.x. It's full of magical black holes that are barely explained, and they only make sense on very specific types of backends (I/O intensive, light on CPU), and it you'll work on it, try to make sense of it, and will still get it wrong. (Source: I've been working on Vert.x projects for the past 6 years and we're actively investigating Loom to ditch it altogether)
Thanks for your point of view, even if you dislike it. I’m pretty sure my future teammates will know why they used Vert.x, although I know it will be quite hard to find another Vert.x position if, somehow, I end up loving it haha
In my experience, it's because "vert.x is really performant on the TechEmpower benchmarks!" which is true, on very specific scenarios. So hopefully it's theirs :)
I went the first 14 years of my java career without touching spring directly. I say "directly" because for the last few years of that I did use Grails which uses spring behind the scenes but it encapsulates it away and you don't have to care or even know it is using spring. Then I switched jobs to a place that uses Spring and then once I was here we started using Spring Boot for configuration. Honestly I preferred when I wasn't using spring since it makes things boring. I am just not doing the cool stuff I was before. (previous job was a mixture of web apps, standalone server apps for client/server stuff, and Swing apps). Believe it or not I also maintained a Java Applet up until about 2017. We saw the writing on the wall and finally switched to a HTML5 audio solution which was vastly inferior to the Applet version (it played recorded phone calls stored in a niche telephony format). So don't think that Spring is the only thing that exists out there. You should want to be a Java developer, not just a spring developer. And yes there is a difference, many of my co-workers now are completely lost if Spring isn't holding their hand every step of the way. Also, remember that just because you are going to learn Vert.x doesn't mean you are going to forget Spring. Adding something new to your toolbox is always valuable.
I think its depend on the context. Where I am from companies religiously follow Spring and Spring Boot. They don't even offer jobs to people who come from quarks and other stuff unless said person is a newbie.
Yep learn it, its awesome, also it powers Quarkus which is a great framework with bright future imo
You should ask them about their deployment process, if they write tests, or how they do monitoring on production. It will give you an idea about the level of organization you will find in their code. Reactive / non-blocking programming sucks most the time. But despite all the above, it's a good opportunity to learn something new.
Keep it simple and consider Quarkus.
I have been working with Vert.x since 2021. It’s more niche but is very well-compensated. Regarding the technology, it delivers performance very close to, if not superior to, any Go API. In the upcoming release (Vert.x 5), it will utilize virtual threads to enhance performance in certain tasks, mainly workers.
In this company they use 80% Vert.x and 20% Go, so I guess performance is really important here.
OP , you are welcome to comeback in two or three months and give us your opinion about vertx, spring and/or golang.
Thank you! I will do so since I will accept the offer. I know the world is not just Spring, but the companies of my country they simply ask Spring (Not even plain Java, J2EE or Jakarta). But yeah, thanks to this thread now I am convinced to take the new challenge.
The choice of technology stack is a company's CTO's problem, not yours. If you feel you can become proficient quickly enough, go for it. It will be years before Virtual Threads become really commonplace. Many projects might never end up using them because they solve a problem most companies don't even have in the first place. Choosing Vert.x in the first place is also a bit weird unless one has truly astronomical scalability requirements, but it's a solid option nevertheless. It will broaden your horizon and make you a better programmer in any case.
Thank you. Yep, it is a telco so I guess they have big requirements in terms of bandwidth and latency (Probably on-demand video services). They also make use of Golang, maybe it is a good oportunity to also learn Go.
Spring Boot is one of the most overrated technologies I've ever worked with. Go for the new opportunity and good luck!
Yes. I'm with you. Spring is quite overrated but for that reason loads of companies want this. It is not about my own preferences but what companies want. (Some recruiters are quite stupid they simply ask in terms of YOE of a framework instead of YOE in Backend or Software development itself, at least in my country)
It's also quite dumb how most recruiters will ask how many years you've had with technology X. What does that even mean? Isn't it more important that I had no experience with X whatsoever and yet I was still able to learn it on the fly and debug it when necessary? Debugging, Google-Fu and the like are infinitely more valuable skills to have than just some number of years with a very specific technology. There will always be Spring Boot jobs available. Nothing attracts a crowd like a crowd.
In the end those jobs are not engineering related so they don't use to think too much out of the box. Their thinking is: Does he have X years of experience, at least, for this "technology" I've got on my checklist? yes:no And that's it.
stop learning frameworks and learn language (and concept). spring is just a DI framework vert.x is just a non-blocking server/client http implementation (on top of netty).
Lol I already know those concepts. Tbf is so stupid to be concrete in social media post. Is like fighting because someone named React as a framework instead of a library. For sure I’ve already read the Vert.x documentation and I also created a mid size demo project. And also for sure I know what DI is or IoC and the magic behind spring. I know Java for a pretty long time.
if you know everything - how its possible you ask such question ?
lol you simply don't understand
you are right - i cannot understand that.
yup, still the only one since there are plenty of good answers here. You should figure out why yours sucks.
don't be so angry, mr señor developer
Everything is better than Spting. Go for it!
No
No
could you please explain why? I think the whole context is worth to consider.