> Accept that learning Rust requires...
> Leave your hubris at home
> Declare defeat
> Resistance is futile. The longer you refuse to learn, the longer you will suffer
> Forget what you think you knew...
Now it finally clicked to me that Orwell's telescreen OS was written in Rust
Says who? Programming languages come in all shapes and sizes, and each has their tradeoffs. Rust's tradeoff is that the compiler is very opinionated about what constitutes a valid program. But in turn it provides comparable performance to C/C++ without many of the same bugs/security vulnerabilities.
In JavaScript you can declare a variable, set it to 5 (number), and then set it to the "hello" (string), but that's not allowed in e.g. C. Is C constricting me too much because I have to do it in C's way?
Placing restrictions on the programs a programmer can write is not abusive. The rules exist to ensure clarity, safety, performance, and design goals. In an abusive relationship, rules are created to control or punish behavior, often changing capriciously and without reason or consultation. By contrast, Rust is designed by a group of people who work together to advance the language according to a set of articulated goals. The rules are clear and do not change capriciously.
Abuse causes emotional trauma, isolation, and long-term harm. Rust may cause feelings of frustration and annoyance, it may make you a less efficient programmer, but using it does not cause psychological or physical harm found in abusive relationships.
I probably wouldn't have been able to do that with Rust if I hadn't been an Erlang person previously. Rust seems like Erlang minus the high-overhead Erlangy bits plus extreme type signatures and conscious memory-handling. Erlang where only "zero-cost abstractions" were provided by the language and the compiler always runs Dialyzer.
So the hard part isn't getting code to work, it is ensuring it is only working in the intended ways, even when your co-worker (or your future self) acts like an unhinged, unristricted idiot. And that means using enforced type systems, validation, strict rules.
If you are a beginner cobbling hobby programs an anything-goes approach to software may feel nice and like freedom, but beyond a certain level of complexity it will land you in a world of pain.
Any great C programmer whose code I ever had the pleasure of reading has a plethora of unwritten rules they enforce through their heads. And these rules exist there for a reason. When you have a language that enforces these rules for you, that gives you the freedom to dare more, not less, as certain things would be very risky with manual checking.
It is like the foam pit in extreme sports. While it is certainly more manly to break your neck in ten consecutive tripple-backflip tries, you are going to get there faster with a foam pit where you can try out things. And the foam pit transforms the whole scene, becaus people can now write code that before would crash and burn without feeling restricted. Funny how that goes.
(You could build your own custom data types that have type metadata in a shared header and an addition function that uses it, but then you're building your own custom language on top which isn't really the same thing.)
So yes C really does restrict you in some ways that Javascript doesn't.
Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.
Unions may be the better analog here.
> Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.
That's more like an implementation detail than a quality of the language itself. A JavaScript implementation might do the same. For example, values in V8 are all either pointers to the heap except in the case of small (31-bit) integers, and a less optimized implementation might not even make that distinction and allocate everything on the heap. Similarly, a Python implementation might store SMIs directly where the pointer would be, like V8. PyPy uses both tagged pointers/SMIs and may even allocate registers for values.
Tagged unions would be, except they aren't first class in C.
The best analogy here would probably be OCaml polymorphic variants (https://dev.realworldocaml.org/variants.html)
> That's more like an implementation detail than a quality of the language itself.
It is not, though, because - unlike JavaScript - the fact that everything is a reference to object, and each object has a unique identity, is explicitly a part of Python semantics, and this is very visible in many cases. It's easy to observe it for "primitive" types as well simply by inheriting from them.
(OTOH the fact that a given Python implementation might still implement this by using tagged pointers etc is an implementation detail, because it is still required to behave as-if everything was an object).
For the originally stated example, 'declare a variable, set it to 5 (number), and then set it to the "hello" (string)', a plain union is just fine.
> The best analogy here would probably be OCaml polymorphic variants
It would be, except OCaml is not C.
> It is not, though, because - unlike JavaScript - the fact that everything is a reference to object
Evidently, references and pointers are not the same thing, hence it is an implementation detail whether references correspond to pointers.
> and each object has a unique identity
Which doesn't necessarily have anything to do with their address. It's an opaque value guaranteed to be unique for an object for the duration of its lifetime.
Meanwhile, C pointer values aren't necessarily unique for different objects. For example, a pointer to a struct with one or more fields shares value with a pointer to its first field. It's only once you factor in type that pointers uniquely identify a particular object, so they don't exactly correspond to Python's object identity.