Jonathan Blow on Rust
np.reddit.com
Jonathan Blow on Rust
1–10 of 52 posts
Re: Jonathan Blow on Rust
#2It just seems really unconvincing to me. Just don’t do data modeling with entity pointers at all, and use patterns like RAII to guarantee that resources manage the lifetime of pointers they need. Or use pure functional programming if it matters that much in a given use case.
When the article says the compiler doesn’t know whether a given pointer is meant to be an entity pointer or not, but that you do as the programmer (and thus should use complex metaprogramming facilities to encode correctness of handling semantics of that pointer), it loses me completely. Those are code smells of bad program structure (especially creating the metaprogram to enforce a type of correctness chosen by the programmer, and highly susceptible to YAGNI premature abstraction).
In response to “boy it’s hard to guarantee keeping track of all these things” the bad response is to take on more code liability in the form of metaprogram “safety” enforcement. The good response is to ruthlessly remove entity-style pointer handling entirely and restructure the program to simply not need it.
Re: Jonathan Blow on Rust
#3The only specific statements about Rust quoted in that thread appears to be:
> And so Rust has a good set of ingredients there. The problem that I have with it is when I'm working on really hard stuff, I don't exactly know what I'm doing for a long time. And so if the cost of experimentation is driven too high, it actually impairs my ability to get work done.
The rest seems to be a discussion about the problems of memory management in general. It's not clear how much Blow has actually used Rust.
Re: Jonathan Blow on Rust
#4It just seems really unconvincing to me. Just don’t do data modeling with entity pointers at all, and use patterns like RAII to guarantee that resources manage the lifetime of pointers they need. Or use pure functional programming if it matters that much in a given use case. When the article says the compiler doesn’t know whether a given pointer is meant to be an entity pointer or not, but that you do as the programm…
> highly susceptible to YAGNI premature abstraction
I think in most cases this sentiment is correct but I think Blow's argument is that you are going to need it. In other talks he put forth some use cases where this has worked for him and his game dev studio.
The most abstract version of this argument:
1. A compiler is a tool to help the programmer
2. Compilers for the Rust programming language help the programmer by validating the program to be within a subset of all computable programs that operate within the language's rules (the borrow checker and type system)
3. there are likely many programs that are computable and correct that cannot be modeled within Rust's safety system (see most of the world's software to date)
4. For some use cases the most optimal solution may not fall within the subset of programs that Rust allows
5. Because of this it may be impossible for Rust to implement the most optimal solutions for some programs.
Blow's goal of making compilation describable within the language itself brings forward a huge set of features that other languages need a runtime or complex compiler to do. Things like code generation, reflection, metaprogramming, linting, and correctness validation could simply be packages you install with a package manager. If the language is kept at a minimal feature set and complexity with an advanced enough metaprogramming phase entire language features and abstractions can be implemented in this step. For example imaging being able to do something like `import grpc; import application.proto` and all of the gRPC magic happening without any complex build system at the full native speed of the compiled language with no runtime deps.
I'm not saying Blow is correct, I'm just saying it is a very interesting direction to take programming languages: weak guarantees but completely programmable.
Re: Jonathan Blow on Rust
#5It just seems really unconvincing to me. Just don’t do data modeling with entity pointers at all, and use patterns like RAII to guarantee that resources manage the lifetime of pointers they need. Or use pure functional programming if it matters that much in a given use case. When the article says the compiler doesn’t know whether a given pointer is meant to be an entity pointer or not, but that you do as the programm…
I think most of the time you're right, but in particular in game programming you know the optimizations you're going to need since the patterns have been pretty well established by now. And those patterns and optimizations are pretty low level which requires you to really understand how things are laid out in memory and rust might not give you great insight into how it lays things out (or it's not as well known or talked about...).
Re: Jonathan Blow on Rust
#6The only specific statements about Rust quoted in that thread appears to be: > And so Rust has a good set of ingredients there. The problem that I have with it is when I'm working on really hard stuff, I don't exactly know what I'm doing for a long time. And so if the cost of experimentation is driven too high, it actually impairs my ability to get work done. The rest seems to be a discussion about the problems of me…
> And so if the cost of experimentation is driven too high, it actually impairs my ability to get work done.
side note but so far I think that's what made python so wildly used.
But that doesn't undermine rust value, there are problems where you want rust features even with the cost.
Re: Jonathan Blow on Rust
#7The only specific statements about Rust quoted in that thread appears to be: > And so Rust has a good set of ingredients there. The problem that I have with it is when I'm working on really hard stuff, I don't exactly know what I'm doing for a long time. And so if the cost of experimentation is driven too high, it actually impairs my ability to get work done. The rest seems to be a discussion about the problems of me…
There's a lot more in the podcast that's discussed in the comments as well, RE: linked lists, multiply owned data structures, and common goals of Rust and the Jai compiler team, but I got lazy with transcribing the audio by hand (it's harder than it sounds!) and left it at that. Besides which, the podcast episode outside of Rust was excellent!
Re: Jonathan Blow on Rust
#8The only specific statements about Rust quoted in that thread appears to be: > And so Rust has a good set of ingredients there. The problem that I have with it is when I'm working on really hard stuff, I don't exactly know what I'm doing for a long time. And so if the cost of experimentation is driven too high, it actually impairs my ability to get work done. The rest seems to be a discussion about the problems of me…
> And so if the cost of experimentation is driven too high, it actually impairs my ability to get work done. side note but so far I think that's what made python so wildly used. But that doesn't undermine rust value, there are problems where you want rust features even with the cost.
> made python so wildly
I think you meant "widely", but wildly works as well.....
Re: Jonathan Blow on Rust
#9The only specific statements about Rust quoted in that thread appears to be: > And so Rust has a good set of ingredients there. The problem that I have with it is when I'm working on really hard stuff, I don't exactly know what I'm doing for a long time. And so if the cost of experimentation is driven too high, it actually impairs my ability to get work done. The rest seems to be a discussion about the problems of me…
There's a lot more in the podcast that's discussed in the comments as well, RE: linked lists, multiply owned data structures, and common goals of Rust and the Jai compiler team, but I got lazy with transcribing the audio by hand (it's harder than it sounds!) and left it at that. Besides which, the podcast episode outside of Rust was excellent!
Is it possible to use the speech to text feature of your OS to transcribe the podcast quickly? Just curious...
Re: Jonathan Blow on Rust
#10It just seems really unconvincing to me. Just don’t do data modeling with entity pointers at all, and use patterns like RAII to guarantee that resources manage the lifetime of pointers they need. Or use pure functional programming if it matters that much in a given use case. When the article says the compiler doesn’t know whether a given pointer is meant to be an entity pointer or not, but that you do as the programm…
"[T]here is always a well-known solution to every human problem — neat, plausible, and wrong."
H.L. Mencken