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

171–180 of 280 posts

Re: Go's Sweet 16

#171

Post by treis »

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…

The tradeoff with that language simplicity is that there's a whole lot of gotchas that come with Go. It makes things look simpler than they actually are.

Re: Go's Sweet 16

#172

Post by Thorrez »

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…

Go is getting more complex over time though. E.g. generics.

Re: Go's Sweet 16

#173

Post by liveoneggs »

liampulles wrote: post #133

I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily. This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin…

I don't understand how this isn't also true for practically every other language?

Re: Go's Sweet 16

#174

Post by liveoneggs »

alexjplant wrote: post #29
morshu9001 wrote: post #24

Earlier quoted context omitted.

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.

strict mode makes it okay

Re: Go's Sweet 16

#175

Post by Too »

dmoy wrote: post #127
Mawr wrote: post #105

Earlier quoted context omitted.

Yeah, but just going back to warnings would be a regression. I believe the correct approach is to offer two build modes: release and debug. Debug compiles super fast and allows unused variables etc, but the resulting binary runs super slowly, maybe with extra safety checks too, like the race detector. Release is the default, is strict and runs fast. That way you can mess about in development all you want, but need to…

> Debug compiles super fast and allows unused variables etc, but the resulting binary runs super slowly, maybe with extra safety checks too, like the race detector. At least in the golang / unused-vars at Google case, allowing unused vars is explicitly one of the things that makes compilation slower. In that case it's not "faster compilation as in less optimization". It's "faster compilation as in don't have to chase…

Accidentally pulling in a unused dependency during development is, if not a purely hypothetical scenario, at least an extreme edge case. During debug, most of the times you already built those 5000000000 lines while trying to reproduce a problem on the original version of the code. Since that didn’t help, you now want to try commenting out one function call. Beep! Unused var.

Re: Go's Sweet 16

#176

Post by vlovich123 »

liveoneggs wrote: post #173
liampulles wrote: post #133

I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily. This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin…

I don't understand how this isn't also true for practically every other language?

It’s not true of C/C++ which need changes to the build system. Also true for rust workspaces which is how I’d recommend structuring monorepos although it is generally easy (you just need to add a small cargo.toml file) or you can not use a workspace but you still need to declare the binary if I recall correctly.

Re: Go's Sweet 16

#177

Post by Xeoncross »

vips7L wrote: post #63
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…

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 my production Java systems easily use 8x more memory and still barely match the performance of my Go systems.

Re: Go's Sweet 16

#178

Post by [deleted] »

EnergyAmy wrote: post #147
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.

I like the language saying "it's not as easy as you think" when I'm about to do something ill-advised like roll my own mutable tree structure.

[deleted]

Re: Go's Sweet 16

#179

Post by tptacek »

EnergyAmy wrote: post #147
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.

I like the language saying "it's not as easy as you think" when I'm about to do something ill-advised like roll my own mutable tree structure.

You understand that tree structures aren't just lookup tables, right? I wouldn't roll my own red-black tree (Jesus how tedious would that be). That's not what I'm talking about.

Re: Go's Sweet 16

#180

Post by anal_reactor »

ModernMech wrote: post #51

Oh wow, so it's already been 16 years since Google steamrolled the Go! language, which had existed a decade before Go and had every right to the name. This was when they were still pretending "do no evil" was their brand. There may be no honor amongst thieves but there is honor amongst langdevs, and when they did Go! dirty, Google made clear which one they are. Status changed to Unfortunate https://github.com/golang/…

Go! was clearly a toy language created only for the purpose of writing papers. It has no applications outside academia. Meanwhile Google's golang exists mostly in the sphere of practical use.
Post reply on HN