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

Go is my hammer, and everything is a nail

maragu.dev

Post reply on HN
Print view View original

141–150 of 816 posts

Re: Go is my hammer, and everything is a nail

#141

Post by cybrexalpha »

acedTrex wrote: post #128
cybrexalpha wrote: post #121

I've been coding in Go for over five years. I like Go, but I don't love it. It's never my first choice, although I don't advocate for rewrites just to move away from it. The tooling is a mess. Go modules still feel like a 'first pass' implementation that never got finished. There's no consistency in formatting or imports (even though Go claims there is). Generics are a good step but are still very primitive (no gener…

What do you mean by no consistency in formatting? go fmt is a solid formatter that does its job

Go fmt is pretty good, but it's not ideal. My biggest gripe is imports. Go fmt will just sort imports alphabetically in lists that aren't separated by a blank line. Goimports will separate out core from 3rd party imports, unless you run it with the local flag then it'll add a third block of "local" imports.

But this spread means that it's not consistent across projects which style is preferred.

Some examples, based on cursory looking at big Go codebases: - Kubernetes, one of the biggest public-facing Go projects, uses the 3-block style https://github.com/kubernetes/kubernetes/blob/master/pkg/con... - TIDB uses 2-block style https://github.com/pingcap/tidb/blob/master/pkg/ddl/placemen... - MinIO uses 2-block https://github.com/minio/minio/blob/master/internal/grid/con...

In all of those cases if you make a change and just run 'go fmt' it very well could inject any new imports in the first block, which would be wrong and you wouldn't know until project CI picks it up.

Re: Go is my hammer, and everything is a nail

#142

Post by jerf »

bborud wrote: post #118
DarkNova6 wrote: post #4

If all you know is a Hammer… I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me wanting. It strikes me that Go is riding the peak of hype languages, succeeding Rust and Node.js (which are all good pieces of technology and absolutely have their merit). And like with most hype driven decisions there is little (self) awareness of context and…

I think the hype has already peaked for Go. When we switched to Go 8-9 years ago I already felt the hype had died down. We were late to the party. And I saw that as a good thing. To me it suggested Go was going to stick around. And now, almost a decade later, we're still using it. Note that at my company, we're a bunch of grumpy old guys with about 30 years of experience each. If you dangle a new and shiny language i…

