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

Go runtime: 4 years later

go.dev

Post reply on HN
Print view View original

81–90 of 296 posts

Re: Go runtime: 4 years later

#81

Post by coder543 »

nu11ptr wrote: post #33
akira2501 wrote: post #32

Earlier quoted context omitted.

I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task. I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow. It essentially has no enums. However, it has a comfortable type system that can wrap prim…

I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point o…

> I do wonder how many people who understand Go's limitations (and work around them as you point out above) have truly given Rust a try (takes a few months - can't be done faster)

I have written both languages professionally in various contexts for years. In point of fact, I've been writing Rust since before Rust 1.0 came out, although I didn't get my first Rust job until about 3 years later. They're both excellent languages. I actually didn't learn Go until several years after learning Rust, and at the time I didn't appreciate it like I should have, since I was so excited about Rust. Only after getting professional experience with Rust did I truly begin to appreciate how nice Go is for the things it is good at.

Go is just so much better suited for network-connected services (including but not limited to web backends), and Rust is better suited for batch processing or embedded contexts where no compromise on performance can be made, in my experience. There are lots of reasons for this, but it's off topic from the question, and the answer to the question is that I absolutely do go back to Go. Neither language is a perfect tool for all problems, and I constantly dream about building my own language that learns from the best of both... there is certainly room for improvement on both ends.

Re: Go runtime: 4 years later

#82

Post by vore »

ck45 wrote: post #6
cmrdporcupine wrote: post #5

Earlier quoted context omitted.

I don't like Go, but I think I would use that. But I'm ignorant: is the Go runtime built in any way to accomodate third party languages? Apart from writing an interepreter in Go, is there a good way to target it?

This is just an assumption, but it might be possible to translate to Go assembly and then use the Go toolchain. Edit: https://github.com/minio/c2goasm seems to slightly go in that direction.

Go assembly is just a slightly funny version of the target platform's assembly. At that point, you might as well just assemble for the target directly and avoid the quirks of Go's assembler.

Re: Go runtime: 4 years later

#84

Post by yawn »

steveklabnik wrote: post #54
ikiris wrote: post #45

Earlier quoted context omitted.

The problem with rust is explicitly that cognitive load in large codebases. It is much easier to read go code than rust when working on many things. Rust fits great if you don't scale though.

It’s funny how experiences differ; I can’t comment on how Go fares here, but if anything, I find that the compiler takes such a mental load off of my shoulders that Rust is the language I find easiest to make large refactorings in.

It's not about refactoring for me. It's about trying to grok what the heck some library author or coworker was thinking when they went all Architecture Astronaut with the type system and traits. It reminds me of how people go crazy with OO and end up with delegation spread across several files. I already have to hold the problem in my head. I find that Go takes such a mental load off my shoulders that I find it the easiest to grok other's intentions (including my own several months/years later) in.

Re: Go runtime: 4 years later

#85

Post by Gigachad »

nu11ptr wrote: post #29

I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…

Rust has set the bar so high that it’s going to be hard for other languages to justify their use.

If I had to make a bet, I’d say Typescript will take over for everything not performance critical and Rust will fit in every spot that either requires high quality assurance or high performance.

Re: Go runtime: 4 years later

#86

Post by zarzavat »

steveklabnik wrote: post #54
ikiris wrote: post #45

Earlier quoted context omitted.

The problem with rust is explicitly that cognitive load in large codebases. It is much easier to read go code than rust when working on many things. Rust fits great if you don't scale though.

It’s funny how experiences differ; I can’t comment on how Go fares here, but if anything, I find that the compiler takes such a mental load off of my shoulders that Rust is the language I find easiest to make large refactorings in.

The differentiating factor is probably prior exposure to C++. If you have used C++ then Rust is so easy and convenient and fun. It takes hideous C++ monstrosities and turns them into easy one liners.

If you have never used C++ and your baseline is Go or JavaScript then it probably looks like a confusing hellscape. You have to learn a whole new kind of type system, a new nomenclature (“Vec”s instead of “Array”s), new concepts like allocators, plus the borrow checker and lifetime annotations, and module/crate system. Former C++ programmers only have to learn the latter half.

Re: Go runtime: 4 years later

#87

Post by Klonoar »

qaq wrote: post #79
nu11ptr wrote: post #33

Earlier quoted context omitted.

I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point o…

Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.

>Also Go is much easier to read vs Rust.

This is subjective - I for example have no real issues reading Rust code, but find Go to look like utter spaghetti on the screen.

Re: Go runtime: 4 years later

#88

Post by rob74 »

Karrot_Kream wrote: post #63
danielheath wrote: post #60

Earlier quoted context omitted.

I don't like _writing_ go, but I also don't hate reading & _debugging_ it. I love writing lisp, but I hate reading & debugging lisp.

Lisp as practiced nowadays is mostly found in small teams with low turnover. As such, features of the language that necessarily have to scale with larger team sizes and turnover rates are probably just not that important to its current user base. There's a Go code base that a friend and I first wrote 5 years ago and we incrementally update it as we find small bugs because of a system it interacts with that changes. W…

Yup, that's the tradeoff that most people somehow don't get: Go is maybe a bit more awkward and verbose to write than other languages, but it's much easier to read and refactor. My work with Go is (unfortunately) mostly private side projects which I sometimes have to leave for months, so I already learned to appreciate this years ago. Plus I also programmed in Delphi for years, so maybe some of the Pascal-inspired features of Go that programmers accustomed only to C-family languages find alien seem familiar to me.

Re: Go runtime: 4 years later

#89

Post by Klonoar »

zarzavat wrote: post #86
steveklabnik wrote: post #54

Earlier quoted context omitted.

It’s funny how experiences differ; I can’t comment on how Go fares here, but if anything, I find that the compiler takes such a mental load off of my shoulders that Rust is the language I find easiest to make large refactorings in.

The differentiating factor is probably prior exposure to C++. If you have used C++ then Rust is so easy and convenient and fun. It takes hideous C++ monstrosities and turns them into easy one liners. If you have never used C++ and your baseline is Go or JavaScript then it probably looks like a confusing hellscape. You have to learn a whole new kind of type system, a new nomenclature (“Vec”s instead of “Array”s), new…

>If you have never used C++ and your baseline is Go or JavaScript then it probably looks like a confusing hellscape.

I'm not sure this is accurate - have you seen modern TypeScript? I actually find that more confusing than Rust to read.

(FWIW, I was predominantly Python/JS-centric before just going "all in" on Rust. It's not that bad, in my experience - if anything, I find Rust "just works" whereas I got tired of the churn in those environments)

Re: Go runtime: 4 years later

#90

Post by geenat »

Love go as a platform.. self contained binaries have been a miracle for ops..but have a few big hangups about using the language full time because of the sucky ergonomics.

* No optional/named parameters. Writing a whole function per parameter for function chaining is excessive. This would not be difficult to add to the compiler (i've done it and have seriously considered using the fork) but it seems like the team is just stubborn about adding stuff like this.

* No default struct values. 0 isn't good enough in real world scenarios.. have fun writing BlahInit(...) for everything.

* Would be nice to get the question mark syntax for error handling. Error handling shorthand for if err != nil would also be very welcome.

Post reply on HN