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

241–250 of 816 posts

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

#241

Post by SatvikBeri »

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…

We switched from Python to Julia for numeric code. It's generally much faster (and easier to optimize), and has slightly better syntax for mathy code.

It's worth noting that Julia is very similar to go, despite superficial differences. They're both small languages with big libraries, use the same concurrency model, use a mark-and-sweep GC with an emphasis on making it easy for the programmer to reduce garbage/allocations, and both use structs + functions rather than classes.

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

#242

Post by duskwuff »

hughesjj wrote: post #212
lantry wrote: post #129

Earlier quoted context omitted.

IME, there are two main differences between go and java: 1) go is more "batteries included". Modules, linting, testing, and much more are all part of the standard cli. Also, the go stdlib has a ton of stuff; in java, there is almost always a well-built third party library, but that requires you to find and learn more things instead of just reaching for stdlib every time. 2) golang is "newer" and "more refined". this…

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

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

#243

Post by erik_seaberg »

Cthulhu_ wrote: post #81
fifilura wrote: post #71

Where I feel go is lacking is for data wrangling. Group by, filter, map, join. It is just very error prone, inconvenient and slow to implement with for loops.

Go does support functional programming constructs (as it has first-class functions) and there are some FP libraries out there, but they are discouraged because the execution is so much slower; Go is not optimized for FP, and chooses "clumsy" for loops over clever functional programming because the loops have mechanical sympathy and are simply faster in execution speed. That said, if you have a use case with a lot of…

Mechanical sympathy now favors SIMD instructions and hyperthreads because sequential loops are slower even unrolled.

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

#244

Post by dilyevsky »

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…

Numerical programs seems like a great fit for DSLs, say Starlark[0] ;-) That's what many C++ libs basically achieve with their heavy use of overloading, tmp, etc

[0] - https://github.com/google/starlark-go or alternatively https://github.com/facebook/starlark-rust

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

#245

Post by beepbooptheory »

I know its great and powerful but Go was always the "Google language" to me and as an unsufferable hipster that just turned me off to ever touch it.

I want all the things I spend my years studying to be built by committee or otherwise brief specimens of creative genius. Anything else makes me feel like I'm just learning Marvel lore.

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

#246

Post by jagged-chisel »

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?

Yes. Because "things are simpler without it." Presumably "simpler" from the point of view of the language implementer as opposed to the user of the language.

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

#247

Post by ljm »

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…

You might like Zig too. The C interop is amazing. Last time I checked you could use Zig to just compile C straight up.

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

#248

Post by etse »

busterarm wrote: post #166
tail_exchange wrote: post #85

Earlier quoted context omitted.

Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.

Go was designed for use in enterprise environments. It was literally designed for Google's specific development problems. Nothing about Go's design should be talked about divorced from the context of it being tailor-built to solve Google-specific problems. All other uses of Golang are basically in the territory of rounding error.

The opposite seems true (regarding Go being over-fitted to Google problems).

It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat.

Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does.

I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.

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

#249

Post by halfcat »

maccard wrote: post #127
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…

I would rather go had real enums, and I would _prefer_ if there were sum types. I agree it's more verbose, but I don't find that that verbosity really bothers me most of the time. Is res= [x for x in foo if "banned" in x] really actually more readable than var result []string for _, x := range foo { if strings.Contains(x, "banned") { result = append(result, x) } } ? I know it's 6 lines vs 1, but in practice I look at…

”Is really actually more readable than ?”

I mean, I mostly work in Python, but, yes absolutely.

There’s something to be said for locality of behavior. If I can see 6x as many lines at once that’s worth a lot in my experience.

This becomes blatantly apparent in other languages where we need 10 files open just to understand the code path of some inheritance hierarchy. And it’s not nearly that extreme in go, but the principle is the same.

But there is something to be said for the one way to do it, and not overthinking it.

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

#250

Post by dudeinjapan »

hello_computer wrote: post #237
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…

Something like Elixir's function composition operator (->) would go a long way toward smoothing that out, but they rejected that as well. I think the best we can do at the moment is runtime expression evaluation with something like this: https://github.com/expr-lang/expr or this: https://github.com/Knetic/govaluate

Elixir's function composition operator is |>
Post reply on HN