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

251–260 of 280 posts

Re: Go's Sweet 16

#251

Post by rcxdude »

Measter wrote: post #83
throw1111221 wrote: post #54

Earlier quoted context omitted.

Just because it was a design goal doesn't mean it succeeded ;) From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby."…

It's interesting that I've also heard the same from people involved in Rust. Expecting more interest from C++ programmers and being surprised by the numbers of Ruby/Python programmers interested. I wonder if it's that Ruby/Python programmers were interested in using these kinds of languages but were being pushed away by C/C++.

I think on average C++ programmers are more interested in Rust than in Go. But C programmers are on average probably not interested in either. I do agree that the accessible nature of the two languages (or at least perception thereof) compared to C and C++ is probably why there's more people coming from higher-level languages interested in the benefits of static typing and better performance.

Re: Go's Sweet 16

#252

Post by ninetyninenine »

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.

Pointers are orthogonal to sum types. They are completely different things and there is literally no tradeoff for the two things you describe. So you’re not making any sense.

Re: Go's Sweet 16

#253

Post by arccy »

ModernMech wrote: post #142
arccy wrote: post #120

Earlier quoted context omitted.

Like how C and C# are different languages, Go and Go! are different. There's not name reuse here.

Go and Go! are pronounced the same way, so yes, they're the same. Moreover the author of Go! personally requested that Google not step on his life's work. The man had dedicated a decade and authored a book and several papers on the topic, so it wasn't a close call. Additionally C# built on C++ which built on C. Go had no relationship to Go! at all. Homage and extension are one thing, but Go was not that. A policy of…

They are not pronounced the same, otherwise we wouldn't have the ! in the language.

Re: Go's Sweet 16

#254

Post by grey-area »

nicodjimenez wrote: post #222
grey-area wrote: post #201

Earlier quoted context omitted.

Microservices are entirely unrelated to classes and in no way endemic to go. Go’s lack of inheritance is one of its bolder decisions and I think has been proven entirely correct in use. Instead of the incidental complexity encouraged by pointless inheritance hierarchies we go back to structure which bundle data and behaviour and can compose them instead. Favouring composition over inheritance is not a new idea nor di…

Microservices in Golang are definitely related to classes due to the ergonomic aspects of a language. It takes a lot of discipline in Golang not to end up with huge flat functions. Golang services are easier to reason about when they are small due to the lack of abstractions, also Golang is very quick to compile, so its natural to just add services to extend functionality. Code re-use is just a lot of work in Golang.…

It really doesn’t.

Structs and interfaces replace classes just fine.

Reuse is really very easy and I use it for several monoliths currently. Have you tried any of the things you’re talking about with go?

Re: Go's Sweet 16

#255

Post by ErroneousBosh »

benjiro wrote: post #224
ErroneousBosh wrote: post #186

Earlier quoted context omitted.

> This is why unused dependencies are a compile time error. I think my favourite bit of Go opinionatedness is the code formatting. K&R or GTFO. Oh you don't like your opening bracket on the same line? Tough shit, syntax error.

But it also has a advantages that you can literally read a lot of code from other devs without twisting your eyes sideways because everybody has their own style.

Exactly.

"This is Go. You write it this way. Not that way. Write it this way and everyone can understand it."

I wish I was better at writing Go, because I'm in the middle of writing a massive and complex project in Go with a lot of difficult network stuff. But you know what they say, if you want to eat a whole cow, you just have to pick and end and start eating.

Re: Go's Sweet 16

#256

Post by tptacek »

ninetyninenine wrote: post #252
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.

Pointers are orthogonal to sum types. They are completely different things and there is literally no tradeoff for the two things you describe. So you’re not making any sense.

No, you simply misread the comment.

Re: Go's Sweet 16

#257

Post by HumblyTossed »

asa400 wrote: post #39
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…

> The nice thing about Go is that you can learn "all of it" in a reasonable amount of time This always feels like one of those “taste” things that some programmers tend to like on a personal level but has almost no evidence that it leads to more real-world success vs any other language. Like, people get real work done every day at scale with C# and C++. And Java, and Ruby, and Rust, and JavaScript. And every other la…

> Like, people get real work done every day at scale with C# and C++.

That would be me. I _like_ C#, but there are elements to that language that I _never_ work with on a daily basis, it's just way too large of a language.

Go is refreshing in it's simplicity.

Re: Go's Sweet 16

#258

Post by sacado2 »

liveoneggs wrote: post #229
dlisboa wrote: post #225

Earlier quoted context omitted.

It just isn't. There's nothing stopping other languages from being that easy but very few even try. Go sees itself more as a total dev environment than just a language. There's integrated build tooling, package management, toolchain management, mono repo tools, testing, fuzzing, coverage, documentation, formatting, code analysis tools, performance tools...everything integrated in a single binary and it doesn't feel b…

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…

> "making a folder" and "putting a ... main() func" in it

You can't do that with python for instance. First, you need a python interpreter on the target machine, and on top of that you need the correct version of the interpreter. If yours is too old or not old enough, things might break. And then, you need to install all the dependencies. The correct version of each, as well. And they might not exist on your system, or conflict with some other lib you have on your target machine.

Same problem with any other interpreted language, including Java and C# obviously.

C/C++ dependency management is a nightmare too.

Rust is slightly better, but there was no production-ready rust 16 years ago (or even 10 years ago).

Re: Go's Sweet 16

#259

Post by zimpenfish »

roncesvalles wrote: post #234
zimpenfish wrote: post #143

Earlier quoted context omitted.

> I'm pretty sure that I won't do anything in a go program that would cause the other team members much trouble Alas there are plenty of people who do[0] - for some reason Go takes architecture astronaut brain and wacks it up to 11 and god help you if you have one or more of those on your team. [0] flashbacks to the interface calling an interface calling an interface calling an interface I dealt with last year - NONE…

My cardinal rule in Go is just don't use interfaces unless you really, really need to and there's no other way. If you're using interfaces you're probably up to no good and writing Java-ish code in Go. (usually the right reason to use interfaces is exportability) Yes, not even for testing. Use monkey-patching instead.

> My cardinal rule in Go is just don't use interfaces unless you really, really need to and there's no other way.

They do make some sense for swappable doodahs - like buffers / strings / filehandles you can write to - but those tend to be in the lower levels (libraries) rather than application code.

Re: Go's Sweet 16

#260

Post by neonsunset »

sacado2 wrote: post #258
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…

> "making a folder" and "putting a ... main() func" in it You can't do that with python for instance. First, you need a python interpreter on the target machine, and on top of that you need the correct version of the interpreter. If yours is too old or not old enough, things might break. And then, you need to install all the dependencies. The correct version of each, as well. And they might not exist on your system,…

[dead]
Post reply on HN