The Blow programming language

The developer of Braid has streamed two talks so far (with more to come) on his pain points in language design. He's uploaded the recordings here:

https://www.youtube.com/watch?v=TH9VCN6UkyQ
https://www.youtube.com/watch?v=5Nc68IdNKdg

It seems to me that what he actually wants is more or less Rust, but he doesn't realize it because he's hung up on design decisions that strike him as opinionated, when really they're the natural outcome of the overall design constraints ("no GC, no run-time type checking if we can help it," and so on) or represent planned features that merely have yet to be implemented. Then again, the D community is saying something similar, and I don't know D as well as Rust so I'm not sure what to think.

>>3
I'm sure there's a transcript somewhere of his specific complaints. But off the top of my head, without rewatching the entire thing:

- The C-style header + preprocessor model needs to die (I think all of us can agree with this)
- Inheritance hierarchies are snake oil, and maybe method syntax is bad too (he's not sure)
- RAII is no substitute for having decent memory management techniques baked into the language, but GC is the wrong solution. A better plan would be to have owned vs. weak/borrowed pointers, and only the current owner decides whether a pointer gets freed
- Nullability should be reined in, but this has to be done using a special language feature like in C#, not a general purpose data structure feature like the Maybe type in Haskell (because of his syntax gripes below)
- Generally, memory should not be regarded as a general purpose "resource" like a file handle, because (e.g.) your program is guaranteed to allocate memory somehow, but might not open files or whatever
- Memory safety is a tooling problem, not a compiler problem, so the language only needs just enough safety features to enable better tooling
- Syntax should aid as much as possible in refactoring, meaning that any change by the programmer which has a small impact on the behavior of the code should also have a small impact on what the syntax looks like
- Type syntax, for example, should be very up-front about what kind of data a var actually contains, and use small sigils in consistent ways to indicate that a var is any of the different types of pointers, an array, refcounted, nullable, etc.
- Declaration syntax should be more regular: foo : int to declare a var with its type, foo = 5 to perform assignments, and foo : int = 5 (or foo := 5 if you have type inference) to declare and initialize in the same statement
- Function, lambda, and local scope block syntax should be unified as much as possible, so that you can quickly rewrite one to another just by adding an argument list or whatever
- C++-style closure capture whitelists should be available on all of the above, even regular scope blocks and top-level functions, for fine-grained control over exactly how "pure" a block of code is (ie. what outside state it reads or modifies)

He also ranted a bit about stuff like public/private modifiers, which I guess means he wants the language not to assume you're writing a library, because who writes those anyway?