If Go And Rust Had A Baby

The biggest revelation in this whole video is that Prime doesn't know what "for all intents and purposes" means

If Go And Rust Had A Baby, his name will be: Grrr

Opt in safety means, you cannot trust any code you didn't write and probably can't trust code you did write and have to assume, simply because it's possible, that all code is unsafe until proven otherwise... which is possibly even worse than C because it could give you a false sense of security

The problem with opt in safety, heck all opt in feature, is that you are not the problem if you know the subject well, the problem is your coworkers, who write terrible code, and you have to maintain and debug that terrible code. Most people wouldn't do it if there wasn't a language forcing them to do it, or just don't know it is there, and you have to live with the consequences.

The reason why lifetimes “leak” is because you’re likely treating these annotated stack based objects like based heap based objects. The Rust lifetime checking system is not a substitute for garbage collection or reference counting. This is something that programmers who are used to the value-type-reference-type paradigm seem to struggle with the most when learning the language because when you think of lifetimes you tend to think in terms of the heap, which is something that has to be unlearned in the process of leaning the language.

should be called gust

I think a lot of the Rust lifetime unreadability goes away if you start giving more descriptive lifetimes but 'a and 'b. For example, 'request, 'fileopen etc. Then your error messages will make more sense when it's obvious what the lifetime means for logic.

I think Prime is experiencing the Trough of Disillusionment when it comes to Rust. It's not the savior language to rule them all it seemed but it's also not completely missing the mark either like he seems to be alluding to more lately. Yes, it's difficult to learn "fully", but that difficulty buys you into a lot. It has a lot of high level ergonomics. You can pick up something like Dioxus and write gui and web apps in the same codebase pretty easily from a web dev background, or pick up any will written library with high level ergonomics and write great fast, safe high level rust. I wrote a damn custom bluetooth device sdk within a few months of learning Rust and I barely knew what I was doing. Yes, if you want to write on of those well crafted libraries... that's going to be harder, but it's at least in the same language. I think it's great that you can have the low level difficult problems being solved in the same language as having catered, neat and clean high level (js developer level) ergonomic programming, and both can confidently contribute to the same code solutions. Yes GO is sort've like this but it never gets deeper. If you dive into Go you'll break your neck immediately hitting the bottom and need to switch to another language to go deeper. Rust's unique super power is the high level ergonomics if you want to stay high level and the ability to go as deep as you want, all while playing by the same rules. Rust's difficulty is known, there is a way to do just about everything you could every want to do with code, you just have to learn it or the patterns. JS is "easy" but there's 8 trillion simple footguns along the way that we just pretend aren't there, it's difficulty is unknown. Known and understood difficultly is way more valuable to solve hard problems. I'm not fanboying for Rust btw, it's not the best thing, it has problems and doesn't fit everything, but it definitely does have it's place. I assume (and it may take some time), Prime will eventually revisit Rust with fresh eyes and see it a bit more positively than he currently does when he realizes, zig is too low for a lot of things and go is too 1 dimensional and Rust can actually straddle a very wide band of depth quite well

Opt-in safety is how we got into the current unsafe mess in the first place though. If something is to be used by the masses, it needs to be on by default.

Prime is wrong here 11:07 that actually is the main reason shared mutable references are not allowed

The only reason I like Rust is because it's SAFE by default. Take that aways and why not just use C/C++?

Opt in to safety = unsafe. We already know this from decades of experience. Explicit out is fine, which Rust allows in some cases. But maybe we should have more ways to do this? Also, as an aside, it seems always to be people coming from GC backgrounds who are arguing that Rust is hard. Is it possible that it’s just that GC programming is stupidly easy and that safe systems programming is just inherently non-trivial?

So basically I have to do just as much work as C memory management. But it’s a complex mush mash of syntax that’s even more confusing than just managing the memory yourself. This is why C is still king.

Qt has had the concept of deleteLater for like 25 years, but that is a library implementation as mentioned by someone else vs language impl

Important question: can I use June any other month of the year?

I’m sorry, but with modern C++, GO and ZIG. Rust will never be what people thought

opting out of safety is better than opting into safety, and better than safety you cannot opt out of. I want it auditable. marking an entire block as unsafe I also think is a bit heavy handed. I like the idea of doing it surgically, because my assumption would be that you only need it in small targeted areas. I think there should be a little bit of friction at every separate point you can interface with.

In short it’s using hidden allocators In this language to make “recycling” of memory possible. Guess there should be simply a incentive for people to use allocators and that would make stuff way more trivial. What was meant to be groups here are actually allocators. Embedded Programming with Rust is an Experiment, i found Odin on my side to be the thing i wanted it needs tooling though.

Back in the days Objective-C in NeXTstep had auto-release pools (maybe still today on Swift/MacOS) providing a lifetime control feature on RC memory management. Compact regions in Haskell provides a similar feature on GC behaviour... and of course many more options for fine-tuning memory management without losing safe execution.

If you ever programmed a by-value data-flow language, you'd see all these issues are irrelevant. All memories are deallocated once the function is done. The data will be available if another function is atill using it (passed by value). Obviously not suitable for systems programing language but all memory problems are not present