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

171–180 of 503 posts

Re: One year after switching from Java to Go

#171

Post by roncesvalles »

bryancoxwell wrote: post #18

> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store.

Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies, call init() in topo order, and other such things.

Test using monkey-patching. Stop using interfaces just to be able to swap a real thing with a mock implementation. These are all symptoms of writing Java in Go.

Re: One year after switching from Java to Go

#172

Post by geitir »

bryancoxwell wrote: post #18

> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…

Also https://github.com/uber-go/fx

Re: One year after switching from Java to Go

#173

Post by coder543 »

CharlieDigital wrote: post #123
hedora wrote: post #117

Earlier quoted context omitted.

Exceptions are fine if you never catch them. So is calling abort(). (Which is the Unix way to do what you described.) If you need to handle errors, you quickly get into extremely complicated control flow that you now have to test: // all functions can throw, return nil or not. // All require cleanup. try { a = f(); b = a.g(); } catch(e) { c = h(); } finally { if a cleanup_a() // can throw if b cleanup_b() // null che…

Can you give the equivalent in Go?

I recommend ignoring the other reply you just got. They are clearly building a bad faith argument to try to make Go look terrible while claiming to sing its praises. That is not at all how that would look in Go. The point being made was that the exception-based code has lots of hidden gotchas, and being more explicit makes the control flow more obvious.

Something like this:

    a, err := f()
    if err != nil {
        c, err := h()
        if err != nil {
            return fmt.Errorf("h failed: %w", err)
        }
        cleanupC(c)
        return fmt.Errorf("f failed: %w", err)
    }
    defer cleanupA(a)

    b, err := a.g()
    if err != nil {
        c, err := h()
        if err != nil {
            return fmt.Errorf("h failed: %w", err)
        }
        cleanupC(c)
        return fmt.Errorf("a.g failed: %w", err)
    }
    defer cleanupB(b)

    // the rest of the function continues after here
It’s not crazy.

With Java’s checked exceptions, you at least have the compiler helping you to know (most of) what needs to be handled, compared to languages that just expect you to find out what exceptions explode through guess and check… but some would argue that you should only handle the happy path and let the entire handler die when something goes wrong.

I generally prefer the control flow that languages like Rust, Go, and Swift use.

Errors are rarely exceptional. Why should we use exceptions to handle all errors? Most errors are extremely expected, the same as any other value.

I’m somewhat sympathetic to the Erlang/Elixir philosophy of “let it crash”, where you have virtually no error handling in most of your code (from what I understand), but it is a very different set of trade offs.

Re: One year after switching from Java to Go

#174

Post by coder543 »

coder543 wrote: post #173
CharlieDigital wrote: post #123

Earlier quoted context omitted.

Can you give the equivalent in Go?

I recommend ignoring the other reply you just got. They are clearly building a bad faith argument to try to make Go look terrible while claiming to sing its praises. That is not at all how that would look in Go. The point being made was that the exception-based code has lots of hidden gotchas, and being more explicit makes the control flow more obvious. Something like this: a, err := f() if err != nil { c, err := h()…

Or, if you really hate duplication, you could optionally do something like this, where you extract the common error handling into a closure:

    handleError := func(origErr error, context string) error {
        c, err := h()
        if err != nil {
            return fmt.Errorf("%s: h failed: %w", context, err)
        }
        cleanupC(c)
        return fmt.Errorf("%s: %w", context, origErr)
    }

    a, err := f()
    if err != nil {
        return handleError(err, "f failed")
    }
    defer cleanupA(a)

    b, err := a.g()
    if err != nil {
        return handleError(err, "a.g failed")
    }
    defer cleanupB(b)

    // the rest of the function continues after here

Re: One year after switching from Java to Go

#175

Post by 3uler »

roncesvalles wrote: post #171
bryancoxwell wrote: post #18

> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

And yet Uber wrote fx[1] to support DI in their golang services. It’s clearly a useful pattern when working on large services.

[1]: https://github.com/uber-go/fx

Re: One year after switching from Java to Go

#176

Post by idoubtit »

heluser wrote: post #116
jayceedenton wrote: post #19

Earlier quoted context omitted.

Which of these languages is declarative? Aren't they both imperative?

Java 8+ is basically a declarative language. They even officially started departing from Object Oriented Programming towards Data Oriented Programming ( article by their chief architect https://www.infoq.com/articles/data-oriented-programming-jav... ). Unfortunately, most of the comparison articles come from people who still code POJOs with setters, use for loops and overall rely on mutable and unsafe code. And using…

> Java 8+ is basically a declarative language.

That's a bold claim!

The article you link to does not contain the word "declarative". It simply states that modern Java allows more of Data-Oriented Programming, meaning a emphasis on pure data structures (records) and more expressive types (algebraic types). It doesn't say much about the code that deals with this data, which is of course procedural.

Apart from SQL which is not generic, I've toyed with two declarative languages, and I can't see much similarities with Java. https://en.wikipedia.org/wiki/List_of_programming_languages_...

Re: One year after switching from Java to Go

#177

Post by roncesvalles »

3uler wrote: post #175
roncesvalles wrote: post #171

Earlier quoted context omitted.

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

And yet Uber wrote fx[1] to support DI in their golang services. It’s clearly a useful pattern when working on large services. [1]: https://github.com/uber-go/fx

I disagree with the premise of that whole project. It shouldn't exist.

Re: One year after switching from Java to Go

#178

Post by cowl »

qaq wrote: post #137
hedora wrote: post #114

Earlier quoted context omitted.

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…

99% of people who never written go will know what the go version does

and 99% of the people will learn the ? shortcut in fraction second. it's just like every other operator ffs. are you dumbfounded everytime you see the channel operators (->) ? noone takes a second thought to them after the first couple of seconds when they encounter them the first time.

Re: One year after switching from Java to Go

#179

Post by azaras »

invalidname wrote: post #94

All k8s operators are written in Go. It's really unsurprising that Java doesn't fit there. Java has huge advantages for typical web applications (observability, deployment flexibility, deep toolchain beyond IDE etc.). I've seen companies trying to use Go in the environment where the JVM excels, then breaking down the problem to thousands of small microservices which end up making something simple into shards of compl…

There are operators written in Java and Rust.

Re: One year after switching from Java to Go

#180

Post by vram22 »

nesarkvechnep wrote: post #149
MrDarcy wrote: post #25

Earlier quoted context omitted.

I hit this point in tfa and had the same comment. Please don’t pass things around in a Comtext. Maybe stash a slog logger in there, but that’s about it. I made the switch to Go a few years ago. For those who are on a similar journey as the author, or the author himself, I suggest spending time with the Go standard library and tools written by Rob Pike and Russ Cox to get a handle on idiomatic Go. It’s clear the autho…

I’m yet to see a former Java developer who uses the idioms of the language they currently use. They all just write Java in a different language.

That is a function of the developer, not of the language, i.e. f(dev), not f(lang) ;)

Replace Java with star and that statement still holds true (for some people).

Hence the statement that you can write FORTRAN in any language.

https://blog.codinghorror.com/you-can-write-fortran-in-any-l...

Post reply on HN