Not all of them are political (e.g. cancelling someone for sexual assault is clearly not, and that Heineken one... how??), but a decent number are, e.g. number 6 is about as partisan as you can get.
It's a fairly inevitable reaction to cancel culture. This was predicted and warned against when left-wing cancel culture was at its height, but people didn't listen. Now we have right-wing cancel culture instead.
I wouldn't recommend the Gang of Four book. Many of the design patterns they espouse are way over complicated from the days of peak OOP. You know, FactoryFactoryVisitor stuff. Usually best avoided.
Throwaway scripts: "write me a bash script to delete all merged git branches starting with 'foo'"
Writing functions that are tedious to look up but I can fairly easily evaluate for correctness: "write a C function to spawn a process and capture stdout and stderr merged"
Doing stuff in systems I'm not very familiar with: "write an OCaml function to copy a file"
I haven't got around to setting up any of that agentic stuff yet. Based on my experience of the chat stuff I'm a bit skeptical it will be good enough to be useful on anything of the complexity I work on. Find for CRUD apps but it's not going to understand niche compiler internals or do stuff with WASM runtimes that nobody has ever done before.
I think it's a perfectly reasonable license. You can also use it for free with closed source projects, except embedded projects (where most of the money is), which I think is generous.
I don't think everything has to be completely free. I'd much rather they had a viable business model and actually continue existing than just fizzle out because they have no funding source. Writing a high quality GUI toolkit is an enormous task so it's not really going to happen otherwise.
As much as I'm following egui, Xylem, Dioxus, Makepad etc. and hope they succeed I'd put my money on Slint being the first to make a Rust GUI toolkit of the same quality as Qt.
This video confuses at least three different concepts - quantum uncertainty, ternary computers, and "unknown" values.
Ternary computers are just not as good as binary computers. The way silicon works, it's always going to be much much slower.
"Unknown" values can be useful - they are common in SystemVerilog for example. But you rarely just have true, false and unknown, so it makes zero sense to bake that into the hardware. Verilog has 4 values - true, false, unknown and disconnected. VHDL has something like 9!
And even then the "unknown" isn't as great as you might think. It's basically poor-man's symbolic execution and is unable to cope with things like let foo = some_unknown_value ? true : true. Yes that does happen and you won't like the "solution".
High level programming concepts like option will always map more cleanly onto binary numbers.
Overall, very confused video that is trying to make it sound like there's some secret forgotten architecture or alternative history when there definitely isn't.
I disagree. That's how Python works but it sucks because it means instead of a C++ (for example) project with some Python utility scripts scattered inside it, you have to turn it into a proper Python project, when it isn't a Python project; you just have some Python scripts in it.
Basically it throws away the ad-hoc scripting use case entirely.
This is awesome. It gets closer to Deno which I think is one of the only things that have actually solved the "ad hoc scripting" challenge, which requires:
Easy to install language.
Easy to use third party dependencies (from a single file script).
Easy to import from other files without setting up a whole project.
IDE support.
At one end we have Deno which nails all of those. At the other, Python which fails all of them pretty miserably (despite this being one the most popular use cases for Python).
Seems like with this Rust will have 1 and 2 solved, and I guess 4 isn't too hard. What about 3 though?
If I eventually decide I want to split my one file script into two files will I be able to?
Edit: I had a play and actually it's good news!
If you want to split up a script you can just do mod foo and it will look for foo.rs (or I guess foo/mod.rs) in the same directory!
For common code, which you might want to import from e.g. ../../common you can't just use mod but you can add common = { path = "../../common" } to [dependencies]. That directory has to be a proper crate with Cargo.toml but I think that's ok and probably desirable.
The only downsides I found are:
No IDE support yet.
It prints compilation messages to stdout, which kind of sucks.
Even after it has been built, it still does incremental compilation every time you run it, leading to more compilation message noise, and ~100ms startup time.
Thanks for highlighting your username - made me notice that you post a lot of nonsense here so I can easily block it!