Unions can be used as a somewhat safer (not safe by any means but safer), more flexible, and less error-prone form of transmute. Notably you can use unions to transmute between a large type and a smaller type.
That is essentially the motivation, primarily in the context of FFI where matching C's union behaviour using transmute is tricky and error-prone.
There are rare cases where all attributes of the C union are valid at the same time. Say you have a 32-bit RGBA color value and you want to access the individual 8 bit values. You can make a union of an 32 bit int and a struct that contains 4x 8 bit integers.
Also you can manually tag them and get s.th. more like other high level languages. It will just look ugly.
I assume it's anthropic rejecting the US Government's use of their software for domestic mass surveillance or fully autonomous weapons, and openai happily agreeing to it.
That has led to a significant number of people switching over from openai, or at least stating they were going to do so.
> Yes, it's also a systems language without a runtime. But that's not the novel part.
Low level strong correctness was absolutely a novel part. In fact it’s exactly why many people glommed onto early rust, and why it was lowered on the stack.
Although learnability and weirdness budgets were also extremely novel in low level contexts which had been subsumed by C and C++.
> horrors in C++
Yes, horrors in C++. Half baked jerry-rigged and barely usable nonsense. Not an industrial strength langage with a reliable type system and a strong focus on safety through types.
50 years of computing have proved pretty conclusively that less than that is wishful thinking at best. Large C++ programs, even with massive amounts of resources and tooling, can’t even get memory management correct.
> I imagine Rust has features which can not be translated into Go's assembly
Why would there be? Go’s assembly might be lacking ways to make them optimally efficient, but that’s probably a given either way without an optimizing compiler backend.
2018 (tham luang cave rescue) is when the cracks really started showing up, so the trajectory was probably set a while earlier.
The tendency was probably always there given the serial lying about self driving started circa 2015, or the weird ego trip of ousting the founders and getting himself called co-founder, but if we’re looking for a point event the removal of his long time PA in 2014 still stands out to me.
Right. This is so often the excuse for terrible designs in C and C++. It's wrong, "But it's faster". No, it's just wrong, only for correct answers does it matter whether you were faster. If just any answer was fine there's no need to write any of this software.
As long as you clearly document that the incoming data is going to be modified, it's not a problem. And in a lot of cases, the data either comes from the network or is read from the file - so the buffer is going to be discarded at the end anyway... why not reuse it?
And yes, today it would be easier to make a copy of the data... but remember we are talking about 90's, where RAM is measured in megabytes and your L1 cache may be only 8KB or so.
That is essentially the motivation, primarily in the context of FFI where matching C's union behaviour using transmute is tricky and error-prone.
reply