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

21–30 of 280 posts

Re: Go's Sweet 16

#21

Post by morshu9001 »

Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

Language can be bottleneck if there's something huge missing from it that you need, like how many of them didn't have first class support for cooperative multitasking, or maybe you need it to be compiled, or not compiled, or GC vs no GC. Go started out with solid greenthreading, while afaik no major lang/runtime had something comparable at the time (Java now does supposedly).

The thing people tend to overvalue is the little syntax differences, like how Scala wanted to be a nicer Java, or even ObjC vs Swift before the latter got async/await.

Re: Go's Sweet 16

#22

Post by neonsunset »

Xeoncross wrote: post #15
klodolph wrote: post #12

Earlier quoted context omitted.

> I don't see it. Can you say what 80% you feel like you're getting? I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits. I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performan…

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

[dead]

Re: Go's Sweet 16

#23

Post by roncesvalles »

Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

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 "partial method" or "generic delegate" means, and then keep reading that codebase if you still have momentum left.

Re: Go's Sweet 16

#24

Post by morshu9001 »

roncesvalles wrote: post #23
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

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…

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

Re: Go's Sweet 16

#25

Post by jchw »

morshu9001 wrote: post #24
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…

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

Just so we're on the same page, this is the current JS spec:

https://262.ecma-international.org/16.0/index.html

I don't agree. (And frankly don't like using JS without at least TypeScript.)

Re: Go's Sweet 16

#26

Post by echelon »

Xeoncross wrote: post #15
klodolph wrote: post #12

Earlier quoted context omitted.

> I don't see it. Can you say what 80% you feel like you're getting? I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits. I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performan…

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs.

I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust.

The language has very intentional design around error handling: Result, Option, match, if let, functional predicates, mapping, `?`, etc.

Go, on the other hand, has nil and extremely exhausting boilerplate error checking.

Honestly, Go has been one of my worst languages outside of Python, Ruby, and JavaScript for error introduction. It's a total pain in the ass to handle errors and exceptional behavior. And this leads to making mistakes and stupid gotchas.

I'm so glad newer languages are picking up on and copying Rust's design choices from day one. It's a godsend to be done with null and exceptions.

I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile like Go, but designed in a safe way like Rust. I need it for my smaller tasks and scripting. Swift is kind of nice, but it's too Apple centric and hard to use outside of Apple platforms.

I'm honestly totally content to keep using Rust in a wife variety of problem domains. It's an S-tier language.

Re: Go's Sweet 16

#27

Post by nine_k »

echelon wrote: post #26
Xeoncross wrote: post #15

Earlier quoted context omitted.

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result , Option , match, if let, functio…

> I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile

It could as well be Haskell :) Only partly a joke: https://zignar.net/2021/07/09/why-haskell-became-my-favorite...

Re: Go's Sweet 16

#28

Post by Xeoncross »

echelon wrote: post #26
Xeoncross wrote: post #15

Earlier quoted context omitted.

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result , Option , match, if let, functio…

I agree with a lot of what you said. I'm hoping Rust will warm on me as I improve in it. I hate nil/null.

> Go... extremely exhausting boilerplate error checking

This actually isn't correct. That's because Go is the only language that makes you think about errors at every step. If you just ignored them and passed them up like exceptions or maybe you're basically just exchanging handling errors for assuming the whole thing pass/fail.

If you you write actual error checking like Go in Rust (or Java, or any other language) then Go is often less noisy.

It's just two very different approaches to error handling that the dev community is split on. Here's a pretty good explanation from a rust dev: https://www.youtube.com/watch?v=YZhwOWvoR3I

Re: Go's Sweet 16

#29

Post by alexjplant »

morshu9001 wrote: post #24
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…

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

ECMAScript is an order of magnitude more complicated than Go by virtually every measure - length of language spec, ease of parsing, number of context-sensitive keywords and operators, etc.

Re: Go's Sweet 16

#30

Post by woodruffw »

morshu9001 wrote: post #24
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…

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

I think JS is notoriously complicated: the phrase “the good parts” has broad recognition among programmers.
Post reply on HN