Rust vs. Go: Battle for the Back End
effective-programmer.com
effective-programmer.com
For high performance, the answer is C, C++, Zig or Rust.
For backend it can be Go, it can be Java, it can be C#, it can be Python or Javascript.
C# is on par performance wise with Go and I suspect the same for Java.
Choosing a language for something has to be done by considering trade offs, benefits and disadvantages, on both long and short term.
Rust would fit system programming while Go will fit the backend. I know "the right tool for the job" is very often mentioned but I will mention it again.
For backend I would be interested in a functional language, be it F#, OCaml, Elixir or Clojure, because I grew tired of OOP, SOLID, design patterns, clean coding, kingdom of nouns and Uncle Bob. All things, I used long ago to believe in. But since no one is hiring functional programming and I don't have the resources to be the sole owner and developer of a startup, I am stuck in kingdom of nouns.
If top raw performance was so important in the backend, people would have used C++ long before Rust became popular.
Now you might have a rare use case where raw performance is important, but in that case you write that part in a low level language and the rest of the microservices in a more productive one.
Linux beat Windows, PostgreSQL beat MySQL.
It actually doesn't. Languages like Kotlin, C# and TypeScript special case null in the type system and allow you to specify whether or not a given type should include null or not.
It’ll never happen, but I wish rust added this kind of sugar on top of Option.
There are language decisions other than options that can work, but they boil down to the same thing: force a branch before use. If go does not have this sort of secondary type system now, it won't be too long before someone sees the value.
Python these days has Optional[str] = str | None.
Both are in the alternative.
Dart hides optional as ?
You can achieve the same thing as optional types in Go using ‘…any’ and the standard library has made use of that pattern since the very first release of Go.
Nil pointers in Go are a completely different problem and there isn’t really a direct comparison in dynamic languages like Python nor Typescript because they use references rather than pointers.
Where “references” differ is you have to initialise the type to get a reference. In Python and Typescript, you don’t create naked pointers. You create structs then pass that reference in functions.
The problem with Go is that you can create those naked pointers and then you need to remember to create your struct and then point that pointer to the struct. And you’re sometimes you’re incentivised to write code this way because Gos garbage collector needs to do more work than if you create pointers adhoc after (like references). But you can use pointers like references if you wanted too.
So there isn’t really a direct comparison with languages like Python and Typescript because they don’t have the same primitive to begin with.
There are benefits to Gos approach: you get more control over memory usage as well as improved performance. But like any idiom, it comes with disadvantages too. And the reason Go panics is because the alternative is the risk of silent memory corruption, which is what a lot of other languages can suffer from with pointers. Though this isnt to say that there are also languages that do solve this problem in a much better way too. But they’re are also a completely different language to Python and Typescript again too.
So the comparisons to Python and Typescript simply don’t work for this type of problem.
function useFoo(f: Foo) { f.Use() }
var foo: Foo
useFoo(foo)
func useFoo(f *Foo) { f.Use() }
var foo *Foo
useFoo(foo)
A better example will be:
foo := Foo{}
useFoo(&foo)
Nil pointer bugs happen when you need to use pointers as pointers. (Shock horror!) And sometimes you do need a pointer with no object attached when solving specific problems are aren’t well suited for Typescript.
Python and Typescript doesn’t have pointers. Those languages made different trade offs so they lose performance and memory management controls as a result.
It’s no secret that Python needs to call FFIs to (for example) C++ code when performance and memory management concerns arise. Likewise with node too. In fact I’m in the process of debugging a 3rd party Rust library for Node that’s not handling pointers correctly and thus causing sporadic crashes of the node runtime. And that Rust library only exists in the first place because JavaScript doesn’t have primitives to write the required code natively in node at the performance required for scale.
Maybe WASM will be the saviour here. But it feels like we are now just piling on more abstractions between the code and CPU rather than trying to learn how to use our existing set of tools better.
That said, Im sure there are better ways of handling undefined types in Typescript than I was doing. I’m certainly not an expect in Javascript nor Typescript. Though a large part of that reason is because there are far far far too many design choices in those languages that really rub me the wrong way, so I usually limit my Javascript/Typescript usage the bare minimum I can get away with.
That all said, I will say I found Typescript to be a massive improvement over vanilla Javascript. It’s a pity we can’t just do away with JS completely and have TS run everywhere instead.
the optional static type checking in python gives you a stronger typing than what golang does because you don't have to type everything as (None | Foo) and presumably its a type error to perform Foo operations on a (None | Foo) type.
Of courses there’s pointers under the hood. It’s a runtime built in C++.
But that doesn’t mean that Python -the language not the runtime- has pointers itself.
> the optional static type checking in python gives you a stronger typing than what golang does
“Stronger” isn’t the term you’d want to use there. Python is not more strongly typed than Go just by virtue of it being more a dynamic language.
I do agree that the Go type system is pretty inflexible though.
Plenty of recent languages have fixed this problem - like zig, Swift, kotlin, rust and typescript. Go is behind the curve.
Ocaml's `None | Some of int` has the same basic meaning as TypeScript's `number | undefined`
Go data types cannot be null but a pointer to a data type can be. And what a nil pointers is, is a valid type of pointer but which points to an invalid point or memory.
Typescript doesn’t have the same problem because it doesn’t have pointers.
Rust somewhat this problem with its borrow checker but it’s still entirely possible to create a nil pointers in Rust and without using ‘unsafe’, but admittedly it’s not by writing idiomatic Rust.
Go really should do more to prevent issues here but the real problem is around the creation of “objects” (since Go isn’t fully OOP) and how you can’t really create an image struct (nor even map) and have it default as empty. I’m sure the logic behind that is for performance, but why not expose the option of an uninitialised struct pointer behind ‘unsafe’ for those who are willing to accept that risk?
This isn't true at all. C#, TypeScript and Kotlin are examples of languages where you have to explicitly opt into null.
Also it might seem weird to you given Typescript is a completely different idiom and doesn’t even have pointers to begin with.
That all said, I’m not going to defend the nil pointer problem in Go. It is something that can be largely mitigated with a few relatively small changes to the language. Though I couldn’t see them being entirely backwards compatible.
Edit, responded to pointer vs reference down thread.
I’m not disagreeing that nil pointers are an ugly sore for Go. What I’m arguing against is your claim that Go services are constantly failing in production because of that sore point.
The reason I make that argument is because:
- sore points are a problem for every programming language. designing a programming language is a constant trade off of concerns. so there will always be stuff that doesnt work well. And I know this as an author of a programming language myself.
- however if sore points prevent a language from being usable in a production context (assuming that’s its intended role), then that becomes an insurmountable problem.
Nil pointers aren’t an insurmountable problem for Go. They’re ugly and arguably a terrible design choice, but not an insurmountable problem. Which is why Go succeeds despite this sore spot.
Typescript has its own WTF moments too. Every language does.
What I claimed applied to my company, exactly as I said.
If it doesn’t apply to yours… ok? Congrats?
Looking back, maybe you didn’t understand the shell variable syntax?
type Option[Value any] struct {
value Value
exists bool
}
func (o Option[Value]) Get() (Value, bool) {
return o.value, o.exists
}
It's not without its issues though, the ecosystem does not use such a type and you need a little bit of discipline to stick with it.
But it's not that big of a deal if you're getting regular major outages...
Looking at the go ecosystem you’d think static nil traceability is some sort of Very Hard Problem…
You could also try your luck with https://github.com/uber-go/nilaway
This is posted by the author, apparently, so I hope he can clear this up.
Go gets a ton of things right for easy programming, and presents a super readable language with concurrency as a forethought.
Rust take a more conservative approach with a focus on correctness, and is the more performant language typically, for when you need it.
I don't at all see them filling the same niche, so I can't understand why this argument comes up so often.
The comparisons in this discussion with Python and Typescript are equally silly too because they’re not even strictly typed languages.
I guess some people just want to feel like their preferences are superior and discussions like these allow them to cherry pick favourable metrics which validate their opinions.
Reading the article, it looks like this article is generated by an LLM, as most things are nowadays.