Live data from Hacker News

Rust--: Rust without the borrow checker

github.com

261–269 of 269 posts

Re: Rust--: Rust without the borrow checker

#261
post #164

As someone who's only did a couple of small toy-projects in rust I was never annoyed by the borrow checker. I find it nothing but a small mental shift and I kinda like it. What I _do_ find annoying though and I cannot wrap my head around are lifetimes. Every time I think I understand it, I end up getting it wrong.

Somehow at some point lifetimes started clicking for me. I think the key was when I understood that in a function, not everything needs the same lifetime. e.g.

    struct MyRef { item: &'a i64 }
    struct MyType { items: Vec }
    impl MyType {
        fn get_some_ref(&self, key: &usize) -> MyRef {
            MyRef { item: &self.items[key] }
        }
    }
the function this way is incorrect. When I was a beginner, I would have thought that every & in the signature needed a lifetime. In a slightly complicated code, the borrow checker then demanded lifetimes everywhere, they'd infect everything, but the code would still never compile.

Then I understood that not everything needs to be tied to the same lifetime. In this example, MyRef should be tied to the MyStruct, but not to the `key`:

        fn get_some_ref(&'a self, key: &usize) -> MyRef

Re: Rust--: Rust without the borrow checker

#262

Earlier quoted context omitted.

Rust can set restricts to all pointers, because 1 mut xor many shared refs rule. Borrow checker empowers this. https://en.wikipedia.org/wiki/Restrict

The crazy part about this is that (auto) vectorization in Rust looks something like this: iter.chunks(32).map(vectorized) Where the vectorized function checks if the chunk has length 32, if yes run the algorithm, else run the algorithm. The compiler knows that the chunk has a fixed size at compile time in the first block, which means it can now attempt to vectorize the algorithm with a SIMD size of 32. The else block…

Hah I love things like this, where the compiler leaks out.

Re: Rust--: Rust without the borrow checker

#263

I'm the author of this repo. I see some really angry comments, some of them even personal. Obviously I didn't think that just by tinkering with a compiler, I'd get personally attacked, but anyway, fair enough. For those of you confused: yes, this started as a satirical project with the corroded lib. Then I thought "why not just remove the borrow checker?" without any real motivation. Then I just went ahead and did it…

I ran into the borrowc so many times when doing OS dev. Which is why I hold the position that Rust is (not) a suitable language for OS development/kernels/embedded systems. In such scenarios, multithreading/multiprocessing is something you explicitly have to do, since although most systems that aren't x86 may start all processors simultaneously, your bootstrap code (should!) explicitly park all other cores before continuing. But the problem I always ran into was that Rust wanted me to do something weird for a system that was (not) multi-threaded. As in, I didn't even support threads of any kind. Or coroutines. But I still had to wrap statics in Lazy or Rc or something because "uwuw this is unsafe oh the world is going to end!" And all I wanted was to tell the borrow checker to shut up for once because yes, I actually did know what I was doing, thank you very much.

I get the idiom of "trust the compiler, it knows your code better than you". But there are also instances where the compiler just needs to trust the programmer because the programmer is, in fact, smarter than the compiler in those instances.

Re: Rust--: Rust without the borrow checker

#264

I've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.

…then just use Rust? I’m confused. Most of this stuff never comes up if you aren’t doing things where memory safety would be an issue.

The code I have in C is often code that does't fit in Rusts safety model. Dealing with ffi is annoying because slices have no defined layout. `dyn` is limited compared to what I can do with a manual vtable. I have seriously attempted porting my personal stuff to Rust, but theres enough papercuts that I go back to C. I want the parts of Rust I find to be helpful without those parts I don't.

Re: Rust--: Rust without the borrow checker

#265
post #67

Rust- is you use C with ring buffers. If you think you need dynamic memory allocation your program is underspecified.

Avoiding dynamic allocation does not avoid memory unsafety in C.

Let’s put it this way. If it wasn’t a feature rust wouldn’t exist.

Re: Rust--: Rust without the borrow checker

#266
post #249

Earlier quoted context omitted.

You're basically just re-stating my point. You mistakenly believe the pattern you've seen is predictive and so you've invented an explanation for why that pattern reflects some underlying truth, and that's what pundits do for these presidential patterns too. You can already watch Harry Enten on TV explaining that out-of-cycle races could somehow be predictive for 2026. Are they? Not really but eh, there's 24 hours pe…

> You mistakenly believe the pattern you've seen is predictive Why mistakenly? I think you're confusing the possibility of breaking a causal trend with the likelihood of doing that. Something is predictive even if it doesn't have a 100% success rate. It just needs to have a higher chance than other predictions. I'm not claiming Rust has a zero chance of achieving C++'s (diminished) popularity, just that it has a less…

Your hypothetical "factor of ten" market share growth requirement means it's literally impossible for all the big players to achieve this since they presumably have more than 10% market share and such a "factor of ten" increase would mean they somehow had more than the entire market. When declaring success for a model because it predicted that a literally impossible thing wouldn't happen I'd suggest that model is actually worthless. We all knew that literally impossible things don't happen, confirming that doesn't validate the model.

Lets take your Fortran "example". What market share did Fortran have, according to you, in say 1959? How did you measure this? How about in 1965? Clearly you're confident, unlike Fortran's programmers, users and standards committee, that it was all over by 1966. Which is weird (after all that's when Fortran 66 comes into the picture), but I guess once I see how you calculate these outputs it'll make sense right?

Re: Rust--: Rust without the borrow checker

#267
post #249

Earlier quoted context omitted.

> You mistakenly believe the pattern you've seen is predictive Why mistakenly? I think you're confusing the possibility of breaking a causal trend with the likelihood of doing that. Something is predictive even if it doesn't have a 100% success rate. It just needs to have a higher chance than other predictions. I'm not claiming Rust has a zero chance of achieving C++'s (diminished) popularity, just that it has a less…

Your hypothetical "factor of ten" market share growth requirement means it's literally impossible for all the big players to achieve this since they presumably have more than 10% market share and such a "factor of ten" increase would mean they somehow had more than the entire market. When declaring success for a model because it predicted that a literally impossible thing wouldn't happen I'd suggest that model is act…

> means it's literally impossible for all the big players to achieve this

Only because they've achieved that 10% in their first decade or so, but what I said is the case for all languages, big and small alike (and Rust doesn't have this problem because it needs a 10x boost to approach C++'s current market share, which is already well below its peak). But the precise numbers don't matter. You can use 5x and it would still be true for most languages. The point is that languages - indeed, all technologies, especially in a competitive market - reach or approach their peak market share relatively quickly.

You make it sound like a novel or strange theory, but it's rather obvious when you look at the history. And the reason is that if a technology offers a big competitive advantage, it's adopted relatively quickly as people don't want to fall behind the competition. And while a small competitive advantage could hypothetically translate to steady, slow growth, what happens is that over that time, new alternatives show up and the language loses the novelty advantage without ever having gained a big-player advantage.

That's why, as much as I like, say, Clojure (and I like it a lot), I don't expect to see much future growth.

> Clearly you're confident, unlike Fortran's programmers

Yes, because I have the benefit of hindsight. Also, note that I'm not saying anything about decline (which happens both quickly and slowly), only that technologies in a competitive market reach or approach their peak share quickly. Fortran clearly became the dominant language for its domain in under a decade.

But anyway, if you think that steady slow growth is a likelier or more common scenario than fast growth - fine. I just think that thesis is very hard to support.

Re: Rust--: Rust without the borrow checker

#268
post #267

Earlier quoted context omitted.

Your hypothetical "factor of ten" market share growth requirement means it's literally impossible for all the big players to achieve this since they presumably have more than 10% market share and such a "factor of ten" increase would mean they somehow had more than the entire market. When declaring success for a model because it predicted that a literally impossible thing wouldn't happen I'd suggest that model is act…

> means it's literally impossible for all the big players to achieve this Only because they've achieved that 10% in their first decade or so, but what I said is the case for all languages, big and small alike (and Rust doesn't have this problem because it needs a 10x boost to approach C++'s current market share, which is already well below its peak). But the precise numbers don't matter. You can use 5x and it would s…

> The point is that languages - indeed, all technologies, especially in a competitive market - reach or approach their peak market share relatively quickly.

This predicts nothing in particular, for any outcome we can squint at this and say it was fulfilled, so in this sense it's actually worse than the XKCD cartoon.

It's not that it's a novel or strange theory, it's just wrong.

> if a technology offers a big competitive advantage, it's adopted relatively quickly as people don't want to fall behind the competition

Yeah, no. See, humans have a strong preference for the status quo so it isn't enough that some technology "offers a big competitive advantage", they'd usually just rather not actually. Lots of decision makers read Google's "Move Fast and Fix Things" and went "Yeah, that's not applicable to us [for whatever reason]" and moved on. It doesn't matter whether they were right to decide it wasn't applicable, it only matters whether their competitors reach a different conclusion and execute effectively.

Re: Rust--: Rust without the borrow checker

#269
post #267

Earlier quoted context omitted.

> means it's literally impossible for all the big players to achieve this Only because they've achieved that 10% in their first decade or so, but what I said is the case for all languages, big and small alike (and Rust doesn't have this problem because it needs a 10x boost to approach C++'s current market share, which is already well below its peak). But the precise numbers don't matter. You can use 5x and it would s…

> The point is that languages - indeed, all technologies, especially in a competitive market - reach or approach their peak market share relatively quickly. This predicts nothing in particular, for any outcome we can squint at this and say it was fulfilled, so in this sense it's actually worse than the XKCD cartoon. It's not that it's a novel or strange theory, it's just wrong. > if a technology offers a big competit…

> It's not that it's a novel or strange theory, it's just wrong.

Okay. Can you provide an example of a language that steadily and gradually grew in popularity over a long time (well over a decade) and that this slow growth was the lion share of its market size growth? You say "it's just wrong" but I think it applies to 100% of cases, and if you want to be specific when it comes to numbers, then even languages whose market share has grown by a factor of 5 after age 10 is a small minority, and even a factor of 2 is a minority.

> Yeah, no. See, humans have a strong preference for the status quo so it isn't enough that some technology "offers a big competitive advantage", they'd usually just rather not actually.

Except, again, all languages, successful and unsuccessful alike, have approached their peak market share in their first decade or so. You can quibble over what I mean by "approach" but remember that Rust, at age 10+, needs to grow its market share by a factor of 10 to even match C++'s already-diminished market share today.

Post reply on HN