Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

241–250 of 280 posts

Re: Go's Sweet 16

#241

Post by nasretdinov »

zero_shift wrote: post #205
roncesvalles wrote: post #23

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

I learned Go this year, and this assertion just... isn't true? There are a bunch of subtleties and footguns, especially with concurrency. C++ is a basket case, it's not really a fair comparison.

As they (I) say, writing a concurrent Go program is easy, writing a correct one is a different story :)

Re: Go's Sweet 16

#242

Post by p2detar »

tptacek wrote: post #141
9rx wrote: post #92

Earlier quoted context omitted.

> proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly th…

I wish Go had sum types too. But I like being able to write a mutable tree structure without first having to read a whole book on the subject and inventing a new system of pointers. Every language is tradeoffs.

Yes, the language does not have ADT support, but there are projects that enable this, like https://github.com/alecthomas/go-check-sumtype.

Re: Go's Sweet 16

#243

Post by ezst »

morshu9001 wrote: post #154
ezst wrote: post #112

Earlier quoted context omitted.

I'll be the one to nickpick, but Scala never intended to be a nicer Java. It was and still is an academic exercise in compiler and language theory. Also, judging by Kotlin's decent strides, "little Syntex differences" get you a long way on a competent VM/Runtime/stdlib.

Kotlin's important feature is the cooperative multitasking. Java code has been mangled all these years to work around not having that. I don't think many would justify the switch to Kotlin otherwise.

It's probably an important feature now, but it's a recent one in this context.

Re: Go's Sweet 16

#244

Post by allovertheworld »

bayindirh wrote: post #217
duskwuff wrote: post #196

Earlier quoted context omitted.

C/C++ library dependencies are a thing, and there's no universal solution to acquiring and installing them.

The most universal thing in C/C++ is vendoring, IMHO. If you are distributing source, you distribute everything. Then, it only needs a compiler and libc. That vendored package is tested, and it works on your platform, so there's no guesswork.

Not really since those vendored libraries would have their own dependencies as well

Re: Go's Sweet 16

#245

Post by allovertheworld »

zerr wrote: post #144
tptacek wrote: post #141

Earlier quoted context omitted.

I wish Go had sum types too. But I like being able to write a mutable tree structure without first having to read a whole book on the subject and inventing a new system of pointers. Every language is tradeoffs.

As a C++ dev, such comments reinforce my hesitation to pick up either Go or Rust seriously :) It seems I already have the golden middle after all.

If only C++ had a fully supported cargo system

Re: Go's Sweet 16

#246

Post by jmaker »

culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

I used to do Go in production for several years, along with Java and TypeScript event-loop backends. It was a breeze of fresh air, especially for new projects, where the Java conventions could be put to rest. But in such an environment, with mostly Java legacy, people did tend to bend Go to the Java idioms rendering the PR reviews very cumbersome.

From what I’ve experienced, if you need any fine-grained control over your data or allocations, precision on the type level, expressing nontrivial algorithms, Go is just too clumsy.

The more I read about how people use Go today and what issues people still have, the more I’m happy I picked Rust for almost everything. I even find it much more productive to write scripts in Rust than in Python or shell script. You just get it right very quickly and you don’t need to care about the idiosyncrasies of ancient tech debt that would otherwise creep into your new projects. And of course the outcome is way more maintainable.

Not saying that Rust hadn’t had its own warts, but most of them are made explicit. This is perhaps what I appreciate the most.

Intuitively, however, I still notice myself creating a new Python or shell script file when I need something quick, but then something doesn’t really work well the moment the logic gets a bit more complex, and I need to backtrack and refactor. With Rust, this hasn’t been an issue in my experience.

And intuitively, I still tend to think in Java terms when designing. It’s funny how it sticks for so long. And when writing some Java, I miss Go’s use-site interfaces and TypeScript’s structural typing, while I miss nominal typing in TypeScript. It’s just maybe that you get used to workarounds and idiosyncrasies in some system and then carry them over to another paradigms.

I do like Go’s value propositions, and lots of its warts have been sorted out, but I’m just not as productive in it for my use cases as I am with Rust. It just checks way more boxes with me.

Re: Go's Sweet 16

#247

Post by deagle50 »

Xeoncross wrote: post #177
vips7L wrote: post #63

Earlier quoted context omitted.

Go is in the same performance profile as Java and C#. There are tons of benchmarks that support this.

1) for one-off scripts and 2) If you ignore memory. You can make about anything faster if you provide more memory to store data in more optimized formats. That doesn't make them faster. Part of the problem is that Java in the real world requires an unreasonable number of classes and 3rd party libraries. Even for basic stuff like JSON marshaling. The Java stdlib is just not very useful. Between these two points, all m…

ZGC? It should be on par or better than Go.

Re: Go's Sweet 16

#248

Post by steveklabnik »

Merovius wrote: post #236
liveoneggs wrote: post #229

Earlier quoted context omitted.

I personally like Go and appreciate its simplicity and tooling and everything but the example given is "making a folder" and "putting a ... main() func" in it. But, like, this is exactly as easy with every single other language that I can think of. The second part "Running go install at the root ./.." is actually terrible and risky but, still, trivial with make (a - literally - 50 year old program) or shell or just w…

> But, like, this is exactly as easy with every single other language that I can think of. I mean, not exactly . Rust (or rather Cargo) requires you to declare binaries in your Cargo.toml, for example. It also, AIUI, requires a specific source layout - binaries need to be named `main.rs` or be in `src/bin`. It's a lot more ceremony and it has actively annoyed me whenever I tried out Rust. > The second part "Running g…

> declare binaries in your Cargo.toml, for example. It also, AIUI, requires a specific source layout - binaries need to be named `main.rs` or be in `src/bin`.

It does not. Those are the defaults. You can configure something else if you wish. Most people just don’t bother, because there’s not really advantages to breaking with default locations 99% of the time.

Re: Go's Sweet 16

#250

Post by rcxdude »

Denzel wrote: post #61
synthetic-echo wrote: post #56

Earlier quoted context omitted.

Just an anecdote and not necessarily generalizable, but I can at least give one example: I'm in academia doing ML research where, for all intents and purposes, we work exclusively in Python. We had a massive CSV dataset which required sorting, filtering, and other data transformations. Without getting into details, we had to rerun the entire process when new data came in roughly every week. Even using every trick to…

Did you try scipy/numpy or any python library with a compiled implementation before picking up Go?

These only help if you can move the hot loop into some compiled code in those libraries. There's a lot of cases where this isn't possible and at that point there's just no way to make python fast (basically, as soon as you have a for loop in python that runs over every point in your dataset, you've lost).
Post reply on HN