Go and Node have some significant overlap, but Go and Rust are barely even competitors. Of course there's a lot of programs that you can use either to write. There's a lot of programs where it hardly even matters which language you pick at all because they're all perfectly acceptable solutions, though, so that really isn't saying much. But if you map languages out by the programs where language choice matters at least a little and where a given language is legitimately one of the top contenders, Go and Rust don't have a particularly strong amount of overlap in my opinion. They do, but again, lots of languages have overlap; I don't see the Rust/Go relationship being particularly heavily overlapping. (Go/Java or Rust/C++, now there's overlap, for comparison.)

Re: Go is my hammer, and everything is a nail

#143

Post by cybrexalpha »

jerf wrote: post #140
cybrexalpha wrote: post #121

I've been coding in Go for over five years. I like Go, but I don't love it. It's never my first choice, although I don't advocate for rewrites just to move away from it. The tooling is a mess. Go modules still feel like a 'first pass' implementation that never got finished. There's no consistency in formatting or imports (even though Go claims there is). Generics are a good step but are still very primitive (no gener…

Not sure what you mean by "no generics on interfaces"? https://go.dev/play/p/jGINeUt1JTE Also echoing not sure what you mean by "no consistency in formatting or imports". It is increasingly difficult to use Go without gofmt getting run, since I have to imagine fewer and fewer people nowadays are using an editor that has neither custom support for their language nor LSP integration, and integration with gopls automati…

> Not sure what you mean by "no generics on interfaces"?

I didn't word this very well. You can have a generic interface, and functions on that interface can refer to generic types. But you can't have a generic method on an interface that uses a different generic type. For example you can't have:

``` type YieldThing[T any] interface { Yield() T DoOperation[U any](U) } ```

Re: Go is my hammer, and everything is a nail

#144

Post by justinsaccount »

conor- wrote: post #120
daghamm wrote: post #47

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything . I have extremely good productivity when using Go. Once your project exceeds 100 lines it is usually even better than python. And yes, I am aware that Rustians did a survey where Rust was crowned as the most efficient language but in my reality (which may differ from yours) Go is simply the best…

Go is the only language I've ever felt highly productive working in. Oftentimes in other stacks I find myself in analysis paralysis on meta things that don't matter: - what design patterns/language features make sense to use - what is the best lib to accomplish X - how do you keep things up to date With Go, the language is so simple that it's pretty difficult to over engineer or write terse code. Everything you need…

Yep.. say you wanted to make a simple http service that needs to

* request a json.gz file from another HTTP service * decompress it * deserialize the json, transform it a bit

That's net/http (and maybe crypto/tls), compress/gzip, encoding/json. I need to make zero decisions to get the thing off the ground. Are they the best libraries in the world for those things? no.. but will they work just fine for almost every use case.

Re: Go is my hammer, and everything is a nail

#145

Post by lairv »

kjksf wrote: post #133
lairv wrote: post #105

Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…

So you're ok with Python, which doesn't have sum types or null safety, 2 out of 3 things you say are missing in Go. In fact, Python didn't have any compile-type type until recently and compared to Go is slow and bloated. So maybe the issue is not Go's lacking some features but something entirely different.

class A: def __init__(): pass def f(self): pass

def g(a: A | None): a.f()

(edit: I don't know how to format code on HN)

If I activate type-checking in VS Code this will highlight an error, although the python interpreter will indeed try to run it without compile time error

As I said, for my side projects this is enough for me to model my problems properly without having to resort to multiple hacks

And I took Python as an example, I also enjoy using Ocaml and Rust

Re: Go is my hammer, and everything is a nail

#146

Post by jerf »

kamaal wrote: post #54
danielvaughn wrote: post #39

Earlier quoted context omitted.

I just began using Go literally 2 days ago, but I could already see building most of my projects in it from here on out. It has the type system I'd need from Java or C#, while being almost as simple and readable as Python. I love the module system so far and enjoy not having to decide on my own formatter. Go is perfectly boring and simple, and seems to get out of my way. At least, that's how it feels as a newcomer. I…

What about the absence of exception handling? Plus OO has its own advantages, even if you don't use it all that much, its one of the best ways to fit problems into neat design patterns. Go seems to be missing those features.

Interfaces and functions do pretty much everything inheritance does. It's just cut in a different direction. If you go in demanding that Go support inheritance you'll be in for a bad time; if you go in demanding that it have some good solution to those problems that you may not be used to, you'll find it generally has them.

Re: Go is my hammer, and everything is a nail

#147

Post by Thaxll »

giraffe_lady wrote: post #38
Thaxll wrote: post #19

Earlier quoted context omitted.

Protobuf is not the default in Go the default is REST. What tools are a mess? Go tooling ( runtime ) and IDE integration is very good. Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.

Go tooling was relatively very good a decade ago but other languages have improved a lot since then, significantly because of its influence, and it's now about average. It's still better than python, and C or C++ of course. But about even with typescript, ruby, shit even php and ocaml have nearly caught up with their tooling. Go's is significantly worse than rust god help us and elixir has always made good excellent…

Go tooling is far better than Elixir and I would say above Rust.

You should have a look what the go command can do.

Re: Go is my hammer, and everything is a nail

#148

Post by jerf »

cybrexalpha wrote: post #143
jerf wrote: post #140

Earlier quoted context omitted.

Not sure what you mean by "no generics on interfaces"? https://go.dev/play/p/jGINeUt1JTE Also echoing not sure what you mean by "no consistency in formatting or imports". It is increasingly difficult to use Go without gofmt getting run, since I have to imagine fewer and fewer people nowadays are using an editor that has neither custom support for their language nor LSP integration, and integration with gopls automati…

> Not sure what you mean by "no generics on interfaces"? I didn't word this very well. You can have a generic interface, and functions on that interface can refer to generic types. But you can't have a generic method on an interface that uses a different generic type. For example you can't have: ``` type YieldThing[T any] interface { Yield() T DoOperation[U any](U) } ```

I figured based on your comment you meant something by it.

In which case I'd point out that it goes beyond interfaces and Go just doesn't permit that in general, for those who are playing along. All generics are always fully instantiated. You can have a

    type Holder[T any, U any] struct {
        Val1 T
        Val2 U
    }
but you can never have anything like a variable of type Holder[int], with a type-currying effect or something where the U bit is still unbound, or a bare variable of type "Holder" without any further parameters. All types within the language are always fully instantiated after compile.

Re: Go is my hammer, and everything is a nail

#149

Post by znkr »

deergomoo wrote: post #92

There are a lot of aspects of Go that I’m really not a fan of, but I’ve been writing an increasing amount of it over the last few months and on the whole I’m finding it really enjoyable—even though I’m not sure I could empirically explain why. The tooling is heaven compared to other stuff we do a lot of at work (TS/JS of course being the main offender), and generally I find I spend less time thinking about things tha…

I have been writing Go code for many years, the fact that I don’t need to think about things unrelated to the problem I am trying to solve is why I love Go. I definitely learned a lot about Go and I am thinking more about certain aspects than before, but usually only in the context of API design.

Re: Go is my hammer, and everything is a nail

#150

Post by randomdata »

markhahn wrote: post #110
caerwy wrote: post #5

This article is not so much about Go but about choosing to specialize in one language ecosystem instead of spreading one's attention across several.

I always wonder: why do some people like to do this (spreading)? I wonder the same about people who are "distro tourists". The latter tend to spend a lot of time on what seems like unproductive diddling (desktop skins, etc).

1. Because I like engineering more than programming. If a problem is best solved by, say, a mechanical system then I will do that instead. But even where programming provides the best solution, not all ecosystems are equal. If I have a problem best solved by, say, AI/ML, it is often impractical to avoid Python. Likewise, if I have a problem best solved in the web domain, it is often impractical to avoid Javsacript. SQL where databases are the best solution. So on and so forth.

2. Because I like to learn. In my younger days, I found a lot of value in exploring the different ways people live. In fairness, I've toured the programming world enough by now that I am less compelled to keep go on "programming language vacations" – at some point you start to feel like you've seen it all, but believe I would be a far worse programmer today had I not been able to take ideas from a wide range of different cultures over the years. There are some good ideas out there that don't seem to ever gain mass adoption outside of their originating ecosystem.

Post reply on HN