Safety is hardly a trend is it? GC'ing everything makes safety rather much easier. Go doesn't go beyond Java level safety or really any of many earlier "managed" languages. Does Go offer safety above, say, PHP?
Rust not only does all that, it provides data race safety, and does so without a runtime or tracing garbage collector or real performance sacrifices. All while maintaining C linkage for zero cost interop. I can use Rust basically anywhere I could use C, Go, not so much.
That seems to put it squarely in a different segment than Go.
> Go doesn't go beyond Java level safety
Go doesn't reach Java level safety because of a lack of generics.
Well it's still memory safe though, right? You'll just get a runtime error, not memory corruption.
Mostly. Java puts a lock on every single object in a multithreaded context; Go doesn't do this as a performance tradeoff, so two goroutines manipulating a pointer simultaneously will likely corrupt it. FWIW, I've been using Go for 4 years and I've not yet seen a memory corruption.
> we'll see other new languages making the same choices?
We are already seeing that, .NET and Java are finally paying more attention to the AOT story on their standard toolchains.
And we also have Objective-C and Swift on iDevices.
- Both compile to native code.
- Both care a lot about performance.
- Both care a lot about parallelism.
- Both care a lot about safety.
- Both were invented by a major browser vendor, roughly around the same time.
- Both include an unsafe fun zone that lets you play with raw pointers.
Maybe some of that was inevitable just by following the trends in the field (safety and parallelism in particular), and we'll see other new languages making the same choices?