Got welders, maps, legs (useful for walking), ropes, furnaces, hand tools, old cars, old workstations, soldering irons, a kitchen, gardens, paddocks, saddle making tools, radio towers, .. you know, regular house in the country from the 1930s kind of stuff.
I have been building a library for some time as well, and am ready to learn and teach once my child is ready. Frankly, the internet experience when I was young vs now is crazy. For me, it was dial up with some forums and RuneScape open, chatting via texts in game with my buddies who were considered long distance even though we all went to the same church. The pauses in loading gave time to think up good discussion, and playing things took patience. Now everything wants your attention scattered everywhere, and is flashing in your face. I love having ad blockers because of that. Social media has done nothing good for our world I feel like. Yes, connecting is nice but when you are fed things off of not your actual interest or easily searchable same results but instead whatever drives engagement for ads I like to stay well away.
Diamond hands is more of a meme token punter term. Thiel is running a hedge fund and has a responsibility to get good returns for his investors. Buying underpriced stocks and selling overpriced is a normal thing to do.
Yeah everyone wants a conspiracy when the obvious signal is that he already made insane amounts of money off the stock spiking so high and he wants to diversify it on other stuff instead of continuing to gamble on a big one. Which is also what the article says he is doing.
And Nvidia has a target on its back right now. It's priced like it's the only game in town, but AMD, Google, Meta and Intel have varying degrees of competing chips for AI use.
They don't sell it, but they could if Nvidia started charging too much, and some of these are going into Meta datacenters instead of Nvidia.
Intel makes the Arc. It's probably the least viable competitor in that list, but the fundamentals are there, so some about of focus and investment could result in a viable competitor.
It doesn't take a genius to work out somebody who bought low might want to sell high.
The newsworthy aspect to this is that the AI hype cycle is saying that right now, today, Nvidia is cheap. If AI is going to capture the entire economy, but it relies on Nvidia hardware, the current valuation is pennies on the dollar of what it will be one day.
Except, you know, that's all a lie. And Thiel peddled it for a while, and is friends with Musk, and connected to many others in the hype cycle besides, and now he's showing his hand that he knows its a lie.
- Tagged unions so you can easily and correctly return "I have one of these things".
- Generics so you can reuse datastructures other people wrote easily and correctly. And a modern toolchain with a package manager that makes it easy to correctly do this.
- Compile time reference counting so you don't have to worry about freeing things/unlocking mutex's/... (sometimes also called RAII + a borrow checker).
- Type inference
- Things that are changed are generally syntactically tagged as mutable which makes it a lot easier to quickly read code
- Iterators...
And so on and so forth. Rust is in large part "take all the good ideas that came before it and put it in a low level language". In the last 50 years there's been a lot of good ideas, and C doesn't really incorporate any of them.
It's that as well, but that part of the description doesn't catch how objects are automatically freed once the last reference to them (the owning one) is dropped.
Meanwhile my description doesn't fully capture how it guarantees unique access for writing, while yours does.
> but that part of the description doesn't catch how objects are automatically freed once the last reference to them (the owning one) is dropped.
You're confusing the borrow checker with RAII.
Dropping the last reference to an object does nothing (and even the exclusive &mut is not an "owning" reference). Dropping the object itself is what automatically frees it. See also Box::leak.
The borrow tracker tracks whether there is 1, more than 1, or no references to a pointer at any particular time and rust automatically drops it when that last reference (the owning one) goes away. Sounds like compile time reference counting to me :P
I didn't invent this way of referring to it, though I don't recall who I stole it from. It's not entirely accurate, but it's a close enough description to capture how rust's mostly automatic memory management works from a distance.
So the problem here is that it is almost entirely wrong. There is no reference count anywhere in the borrow checker’s algorithm, and you can’t do the things with borrows that you can do with reference counting.
It’s just not a good mental model.
For example, with reference counting you can convert a shared reference to a unique reference when you can verify that the count is exactly 1. But converting a `&T` to a `&mut T` is always instantaneous UB, no exceptions. It doesn’t matter if it’s actually the only reference.
Borrows are also orthogonal to dropping/destructors. Borrows can extend the lifetime of a value for convenience reasons, but it is not a general rule that values are dropped when the last reference is gone.
There is a reference count in the algorithm in the sense that the algorithm must keep track of the number of live shared borrows derived from a unique borrow or owned value so that it knows when it becomes legal to mutate it again (i.e. to know when that number goes to zero) or if there are still outstanding ones.
Borrow checking is necessary for dropping and destructors in the sense that without borrows we could drop an owned value while we still have references to it and get a use after free. RAII in rust only works safely because we have the borrow checker reference counting for us to tell us when its again safe to mutate (including drop) owned values.
Yes, rust doesn't support going from an &T to an &mut T, but it does support going from an <currently immutable reference to T> to a <mutable reference to T> in the shape of going from an &mut T which is currently immutably borrowed to an &mut T which is not borrowed. It can do this because it keeps track of how many shared references there are derived from the mutable reference.
You're right that it's possible to leak the owning reference so that the object isn't freed when the last reference is gone - but it's possible to leak a reference in runtime reference runtime reference counted language too.
But yes, it's not a perfect analogy, merely a good one. It's most likely that the implementation doesn't just keep a count of references for instance, but a set of them to enable better diagnostics and more efficient computation.
I think Rust speaks to people who don't "play" with their code during development. Moving stuff around, commenting things out, etc. When I try to do this in Rust, the borrow checker instantly complains because $something violates $some_rule. I can't say "yeah I know but just for now let's try it out this way and if it works I'll do it right".
I work this way and that's why I consider Rust to be a major impediment to my productivity. Same goes for Python with its significant whitespace which prevents freely moving code around and swapping code blocks, etc.
I guess there are people who plan everything in their mind and the coding part is just typing out their ideas (instead of developing their ideas during code editing).
That might be true. In my case, it is precisely because I do play a lot with my code, doing big 2-day refactors sometimes too. With Rust, when it finally compiles, it very often tends to run without crashing, and often correctly too, saving me a lot of debugging.
But it's also because of all the things I'm forced to fix while implementing or refactoring, that I would've been convinced were correct. And I was proven wrong by the compiler, so, many, times, that I've lost all confidence in my own ability to do it correctly without this kind of help. It helped me out of my naivety that "C is simple".
You eventually don't even think about the borrow checker, writing compiling code becomes second nature, and it also has the side effect of encouraging good habits in other languages.
> I guess there are people who plan everything in their mind and the coding part is just typing out their ideas (instead of developing their ideas during code editing).
I don't think there are, I think Gall's law that all complex systems evolve from simpler systems applies.
I play with code when I program with Rust. It just looks slightly different. I deliberately trigger errors and then read the error message. I copy code into scratch files. I'm not very clever; I can't plan out a nontrivial program without feedback from experiments.
I enjoy the ability to do massive refactors and once it builds it works and does the expected. There are so few odd things happening, no unexpected runtime errors.
I've written probably tens of thousands of lines each in languages like C, C++, Python, Java and a few others. None other has been as misery-free. I admit I haven't written Haskell, but it still doesn't very approachable to me.
I can flash a microcontroller with new firmware and it won't magically start spewing out garbage on random occasions because the compiler omitted a nullptr check or that there's an off-by-one error in some odd place. None. Of. That. Shit.
So many ways it's hard to list them. Better tooling, type system, libraries, language features, compile-time error checking.
I'm a bit surprised that you are surprised by this. I sometimes think Rust emphasizes memory safety too much - like some people hear it and just think Rust is C but with memory safety. Maybe that's why you're surprised?
Memory safety is a huge deal - not just for security but also because memory errors are the worst kind of bug to debug. If I never have to a memory safety bug that corrupts some data but only in release mode... Those bugs take an enormous amount of time to deal with.
But Rust is really a great modern language that takes all the best ideas from ML and C, and adds memory safety.
(Actually multithreading bugs might be slightly worse but Rust can help there too!)
reply