Seven years of Go

I've taken a very similar path recently myself and started looking into Rust.

> 2. Proper error handling. I love error checking

Hugely agree here. I can get behind Go's overall mentality of returning errors instead of throwing exceptions, but in my mind there are not enough primitives in the language to keep this style of coding safe and sustainable.

Rust's `Result` type, `try!` macro, and pattern matching are an incredibly powerful combination, and make Go's approach look downright medieval in comparison.

Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry).

One of my biggest complaints about ORMs is that I often know the exact query I need to write, and it is a pain to compose it with the ORM. Simple CRUD, sure, maybe. Beyond that though... Arguably one of the biggest benefits of an ORM is sanitization. You get that for free with Go. I've done quite a bit of work with DBs and Go, and I've not seen the need for an ORM, just some library helpers.

A lot of this comment resonates with my experience and views :)

> You'll note that i didn't list Generics. I know that's high on peoples list, but not mine

This is me too.

Been programming in Rust for 3 years, and picked up Go two years ago. I like the language; I like how it feels like "C but safety net". I haven't used it for anything important (course projects a bit), but this is because so far Rust works for almost all my needs and for everything else I use Python. But I'd be happy to use Go if someone asked me to or there was a reason why Python wasn't suitable.

However, generics aren't what I want in Go. I get that a language without generics can get complex and perhaps slow to compile and has other issues too. On the other hand, enums are on the top of the list for me. Especially for the message-passing programs I tend to write in Go. There have been times when I've hacked together an enum system using interfaces and hidden methods but its not great. I've grown to get used to error handling, but I do think it can be improved a lot. Package management was a major gripe of mine but it seems like y'all are fixing that :D

I have not written production software in Go so panic-proof channels haven't been on my radar but yeah, that one makes sense.

> didn't want to make a choice that would cause them to spend weeks/months feeling unproductive.

+1 I have often recommended Go to people who don't have time but want to learn something new. If you want to actually spend time writing software from scratch in week 1 of learning the language, Go is amazing. I recommend Rust often too, but I usually find out how much time they have and/or their background first.

> Rust gives me a peace of mind that Go never came close to.

Again, big +1. For me it is two effects -- one is that Rust feels safer, and the other is that as a Rustacean Go feels wasteful at times. After programming in Rust for that long, losing performance at any corner for no reason irks me. In Rust, for example, most folks will avoid reference counting and trait objects and heap allocation as much as possible. If you see an unnecessary trait object it _feels wrong_. This is a perfectly sensible attitude to have in Rust. For me, it often carries on into Go. But Go loves interfaces and has garbage collection (with good escape analysis, but a GC nevertheless). Every time I use an interface object in Go, it _feels wrong_. It shouldn't. And I've learned to ignore it -- if I'm writing an application in Go; perf probably didn't matter enough for this to matter. (In fact, the odd unnecessary trait object in a typical Rust lib is usually no big deal either.). But, that nagging feeling is still there :)

My 2c: Go is incredibly convenient for non-programmers. I don't make a living writing software, I make a living answering quantitative questions, using computers. I use Python for most tasks, but when I need extra performance and/or portability, I grab Go every single time.

The main appeal is the quality standard library that covers most things I get in contact with. I could get immersed in it right away, because I didn't spend weeks trying to read the spec - the spec itself is so trivial it's mindblowing. The standard library feels very Pythonic in terms of reach. I've built tiny servers, parsed plethora of file formats, calculated maths, wrote data, (de)compressed stuff, encrypted things, ... The joy of not having to worry about 3rd party dependencies for all these is quite refreshing. And the appeal of few runtime issues thanks to static compilation is oh so excellent.

Sure, Go didn't invent any of these practices and sure, it doesn't have generics, runtime assembly, it's opinionated in a few places, its vendoring is subpar, ... But when you're someone who isn't really a programmer, these things don't matter much. I'm not here for the hype, I'm here for the productivity and ease of use.

> Granted, i left out nil pointer/interface panics because it seems unrealistic given how difficult it was for Rust to get rid of nil pointers.

That wasn't really a difficult part, it's just a basic application of generic enums.

Now Go doesn't have (userland) generics or enums, but they could have taken the same path as other languages (and the one Go is wont to take): special-case it. Which they probably can't anymore because of zero-valuing, you can't have a zero value for non-null pointers.