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.
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
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.
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.
Plenty of recent languages have fixed this problem - like zig, Swift, kotlin, rust and typescript. Go is behind the curve.
It’ll never happen, but I wish rust added this kind of sugar on top of Option.
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.
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.
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.
Linux beat Windows, PostgreSQL beat MySQL.
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.
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.