Most programming languages don't have a legacy. They're just forgotten. That's the default. So far I've not seen anything from Go to make me think it will be more than a footnote.
How about Docker and other tools in the container space?
Go is a great systems language. The stdlib is through and handling IO and pipes is safe and fast.
Amazon is using as the mission critical ecs-agent that orchestrates their container service.
Perhaps containers will be forgotten too. But my guess is that we will be seeing some go binaries controlling very important parts of Linux and distributed systems in the far future.
Probably the most important feature of a systems language is the ability to predict and manage resource usage, and even though garbage collection is pretty good these days, it's still a feature that will turn a good number of people off from considering Go to be their go-to systems language. Some might not even consider it a systems language for having it, let alone a great one. It is mostly a feature of convenience, after all.
Go is problematic as a systems language. Calling it safe is odd, when it's glaringly allowed for Null. It's safe like Java is safe, which means that the memory will always be safe to use, but the program will still die due to bugs that a compiler could have helped prevent.
As a comparison Rust has no runtime, has no garbage collector, and is a pure systems language, and also helps developers be truly safe. Based on my experience with Go, I still don't understand where it fits, it's a compiled language, but has a runtime and a GC. So it's somewhere between C++ and Java, it's less verbose and faster to program in, but if that's the desire, than perhaps the better choice will be Kotlin in the long run.
> which means that the memory will always be safe to use
In another post [1], the author of the article claims that Go will not "tolerate unsafe memory access".
A reference to a variable could be sent across a channel and nil'd from the sending goroutine before being dereferenced in the recipient goroutine, causing a crash. Doesn't this invalidate the "safe memory" claims, or are concurrency-related memory issues not considered when making that claim?
Dereferencing nil is not an unsafe memory access in Go, just like a null pointer exception in Java isn't unsafe. Both are well-defined operations (sure, they yield errors, but they do so with 100% reliability and complete control), they're not undefined behaviour like in C or C++.
Unsafe memory accesses refers to things like accessing an array out-of-bounds, or reading from a pointer that has already been freed. (I suspect a data race could actually cause an array to be accessed out of bounds in Go, but I'm not sure.)
Thanks for the clarification! What if instead of the sender goroutine setting the pointer to nil, the GC frees the object that the pointer was pointing to before the recipient goroutine reads it? Wouldn't that be considered "reading from a pointer that has already been freed"?
That can't happen. The GC won't free the object until nothing references it, and in your proposed scenario either the channel or receiving goroutine will have a valid reference.
OT but my guess is that we'll move towards deploying applications as part of a unikernel instead of running them inside operating systems designed for multi-user usage. Multiple applications may be run on physical hardware using some sort of hypervisor, but I don't see the point in having all this overhead just to wall your application off of with Docker.
With that said, I do use Docker, but only because it's a step up from what I've previously used. Long term I'm looking towards deploying my applications with a unikernel.
