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

291–300 of 816 posts

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

#291

Post by travisd »

randmeerkat wrote: post #264
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?

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

Making an HTTP request and dealing with JSON data is a weed-out question at best. Not sure if you are interpreting the grandparent comment as actually having them write a JSON parser, but I don't think that's what they meant.

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

#292

Post by jayd16 »

xyproto wrote: post #228
jayd16 wrote: post #214

Earlier quoted context omitted.

I'm asking this earnestly but is Go suitable for native GUI apps (not web)? 3D graphics/Games? Audio processing?

Yes, because one can either turn off the GC, allocate memory up front (arena style), or call C or Assembly from Go. The performance is likely to be good enough with GC turned on, though, because it is unusually fast.

Turning off the GC isn't the blocker. Plenty of GC languages manage.

I'm more interested in how Go handles graphics APIs and binding a render thread or working with GUI threads considering how goroutines are done. Does one need to write non-idiomatic go, avoiding goroutines or is there some trick?

For example, GTK isn't thread safe so you can't just use that library without considering that.

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

#293

Post by matwood »

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

I can think of many reasons. Seeing other language perspectives definitely can help with your primary language. I have experienced this. But, I have also explored other languages as a means of procrastination or ways to do something easy when bumping into the more challenging depths of my language of choice.

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

#294

Post by abtinf »

gcau wrote: post #229
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…

Is this something Go intentionally didn't add?

Operator overloading essentially makes code unreadable without deep diving past the interface boundary.

In Go, you can generally look at any snippet of code and know precisely what it does.

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

#295

Post by 0cf8612b2e1e »

jayd16 wrote: post #289
0cf8612b2e1e wrote: post #254

Earlier quoted context omitted.

People write games and GUI apps in Python, so why not?

Is there some particular reason Python is similar to go with regards to GUIs or are you saying everything can do everything?

Python is a slow interpreted language (I write Python every day). Go is compiled and an order of magnitude faster for most everything.

So, I guess, yeah, everything can do everything. Computers are fast where language is rarely going to be the deciding factor.

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

#296

Post by flkenosad »

busterarm wrote: post #23
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.

Bazel. While not Go-specific, it's the extremely popular option in the space and I've seen it bring many-a-seasoned wizard to their knees in tears. Also managing your go dependencies if you cargo-cult other Google behaviors like monorepos tends to be painful. Basically just cargo-culting Google behavior == pain. Choosing golang can often be part of this behavior pattern.

I wish Bazel was a Go project. Unfortunately, it's written in Java.

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

#297

Post by therealdrag0 »

RandomThoughts3 wrote: post #138
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…

That's why I love Go so much. You want to write a very clever library using elegant abstraction and generics to have a cool innovative interface to solve your problem? Tough luck, you can't. So instead, you will just have to write a bog standard implementation with for-loops and good old functions which you will have to copy and tweak as needed where you really need something more complicated. It will work perfectly…

For loops? Dang that’s some clever syntax you have there. Personally I prefer a big standard while loop. /s

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

#298

Post by jayd16 »

mats852 wrote: post #288
sedatk wrote: post #275

Earlier quoted context omitted.

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.

https://github.com/bflattened/bflat

Single file AOT is now officially supported by base dotnet.

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

#299

Post by mjevans »

travisd wrote: post #291
randmeerkat wrote: post #264

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

Making an HTTP request and dealing with JSON data is a weed-out question at best. Not sure if you are interpreting the grandparent comment as actually having them write a JSON parser, but I don't think that's what they meant.

I either had that come up in an interview recently myself, OR it wasn't clear to me that I was allowed to use encodings/json to parse the json and then deal with that. I happened to bomb that part of the interview spectacularly because I haven't written a complex structure parser in years given every language I've used for such tasks ships with proper and optimized libraries to do that.

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

#300

Post by neonsunset »

jayd16 wrote: post #298
mats852 wrote: post #288

Earlier quoted context omitted.

https://github.com/bflattened/bflat

Single file AOT is now officially supported by base dotnet.

bflat has somewhat different set of goals and offers "zerolib" and "uefi" runtime target flavours. Its author is also working on the official NativeAOT, which bflat builds on top of :)

While we're at it, it's impressive how much NativeAOT has improved within just 2 releases or so: https://migeel.sk/blog/2023/11/22/top-3-whole-program-optimi...

There are other niceties like dehydrated binary sections, metadata compression, linker that is deeply aware of the type system, etc. to keep the binary size scalable as you keep adding dependencies. I'm seeing even smaller sizes with .NET 9 preview.

Post reply on HN