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

281–290 of 816 posts

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

#281

Post by rlp »

mapcars wrote: post #160
neonsunset wrote: post #14

Earlier quoted context omitted.

Thanks for posting this. It’s an unfortunate choice of “one hammer to rule them all” given Go does not offer necessary coverage at both low and high ends of abstraction (and performance) the way C# does. For me, it’s a similar kind of hammer. (I prefer to think of it as a crowbar ;D)

The problem with C# is its created by Microsoft, even if its a good language its hard to look at it and not think how much its limited while used outside of Windows.

This is no longer remotely true. Most .NET teams I know now deploy on Linux and develop on Windows/Mac/Linux.

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

#283

Post by neonsunset »

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.

Can't Go compiler statically prove that such single implementation interfaces are indeed that and devirtualize the callsites referring to them?

Either way, the problem seems to happen in most languages of today, if they (or their community) ever happen to accidentally encourage passing an opaque type abstraction over a concrete one.

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

#284

Post by matwood »

Dansvidania wrote: post #125
kaba0 wrote: post #95

Earlier quoted context omitted.

How is it different than, say, java for this generalist purpose?

java on its own is not a competitor to go, IMO, due to the batteries included "culture" in the go ecosystem. I would need to compare it with, for example, Java + Spring(Boot). I find Go to be simpler and more pleasant to use.

I agree with Go being simpler, but modern Java and Spring Boot is also fine. Backend programmers are spoiled with riches nowadays with all the completely workable options we have.

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

#285

Post by bb88 »

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 appreciate the Rust approach where Rust C and Rust Python get along really well together. They really thought about interoperability with existing infrastructure.

Java wanted everyone to rewrite everything in Java because that was easier than to interface with the existing libraries on the OS.

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

#286

Post by matwood »

stuff4ben wrote: post #124
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…

Damn, everything new really is old again. Everyone said the same thing about Java. Yet it still works and gets the job done. Go does as well. I'd rather poke my eyes out with a nail than use Python.

> I'd rather poke my eyes out with a nail than use Python.

Glad I'm not the only one. Every time I'm forced to use Python I cringe. What version disaster and I'm going to run into today? The 2->3 transition happened a long time ago at this point and I still run into lingering effects. Also, for short 'script' like things Python doesn't feel any quicker or easier to write. Go is my Goto (hehe) for short scripts.

And while I'm ranting, I'll also say that modern/latest version Java is also really nice.

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

#287

Post by metaltyphoon »

andrew_eu wrote: post #80

I can't really disagree with the points the article makes in favor of Go, and it's not selling it over some other language/framework/tool but just celebrating how great of an ecosystem Go has. And it's true -- Go's ecosystem has matured into something very pleasant to work with. By the same token I know professors who still write their simulation scripts in QBASIC because that's what they are familiar with and they c…

Go has one of the worst FFI support IMO. Code as comments? It doesn’t ever support C callback without a “bridge” method. MSVC support? Try debugging when CGO is enabled. Worst of it all, it’s also one of the slowest too.

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

#288

Post by mats852 »

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.

https://github.com/bflattened/bflat

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

#289

Post by jayd16 »

0cf8612b2e1e wrote: post #254
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?

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?

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

#290

Post by nrr »

mapcars wrote: post #151
conor- wrote: 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?

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 synthesize solutions to toy problems in a very tightly constrained window of time, particularly if the recruiter makes me commit at the outset to one language over another as part of the overall interview process. It's frustrating for me, and, having been on the other side, it's noisy for the interviewer.

(In fact, my favorite interview loop of all time required that I use gdb to dig into a diabolical system that was crashing, along with some serious code spelunking. The rationale was that, if I'm good with a debugger and adept at reading the source that's in front of me, the final third of synthesizing code solutions to problems and conforming to institutional practice can be dealt with once I'm in the door.)

Post reply on HN