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

481–490 of 503 posts

Re: One year after switching from Java to Go

#481

Post by lamp_book »

hedora wrote: post #114
BytesAndGears wrote: post #51

Earlier quoted context omitted.

Maybe go just isn’t for you? It really doesn’t need every feature of other languages. The error handling is ideal for me, better than any other language. You are always explicit, with every function call, about “what could happen if this fails?” Maybe passing it up the stack is the best way to handle it, but also maybe it’s better to handle it somewhere in the middle. The thing that always happens with exceptions in…

Exceptions are a terrible idea. However, I strongly prefer rust error handling to Go. go: (res, err) := foo() if err != nil return err (res, err) := bar(res) if err != … Equivalent rust: let res = bar(foo)?)?; I think go should add the ? sigil or something equivalently terse. Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possi…

This would drive me nuts to write as a Scala dev, but I can see merit to the philosophy. Go basically lowers the ceiling to raise the floor. Meanwhile Scala can let you glimpse the heavens but has no problem showing you the deepest, darkest pits of hell.

Re: One year after switching from Java to Go

#482

Post by derekperkins »

sn9 wrote: post #432
AYBABTME wrote: post #390

Earlier quoted context omitted.

Rust has its uses but why would you write infra code in Rust when Go is used for most of it, and is just much more ergonomic and fast to work with. The iteration times with Rust are quite detrimental. On the other hand, most of k8s' ecosystem is in Go. I don't like commenting in language-war territory things but I found your comment surprising. "Rust or JVM" for infra isn't a dichotomy I would expect.

Discord had a pretty famous transition from Go to Rust [0]. [0] https://discord.com/blog/why-discord-is-switching-from-go-to...

They didn't have particularly great reasons to migrate at the time besides the team wanting to write rust. That article is just trying to provide validation

Re: One year after switching from Java to Go

#483

Post by whstl »

okeuro49 wrote: post #324
whstl wrote: post #255

Earlier quoted context omitted.

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

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

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

Re: One year after switching from Java to Go

#484

Post by [deleted] »

gf000 wrote: post #282
whstl wrote: post #255

Earlier quoted context omitted.

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

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

[deleted]

Re: One year after switching from Java to Go

#485

Post by whstl »

gf000 wrote: post #282
whstl wrote: post #255

Earlier quoted context omitted.

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

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

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.

Re: One year after switching from Java to Go

#486

Post by winrid »

maccard wrote: post #306
winrid wrote: post #283

Earlier quoted context omitted.

Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think. It could also be when he's hitting "run test" it's actually "compile and run"...

> Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think. Ok, maybe I misspoke about the "JVM" startup. But the time between `mvn test` and it actually logging the first line of user code was in the region of 15 seconds. Every java project I've worked on has had startup time issues once they're bigger than a toy project. Saying…

BTW, I wonder if any test frameworks are using the hot reloading JVMs yet? Would also solve this problem.

Re: One year after switching from Java to Go

#487

Post by cies »

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 found String (Boot) a horror to work with. Annotation based devt with super weird errors. The great thing was that most errors where run into by many before me so could be solved by a simple web search/ Stack Overflow article.

To me being able to CTRL-click my way into the libraries is very important. Overuse of annotations (a.k.a. magic) breaks that. It is what monkey patching is for Ruby. The beginning of the downfall IHMO of an otherwise great language.

Luckily Kotlin's culture avoids this.

Re: One year after switching from Java to Go

#488

Post by cies »

725686 wrote: post #400
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…

"cargo cult" really? Have you ever built maintained big a Java codebase? Spring is a marvel that sprang out of the experience of very, very talented people. It can be misused, of course, like any other technology, but it is a huge productivity booster.

You are joking right?

"Spring is a marvel that sprang out of the experience of very, very talented people." --> sounds very culty to me.

And yes I maintain both Spring and non-Spring JVM projects.

Re: One year after switching from Java to Go

#489

Post by cies »

peterashford wrote: post #466
cies wrote: post #246

Earlier quoted context omitted.

Like the article I hear Spring Boot here mentioned again. I also really hate the annotation culture. This is big in Spring Boot, and more common in Java since it is so damn verbose. It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).

I think this is why most criticism of Java sounds weird to me. I've used Java since 1.3-ish and I've never used a web framework or an annotation and I think I've used a factory once (I think there's one in Swing and I recall thinking it was a stupid design choice).

Like I say:

> It is not inherent in Java though

"Coupling by annotation" culture (which diminishes many of the benefits of using a typed language, as it pushes coupling to runtime and by means of reflection) IS inherent to SpringBoot. Hence my distaste for it.

Java's okay, prefer Kotlin though these days.

Re: One year after switching from Java to Go

#490

Post by kuschku »

CBLT wrote: post #412
kuschku wrote: post #332

Earlier quoted context omitted.

Java developers may write verbose python, but that doesn't compare to the crimes actual python devs commit. Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.

Hey, sorry, that might have been me. I did that then left the company. In my defense, I had to hack around a different Python library also manipulating sys.path, which nobody likes except this one dev team in a different timezone. They somehow got a director to declare that I would fix this issue they self-created before they woke up in 8h, and I wasn't allowed to rip out the library. So, ugly sys.path manipulation i…

The project is an open source project, so it's likely not your fault :)

I can fully see how and why this might have grown historically in ye olden days of python2, but it's not sustainable to continue adding floors ontop of a rotten foundation. Code needs maintenance like anything else, and far too often there's no budget or time available for it. Even if that maintenance would reduce the overall workload.

Post reply on HN