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

271–280 of 816 posts

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

#271

Post by hellcow »

arp242 wrote: post #262
randomdata wrote: post #173

Earlier quoted context omitted.

> it's pretty difficult to over engineer I don't know about that. Every programmer's first Go program seems to like to go to channel city. Perhaps more accurately: Over-engineering your Go program is going to quickly lead to pain. It doesn't have the escape hatches that help you paper over bad design decisions like some other languages do.

Also: interfaceiritus. Someone saw "accept interfaces, return structs" somewhere and now EVERYTHING accepts an interface, whether or makes sense or not. Many (sometimes even all) of these interfaces have just one implementation.

Doing this allows you to mock out that implementation in unit tests.

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

#272

Post by foldr »

Nijikokun wrote: post #213
foldr wrote: post #162

Earlier quoted context omitted.

There are good reasons for not allowing generic methods: https://go.googlesource.com/proposal/+/refs/heads/master/des...

Realistically the reasons are this: > So while parameterized methods seem clearly useful at first glance, we would have to decide what they mean and how to implement that. They just didn't want to decide what they mean or how to implement them.

Right, but that's because it is not obvious what they should mean or how to implement them. In particular, it seems that intolerable complications to the linker would be required. Contrast that with, say, a proposal to add a more concise syntax to Go for anonymous functions. Everyone can see exactly what that would mean and how it would be implemented.

I'm not saying that Go should never add generic methods to the language. But it's at least reasonable to hold off from doing so until these issues are clarified.

There is a concise explanation of the central problem in a comment in the issue thread:

> The crux of the problem is that with a parametric method, the generated code for the body depends on the type-parameter (e.g. addition on integers requires different CPU instructions than addition of floating point numbers). So for a generic method call to succeed, you either need to know all combinations of type-arguments when compiling the body (so that you can generate all bodies in advance), or you need to know all possible concrete types that a dynamic call could get dispatched to, when compiling the call (so you can generate the bodies on demand). The example from the design doc breaks that: The method call is via an interface, so it can dispatch to many concrete types and the concrete type is passed as an interface, so the compiler doesn't know the call sites.

Rust allows generic methods on traits but doesn't allow these traits to be instantiated as trait objects. Perhaps Go could do something similar. https://docs.rs/erased-generic-trait/latest/erased_generic_t.... But it's far from obvious to me that this would be a good idea for Go, and I'm glad the Go team haven't rushed into anything here.

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

#273

Post by insane_dreamer »

I would argue that a language's ecosystem matters much more than the language itself. This is why Java is still so popular, and why certain languages are better suited to certain tasks than others. For example, if you're doing numeric or scientific related development, it's hard to beat Python even if Go itself is better, because of the great set of robust libraries you get for free. (Yes, Go has some equivalent, but not as tried and true as numpy, scipy etc.)

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

#274

Post by erik_seaberg »

duskwuff wrote: post #242
hughesjj wrote: post #212

Earlier quoted context omitted.

Eh, imo the go libraries still aren't up to par with out of the box java libraries. Like there's still no Set class, nor the equivalent of Map.keys. yeah they're easy to write but that's still not an included battery. Also, while the cli to add stuff is useful, there's still nothing to the level of maven or gradle for dependency management, and I usually find myself doing some fun stuff with `find -execdir` for modul…

> Like there's still no Set class map[T]struct{} ?

https://github.com/deckarep/golang-set offers a thread safety option and methods like contains all, intersect, and equal.

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

#275

Post by sedatk »

bitbasher wrote: post #205

Life is barely long enough to get good at one thing so you should choose your thing wisely. That's wisdom I've held for quite some time. Coincidentally, I chose Go as my language of choice as well. The factors that led me to that choice were many, but to highlight some: - incredible standard library - simple to read and write - single static binary builds (assets included, like html/images, etc) - don't need a contai…

I chose C# for the same reasons. It's probably easier to make C# unreadable than Go due to plethora of features, but it all comes down to how you discipline yourself about writing code.

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

#276

Post by bb88 »

laserlight wrote: post #185
maccard wrote: post #174

Earlier quoted context omitted.

> The list comprehension is ever slightly more readable. I disagree - it's terse to the point of being hard to parse, particularly when you get smart ones like: [x for x in t if x not in s] > It is a bit faster to write the code for the Python variant. Code should be written to be read. Saving a few keystrokes vs time spent figuring out the `not in in not with` dance gives the the edge to Golang here. It's "high cont…

Luckily, we are writing Python, not Go, so we can use variable names with more than one letter: [word for word in sentence if word not in bannedWords] Suddenly, nothing is hard to parse.

I do think people should tend to be more verbose with variable names, in general.

And since it's python, use snake case to add faux white space to help the eyes parse the statement.

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

#277

Post by BiteCode_dev »

bborud wrote: post #94

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…

And then you have the ever changing ecosystem, that can take years so sort out on it's own and must be constantly studied.

E.G: if you arrive in Python right now, numpy is in version 2 and polars is stable. uv is all the rage, pydantic gained so much perf it's not even funny, toml is part of the stdlib and textual is looking very good. Type hints are much better than 2 years ago, htmx is used a lot in the web department, fasthtml is having a moment in the light and pyscript got a platform. Is any of those information worth acting on? Should you ignore them all for the sake of productivity? Should you carefully evaluate each proposition?

Now if you have to do that with rust and erlang as well, it's a lot of time you could spend on coding instead.

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

#278

Post by kamov »

lpapez wrote: post #217
GaryNumanVevo wrote: post #189

Earlier quoted context omitted.

Take a look at a JSON parser or ORM written in Go. It's god awful the things they have to do to work around Go's type system. The average developer won't see these things, they're typically just writing glue code between Go's great stdlib (which also contains wild things if you take a look) and other 3rd party dependencies.

> The average developer won't see these things, they're typically just writing glue code between Go's great stdlib (which also contains wild things if you take a look) and other 3rd party dependencies. This is what most of us are doing every day, and exactly what Go excels at.

Sum types allow for more robust modeling of the API boundary in libraries, so in fact having a better type system is desirable even when "just gluing libraries", because it can make incorrect program states physically unrepresentable.

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

#279

Post by nemo1618 »

bborud wrote: post #94

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?"

Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust, or just about any other mainstream language.

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

#280

Post by dwattttt »

duskwuff wrote: post #240
zhengyi13 wrote: post #227

Earlier quoted context omitted.

Not a programmer, so this is every programmer's chance to hammer me on correctness. No, Go doesn't have a type named Dict, or Hash (my Perl is leaking), or whatever. It does have a map type[1], where you can define your keys as one type, and your values of another type, and that pretty closely approximates Dicts in other languages, I think. [1]: https://go.dev/blog/maps

And, if you hate strong typing, there's always map[string]any.

Really, the mismatch is at the JSON side; arbitrary JSON is the opposite of strongly typed. How a language lets you handle the (easily fallible) process of "JSON -> arbitrarily typed -> the actual type you wanted" is what matters.
Post reply on HN