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

351–360 of 816 posts

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

#351

Post by eweise »

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…

Personally I don't find it great for prototyping. There's just too much boilerplate, which is why I use other languages for fun/personal projects.

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

#352

Post by christophilus »

sedatk wrote: post #275
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.

My main beef with C# was the culture. I spent around 15 years building stuff in C# (since 1.0), and absolutely loved the language. But, man. The Microsoft shops were so full of Kool-Aid drinkers, and there was so much enterprisey crap that often came along with that. I miss C#, but I don't miss the culture.

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

#353

Post by Kamq »

kaba0 wrote: post #106
danielvaughn wrote: post #56

Earlier quoted context omitted.

This is my first time working with a language that exclusively uses errors as values, and I haven't had time to develop any strong feelings about it. So far it feels nice because it makes error handling crystal clear, but I could also see it becoming cumbersome over time.

It’s the exact same broken system as has been known from C, it’s literally checking `errno` all the time.

I mean, you're not wrong, It's just strings (usually) instead of ints.

It's pretty bad, but it turns out that exceptions and inverting my entire program to pass into a Result's flatmap chain are even worse.

When they come up with another strategy, I'll try that instead, but until then I'll keep using the least bad option I've found.

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

#354

Post by nrr »

throwaway2037 wrote: post #343
nrr wrote: post #290

Earlier quoted context omitted.

It comes down to how the standard library makes you do things. I don't think there's any reason why a more stringly-typed way of handling JSON (or, indeed, a more high-level way of using HTTP) is outside of the realm of possibility for Go. It's just that the standard library authors saw fit not to pursue that avenue. This variability is honestly one of the reasons why I dislike interviews that require me to synthesiz…

I like your story about debugging during an interview. I can say from experience, you always have one teammate that can just debug any problem. I am always impressed to watch and learn new techniques from them.

This has also been my experience, yeah. My interviewers were very interested in watching me rifle through that core dump. (:

Ultimately, it feels to me like selecting for people who both can navigate existing code and interrogate a running system (or, minimally, one that had gone off the rails and left clues as to why) is the right way to go. It has interesting knock-on effects throughout the organization (in, like, say, product support and quality assurance) that are direly understated.

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

#355

Post by stouset »

bouncycastle wrote: post #328
blt wrote: post #216

I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It's so hard to accept something like Add(Scale(s1, vec1), Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with Python and C++ for now. Rust is really appealing as a C++ replacement, but it has too many rules to replace Python for one-off scripts. Still need to try Nim and Swift, I g…

in my case, I prefer to see that the code is calling functions, so that I'm aware that they take extra resources such as stack space and it's easy to quickly jump into the functions to find what they are doing. Code that uses op overloading is hard to navigate and sometimes causes intense debugging pain. Simplicity always beats fancy features imo.

Functions, especially functions like numerical operations, tend to get trivially inlined and consume no stack space.

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

#356

Post by scubbo »

kloop wrote: post #235
badrequest wrote: post #208

Earlier quoted context omitted.

I think other languages cause folks to understand JSON responses as a big bag of keys and values, which have many convenient ways of being represented in those languages. When you get to Go and you want to parse a JSON response, it has to be a well-defined thing that you understand ahead of time, but I also think you adapt when doing this more than once in Go.

var res map[string]any err := json.Unmarshal(&res)

Uh huh....and what comes next?

Trying to descend more than a couple of layers into a GoLang JSON object is a mess of casts.

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

#357

Post by scubbo »

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{} ?

So, like they said, no Set class.

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

#358

Post by tslocum »

kbolino wrote: post #330
dartos wrote: post #268

Earlier quoted context omitted.

Or servers, and about anything that really benefits from concurrency. Even a lot of games could be made with go. The gc wouldn’t really kill the frame rate of a game unless you really push it.

Gamedev in Go will require cgo (and not just the easy parts), which ups the complexity quite a bit, unless you're already very familiar with C. I think it's pretty viable nonetheless, but more for the experienced developer with specific goals outside of the nice parts of common engines, or for a hobbyist who knows the language and wants to tinker and learn.

Sorry, this comment is so incorrect that I have to ask, what are you basing it on?

You can create games today using Go without cgo, and there are numerous examples of shipped games of varying complexity and quality. I do this to ship the bgammon.org client to Windows, Linux and WebAssembly users, all compiled using a Linux system without any cgo.

https://ebitengine.org

https://github.com/sedyh/awesome-ebitengine#games

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

#359

Post by marcus_holmes »

nrr wrote: post #290
mapcars wrote: post #151

Earlier quoted context omitted.

I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?

It comes down to how the standard library makes you do things. I don't think there's any reason why a more stringly-typed way of handling JSON (or, indeed, a more high-level way of using HTTP) is outside of the realm of possibility for Go. It's just that the standard library authors saw fit not to pursue that avenue. This variability is honestly one of the reasons why I dislike interviews that require me to synthesiz…

My favourite tech interview (so far) was similar: "here's the FOSS code base we're working on. This issue looks like about the size we can tackle in the time we have. Let's work on this together and solve it".

I got to show how I could grok a code base and work out where the problem was quickly, and work out a solution to the problem, and how I understood how to contribute a PR. Way better than random Leetcode bullshit, and actually useful: the issue was actually solved and the PR accepted.

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

#360

Post by shepherdjerred »

monkeywork wrote: post #348
tialaramex wrote: post #318

Earlier quoted context omitted.

> 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?" I am extremely doubtful that this is true and would like evidence.

kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.

I feel this way... very often.

* Init functions

* Top-level variables being shared between all files in a package

* For-loop sharing (fixed in 1.22 [0])

* ldflags (this is more of build behavior, but it took me a while to figure out how some variables were being set [1]. Note: Go does embed some data by default, but an app I was working on introduced more metadata)

* Go build directives prevent IDEs/linters from analyzing a file at all. E.g. if you edit a linux-only file on macOS, you get _zero_ help.

I dunno, there are a lot of other weird, confusing things that Go does. It is less than most other languages, though.

[0] https://go.dev/wiki/LoopvarExperiment

[1] https://www.digitalocean.com/community/tutorials/using-ldfla...

Post reply on HN