Live data from Hacker News

Jonathan Blow on Rust

np.reddit.com

11–20 of 52 posts

Re: Jonathan Blow on Rust

#11

Earlier quoted context omitted.

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...

A hacky solution is to point your speakers at a device running Google Docs with speech-to-text turned on, but I haven't found anything that handles multiple speakers well - especially with overlapping voices, as happens often in this episode.

Re: Jonathan Blow on Rust

#12
post #8

Earlier quoted context omitted.

> 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.....

yeah, I thought about this for a minute and wildly still felt appropriate :)

thanks for the reminder nonetheless

Re: Jonathan Blow on Rust

#13
I would recommend the entire episode, it was very good. Only a small part is about Rust.

I’ve listened to plenty of interviews and talks/rants by Jonathan Blow, and while I think he has a lot of interesting ideas, he also has a well earned reputation for being very blunt in how he expresses his opinions. Bryan Cantrill was an excellent interviewer, and managed to bring out the best side of Blow.

Re: Jonathan Blow on Rust

#14
post #4

It 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…

> 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.

I know you're not advocating for Lisp, but it kind of sounds like you are.

Re: Jonathan Blow on Rust

#15
post #4

Earlier quoted context omitted.

> 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…

> 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 m…

I love Lisp as much as the next neckbeard, but macros aren't unique to Lisp and they aren't the only kind of compile-time execution.

It's tough to come up with a better syntax than sexprs for writing macros in, that's clearly true. A number of recent languages have managed good-enough macros, Nim and Rust being two examples.

Re: Jonathan Blow on Rust

#16
post #3

The 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!

A lot of podcasts get transcribed on Rev, though it isn't free.

Re: Jonathan Blow on Rust

#17
post #3

The 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…

I'm finding exactly the same problem with Rust -- I am do exploratory programming in GAP (a Python-like language), then rewriting to Rust once I'm confident I have all the basic data structures and code down. The compile speed of Rust alone is painful.

Also, when converting C++ code to Rust, I find many places where I'm having to de-optimise code to get it past the borrow checker. Large cyclic data structures which are freed as one piece are annoyingly difficult in Rust.

Re: Jonathan Blow on Rust

#18
I've been arguing lately that C++ should do something like this: Add a full-on theorem-prover to the language so that I can write my own safety rules specific to how my program works.

In the Cloudflare Workers runtime we have a sort of analogous problem to what Blow has in his game engine. We have certain objects that live on the JavaScript heap (which is garbage collected), or are directly owned by objects on the JS heap, and then we have system objects involved in basic I/O that aren't necessarily tied to a particular JS isolate and are not garbage collected, but are often tied to specific OS threads. JS objects and system objects are allowed to own instances of each other, but the ownership must be handled in a special way. E.g., when a system object holds a reference to a JS object, the destructor must ensure the JS isolate lock is held before releasing that reference. Conversely when a JS object holds ownership of a system object, and the JS object is garbage collected, we need to queue the system object's destructor to run in the thread where it was created.

Conceptually, it ought to be easy to write rules where each type is declared as being a system type or a JS type, and then the compiler could trivially enforce that the correct sort of references are used between them. But, the problem is very specific to our codebase, so it would make no sense to bake into the language.

I think the next big thing for C++ should be adding ways to define custom code-checking rules like this. It would allow C++ to become a safe language and would fit perfectly with C++'s culture of being ridiculously overcomplicated. ;)

Re: Jonathan Blow on Rust

#19
post #4

It 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…

I have not listened to the podcast, but the example regarding entity pointers not outliving the frame would be something Rust is really good at.

The borrow checker can make sure that references to entities are strictly contained within the lifetime of a frame container and statically check that aspect.

> Because what’s an entity pointer vs a pointer to something else? The compiler doesn’t know that

Rusts compiler can know the difference and it can check lifetimes around that. Lifetimes can be made part of the type of the pointer.

Re: Jonathan Blow on Rust

#20
post #18

I've been arguing lately that C++ should do something like this: Add a full-on theorem-prover to the language so that I can write my own safety rules specific to how my program works. In the Cloudflare Workers runtime we have a sort of analogous problem to what Blow has in his game engine. We have certain objects that live on the JavaScript heap (which is garbage collected), or are directly owned by objects on the JS…

I really like this idea. I’ve been messing around with the z3 theorem prover, and while I don’t think there’s an easy way to integrate it to do compile-time checks, I made a little wrapper class that lets you add assertions which are checked for satisfiability at the end of a function’s scope. But it’s all at runtime, so it’s more like a more advanced assert() than anything like Jai or Rust has.

I think SMT solvers are criminally under used and have a lot of potential to help solve some of the issues in a way that still allows rapid iteration at first and then incremental safety checks to be added on later.

Post reply on HN