Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

261–270 of 816 posts

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

#261

Earlier quoted context omitted.

This topic has been beaten to death, and being pedantic about the definition of an enum to say "actually go has them" isn't helpful. There are dozens of articles from the last decade which explain the problems. Those problems don't exist in plenty of programming languages. No language is perfect, but go's particular set of bugbears is a good tradeoff

> being pedantic about the definition of an enum to say "actually go has them" isn't helpful. Incorrect. The term "real enums", where used to imply that enums are something other than the basic element of the same name, encompasses a number of distinct features that are completely independent of each other. In order to meaningfully talk about "real enums", we need to break it down into the individual parts. If you're…

Dude. Everyone knew what "real enums" meant including you. Please stop.

And yes popular languages do have real type safe enums. C++, Typescript, Rust, god even Python.

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

#262
post #120

Earlier quoted context omitted.

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…

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

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

#263
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…

My personal Python threshold is 10k lines. After that I tend to loose track of what I am doing and I start to miss static typing and nowadays, an IDE to navigate it. Maybe future Python IDEs can AI scan the codebase and compensate.

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

#264
post #120

Earlier quoted context omitted.

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…

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?

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

Have you considered that your interview process is actually the problem? Focus on the candidate’s projects, or their past work experience, rather than forcing them to jump through arbitrary leet code challenges.

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

#265
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…

Naturally one can't know all the languages of the world.

Even so, I have done consulting since 1999, with a small 2 years pause in research, and have several languages that I keep switching, every couple of months when project reassignment takes place.

The usual T-shape kind of consultant, know some stuff really well, and others good enough to deliver.

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

#266

Earlier quoted context omitted.

This topic has been beaten to death, and being pedantic about the definition of an enum to say "actually go has them" isn't helpful. There are dozens of articles from the last decade which explain the problems. Those problems don't exist in plenty of programming languages. No language is perfect, but go's particular set of bugbears is a good tradeoff

> being pedantic about the definition of an enum to say "actually go has them" isn't helpful. Incorrect. The term "real enums", where used to imply that enums are something other than the basic element of the same name, encompasses a number of distinct features that are completely independent of each other. In order to meaningfully talk about "real enums", we need to break it down into the individual parts. If you're…

Words can have more than one meaning. As far as I know, no one voted you to be arbiter of all terms and their One True Correct™ meaning. It's pretty clear what the previous poster intended to say.

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

#267
post #120
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…

Sure, if everything one does is either CLI stuff, or UNIX daemons, containers, ....

Because in the reign of graphics , GUI, GPGPU, HPC, HFT, ML, game engines,numeric analysis, ... there is hardly any library that really stands out.

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

#268
post #267
post #120

Earlier quoted context omitted.

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…

Sure, if everything one does is either CLI stuff, or UNIX daemons, containers, .... Because in the reign of graphics , GUI, GPGPU, HPC, HFT, ML, game engines,numeric analysis, ... there is hardly any library that really stands out.

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.

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

#269
post #211

Earlier quoted context omitted.

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 us…

Sounds like curl ... | jq ... to me! Not saying you shouldn't use Go for that problem, in a particular context, but it does drive home how much of programming is glue ... there is combinatorial amounts of glue, which is why JSON, HTTP, compression, etc. end up being part of so many problems

There’s a big difference between building something on curl and jq and building something using a language’s standard library.

Everything is just bits at the end of the day. Just about anything can do anything.

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

#270
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…

[deleted]
Post reply on HN