Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

Post reply on HN
Print view View original

251–260 of 503 posts

Re: One year after switching from Java to Go

#251

Post by whstl »

okeuro49 wrote: post #203
time4tea wrote: post #156

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…

> 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 th…

I don't see how writing "one more OAuth client" or "one more login thing" using Spring Boot is not reinventing the wheel in itself.

If you really care about "not reinventing the wheel" there are ready-made paid solutions such as Auth0 and Cognito, plus self-hostable open-source options like Keycloak, Authelia, and Dex.

Also, Spring Boot itself uses third-party libraries for OAuth and Authentication, like Ninbus, which people can drop-in in their non-Spring Java apps.

Re: One year after switching from Java to Go

#252

Post by gf000 »

anthropodie wrote: post #212
okeuro49 wrote: post #203

Earlier quoted context omitted.

> 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 th…

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

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.

Re: One year after switching from Java to Go

#253

Post by DrScientist »

Never quite understood the attraction of dependency injection frameworks.

Sure pass in your dependencies as an interface via some sort of constructor, but why all the frameworks to do so?

Why all the complexity with hard to debug magic strings, annotations and finding out what's missing from the classpath at runtime?

Just seems as a very complicated way to avoid creating package c that brings together package a and dependency b in a simple class that creates b and passes it into a.

What am I missing?

Re: One year after switching from Java to Go

#254

Post by smrtinsert »

okeuro49 wrote: post #203
time4tea wrote: post #156

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…

> 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 th…

Don't know why this is down voted its absolutely true. When our tech leadership reviewed the numbers we changed auth design without touching the application code base really. Saved a ton of work considering we have many microservices.

Spring rocks.

Re: One year after switching from Java to Go

#255

Post by whstl »

gf000 wrote: post #252
anthropodie wrote: post #212

Earlier quoted context omitted.

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

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.

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

Re: One year after switching from Java to Go

#256

Post by gf000 »

RussianCow wrote: post #204
_w1tm wrote: post #191

Earlier quoted context omitted.

> Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work. > I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself. DI is the idea that you should create your dependencies outside of the module / class / function that uses it and pass it in. This makes it easy to swap imple…

If you're doing "dependency injection" by just passing arguments to functions/modules, you're not really doing dependency injection—you're doing "dependencies" without the "injection" part. I'm not saying that DI necessitates a ton of magic, but you need at least a small framework for specifying dependencies and injecting them into your modules dynamically.

No, you can pass (inject) the necessary dependencies to the constructor of an object at creation time, and then simply use that object instance everywhere. The only thing frameworks do is "solve" the dependency graph and instantiate stuff in the correct order.

This is also the most common/preferred way Spring et alia implements their "framework-aided" DI, so that you can write unit tests easily without bootstrapping a Spring context (and it is just well-designed vanilla Java code).

Re: One year after switching from Java to Go

#257

Post by gf000 »

roncesvalles wrote: post #185
someothherguyy wrote: post #182

Earlier quoted context omitted.

So, write python in go instead, gotcha.

The idiomatic way to write Go is as naively as possible after you fully understand how it works. Otherwise it'll just feel like Java with shitty ergonomics. If you're ever writing Go and wish you had real classes instead of this deconstructed "mess" with struct types, methods, and interfaces, you're writing Go totally wrong.

Sounds like a no true Scotsman fallacy.

Re: One year after switching from Java to Go

#258

Post by HexDecOctBin »

DrScientist wrote: post #253

Never quite understood the attraction of dependency injection frameworks. Sure pass in your dependencies as an interface via some sort of constructor, but why all the frameworks to do so? Why all the complexity with hard to debug magic strings, annotations and finding out what's missing from the classpath at runtime? Just seems as a very complicated way to avoid creating package c that brings together package a and d…

> What am I missing?

Job Security.

Re: One year after switching from Java to Go

#259

Post by fweimer »

tpm wrote: post #242
akoboldfrying wrote: post #195

Earlier quoted context omitted.

> Test using monkey-patching. TIL Go has monkey-patching. But since it has monkey-patching, how is it statically typed? Or does Go monkey-patching amount to creating an instance of a defined-on-the-fly subclass? The latter would be interesting, because Java lets you do this too -- conveniently "new up" an instance of a subclass that you define inline of a given class or interface (this used to be the easiest way to d…

Java doesn't really enable monkey-patching in the style of Javascript, Perl etc. AFAIK, or am I missing something? That you can create anonymous subclasses during runtime is different to e.g. editing methods of existing objects/classes during runtime.

JVMTI allows method patching: https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.h... The capabilities are somewhat limited, and an enhancement JEP was withdrawn: https://openjdk.org/jeps/159

On the other other, there is a movement to remove such late binding/rebinding features from the Java platform. However, I think JVMTI is expected to remain supported if the agents are loaded ahead of time. Only on-demand loading of agents will be removed from OpenJDK.

Re: One year after switching from Java to Go

#260

Post by gf000 »

roncesvalles wrote: post #190
stpedgwdgfhgdd wrote: post #187

Earlier quoted context omitted.

I don't get the part on package. Often you want to use structs. (Instance vs static) How would you construct an instance in a test that needs mock implementations?

Such an instance would just be a variable somewhere that would be initialized in some init() call when the program starts. Every user of that instance will use it directly (as opposed to storing a reference to it locally DI style).

So global mutable state? How wonderfully modern!
Post reply on HN