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…
Better enums and non-nil types, that would be my wish list for Go. And conditional expressions, if there's one more wish to be granted. There's no need to make it resemble Rust: Go's type system is expressive enough as it is.
> has error prone C-style 'for'
Not really true. It has `for index, elt := range v` to iterate over arrays and maps. It's a pity you can't define your own range, that's true.
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…
Better enums and non-nil types, that would be my wish list for Go. And conditional expressions, if there's one more wish to be granted. There's no need to make it resemble Rust: Go's type system is expressive enough as it is. > has error prone C-style 'for' Not really true. It has `for index, elt := range v` to iterate over arrays and maps. It's a pity you can't define your own range, that's true.
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…
Two comments: There are two reasons to have match: exhaustiveness and destructuring/pattern matching. I don't think there's an if/else parallel to `match result { Ok(t) => { ... }, Err(e) => { ... } }` The fact that a `nil` value can be made useful (which, AFAICT, means it won't blow up your program?) is not a good enough reason to include them in the language. Rust can do perfectly useful things with, say, `Option >…
The problem isn't null/nil as such, it's when the type system treats null values as legal at compile-time.
But if you look at e.g. Kotlin, or C# with "#nullable enable", it tracks whether a given reference can be null or not. So you write if-else code instead of match, but you have to do that in order to actually do something with a reference.
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 have a similar experience. Used to write a lot of golang, and now I write a lot of Rust. I think I would have pointed out the same issues: auditing Golang network code you can often find easy DoS attacks due to nil values being dereferences (protobuf I’m looking at you), there’s no sum types or enums, etc. Still though, I miss how easy it is to read golang and ramp up on a codebase. Even today I sometimes come across a golang codebase and look for something and I can always easily follow the code. Eventhough I’ve written a lot of Rust, it’s always challenging to ramp up on a Rust codebase, and the language is often abused because it’s too expressive. I’d still say Rust is so much more pleasant to write due to that expressiveness. It really is a double edge sword.
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.
> Async code is way nicer in Go than it is in Rust.
That’s because Go does not have async code. It has sync code on an async runtime. Like e.g. Erlang/Elixir.
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…
> In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. OCaml kind of gives you that, but the dev experience isn't as good as Rust or Go in my opinion. Still, I enjoy it a lot, more than Go or Rust.
Rust is basically what you get if you start with OCaml, remove the GC, and add enough features to the type system to compensate for that without giving up on safety.
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) This is basically the "Anyone who doesn't love my favorite movie hasn't watched it enough times" argument. Programming language design is a complex space, there are no "correct" opinions.
I tend to agree with his argument though, I can see how a lot of Golang developers would really benefit and enjoy migrating (I’m one of them) but I think it also depends on the type of applications that you usually write.
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.
That’s probably because you’re not used to it. I think it’s common knowledge that Golang is easy to read.
Plugins for ELF- and Mach-O-based systems aren't any different than regular shared libraries, modulo slightly different symbol precedence. AFAIU, while a quite different architecture, Windows PE linking treats them quite similarly, too. Perhaps you meant statically compiled binaries? Even then I'm not so sure about that. Right now I'm working on a project that statically compiles a plugin so its various libraries can…
Beyond linking it is also a problem with ABI compatibility of object layouts, etc. It is so much simpler with more dynamic languages.
The C ABI on pretty much any platform defines object layout for structs, which is usually good enough.
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…
I hate C++ but got used to Rust. It just has a steep learning curve unlike Golang. Takes a while but when you get there it is really pleasant.
On the other hand Golang can be fun in like a week of learning it.