Most active commenters
  • gf000(4)
  • whstl(3)
  • okeuro49(3)

←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 14 comments | 18 Feb 25 16:55 UTC | HN request time: 0.001s | source | bottom
Show context
time4tea ◴[19 Feb 25 07:02 UTC] No.43099396[source]▶
The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author is comparing apples with oranges, with a bit of misunderstanding that java/jvm means spring boot, and while that is true for a lot of people and certainly a lot of stuff on the internet implies that 'this is the way', it's not required. Startup times of ~100ms are absolutely standard for a big program, similarly unit tests taking 1ms. I prefer to write kotlin rather than java, as it's a nicer language ,IMHO, but still those bytecodes run on Jvm and same stuff applies.

Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably.

Just use new() it's pretty fast.

replies(12): >>43099426 #>>43099935 #>>43100071 #>>43100330 #>>43100562 #>>43101034 #>>43101071 #>>43101189 #>>43101914 #>>43102326 #>>43102666 #>>43143349 #
okeuro49 ◴[19 Feb 25 08:32 UTC] No.43099935[source]▶
> But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware...

No, people use it because we don't want to reinvent the wheel.

Spring is well documented and Spring Boot gives you a set of dependencies that all work together.

Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

replies(5): >>43100066 #>>43100145 #>>43100618 #>>43100650 #>>43112249 #
anthropodie ◴[19 Feb 25 08:53 UTC] No.43100066[source]▶
> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

It sounds good but in reality people end up spending time messing around with config files and annotations.

replies(3): >>43100632 #>>43103416 #>>43109133 #
1. gf000 ◴[19 Feb 25 10:31 UTC] No.43100632[source]▶
Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase.

In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.

replies(2): >>43100698 #>>43101582 #
2. whstl ◴[19 Feb 25 10:43 UTC] No.43100698[source]▶
> Like, what other option is there?

For this specific case there's plenty...

You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little.

You can use other frameworks that also have those features, in Java or in other languages.

You can use a paid authentication services.

You can use an open source authentication services.

replies(2): >>43100960 #>>43101574 #
3. gf000 ◴[19 Feb 25 11:29 UTC] No.43100960[source]▶
I was talking more abstractly, in that understanding a given feature to be able to configure it properly is not optional (besides asking someone else to handle some part of the complexity e.g. third party authentication services in this case).
replies(2): >>43111144 #>>43111190 #
4. okeuro49 ◴[19 Feb 25 12:54 UTC] No.43101574[source]▶
> You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little.

Then you have to work to make the libraries all work together. And deal with updates. Spring Boot allows to to update all libraries together, and know that they work together.

replies(1): >>43111105 #
5. lenkite ◴[19 Feb 25 12:55 UTC] No.43101582[source]▶
In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own.

In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc.

The extreme difference in basic developer culture causes visible differences in performance outcomes. Can't even blame the JVM - it is a superb beast that is overloaded by Java developers putting Mount Everest atop it.

replies(2): >>43101656 #>>43101688 #
6. okeuro49 ◴[19 Feb 25 13:03 UTC] No.43101656[source]▶
> In Java, people will pull in a 300MB+ mega-framework for a hello-world REST service. Oh and another 200MB for ORM. Another 250MB+ for nailpolish, etc.

I just now used https://start.spring.io/ to generate a project using Spring web, Spring security and Spring data JPA (Hibernate).

It generated a JAR that is 52MB.

replies(2): >>43101762 #>>43103143 #
7. gf000 ◴[19 Feb 25 13:05 UTC] No.43101688[source]▶
Most projects won't stay a hello-world REST service, there would be no point of doing them. They will grow and most likely make use of a bunch of CRUD features, on which we have a lots of experience in various languages and frameworks can solve a good chunk of any problem that might come up (AuthN/Z, session management, endpoints, safe parsing from and to json/url/forms, etc).

Spring (besides itself being modular, so you only "pay" for what you use) will solve all of that for me, so I only have to write the small amount of business-relevant code and be on my way. Later on, some other developer who knows spring can join the project and feel ready at home.

Compare it to a buggy, slow to develop, slow to onramp home-grown half-solution, and it's quite a clear tradeoff, unless there are very specific requirements that make the usage of frameworks a no-go.

8. lenkite ◴[19 Feb 25 13:12 UTC] No.43101762{3}[source]▶
Thanks - I haven't used the Spring Generator for several years now. However, I think one also needs to include the drivers, oauth stuff, template libraries, etc to get an accurate represention of "standard Java enterprise size". Gonna play with this offline and see how good it has got.
replies(2): >>43101807 #>>43102041 #
9. gf000 ◴[19 Feb 25 13:17 UTC] No.43101807{4}[source]▶
You might want to check the native spring native plugin as well, which can AOT compile the whole thing to a single binary (thanks to Graal).
10. ivan_gammel ◴[19 Feb 25 13:41 UTC] No.43102041{4}[source]▶
A real monolithic app dealing with videostreaming that I have been working recently, was based on Spring Boot and AWS SDK and it was a 82 Mb jar file. It had the drivers, oauth stuff, a couple of template engines for business reasons (Handlebars and Thymeleaf), database and queue drivers etc. It could be maintained and extended by a junior developer, because it had established design patterns and they only needed to follow some project conventions. We had multiple releases per week at engineering cost of less than 25k€ per year. I would not be able to build something like that with that budget on Go.
11. geodel ◴[19 Feb 25 15:32 UTC] No.43103143{3}[source]▶
Good. Just a little bigger than linux image size for containers and thats without including JVM.
12. whstl ◴[20 Feb 25 04:23 UTC] No.43111105{3}[source]▶
For this you setup tests and a CI, which is basic stuff that you can't really skip with Spring.

If you don't want or know how to do this, then there are all the other solutions.

Either way: authentication in a Spring app is the definition of "reinventing the wheel".

13. ◴[20 Feb 25 04:27 UTC] No.43111144{3}[source]▶
14. whstl ◴[20 Feb 25 04:34 UTC] No.43111190{3}[source]▶
But in none of those you "end up spending time messing around with config files and annotations", which was the problem mentioned by the grandparent.

So yes: there are other options.