I think from a PLT perspective, the interesting question is 'can the problems Rust is supposed to solve be resolved in a simpler (but radically different) conceptual model'? We started off originally with a spatial conceptual model -- stack, heap, scope -- that mapped lifecycle semantics to spaces and transitions between spaces. Concurrent programming stressed out that model and we're here with explicit mapping of semantics by the programmer. I've been wondering lately whether a new spatial approach can yet again simplify matters.
I've been closely following the development of Vale since I first saw it here. Though their approach is slightly higher-level than Rust and requires (some) runtime safety checks (though to be fair, so does GC).
https://verdagon.dev/blog/zero-cost-memory-safety-regions-ov...
I think it would be tough to change the spatial model in a language as low-level as Rust, because that spatial model is just reflecting how your CPU actually works under the hood. If you try to hide that away, the programmer is going to end up losing some control.
Take the first two sections as a perfect example. You decide you want to introduce a single-character control symbol `&` (which is questionable by itself), how do you apply it? In one case you decide that this control symbol indicates that a value is immutable and in another it's part of the declaration of a value as explicitly mutable. You've now introduced a semantic contradiction that a learner has to overcome.
Now obviously Rust works, and that's its point, and people love that enough to overcome all the ergonomic challenges the language puts up. What I can't wait for is Pythonic Rust where we have a language that treats humans as first class citiziens but offers the guarantees that Rust does. The only question in my mind for if this will ever happen is if the fully literate programming modality enabled by LLMs will make it a moot point.
let i: i32 = 1;
let &i: &i32 = &1;
let &mut i: &mut i32 = &mut 1;
let (i, &mut j): (i32, &mut i32) = (1, &mut 2);
I'm not sure how you'd recreate this symmetry without using the same symbol in both places. var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...}
This is often useful in tests (where each struct value represents a test case). Rust doesn't seem to offer any similarly compact initialization syntax for arrays or Vecs. You have to write some abomination like this: let foo = [MyStruct{a: "foo", b: 1, c: "amp"}, MyStruct{a: "bar", b: 1, c: "fff"}, MyStruct{a: "amp", b: 1, c: "aaa"} ];
Sure, it's more explicit. But even if I add a type annotation to 'foo' specifying the array type, I still have to repeat MyStruct for every member. const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...];
for (str1, num, str2) in &foos {
// ...
}
For a proper struct you have to name the fields, because otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.For example, “Voron” 3D printers are an awesome open-source design, but more and more I am directed to their discord to ask questions - many of which were, in all likelihood, asked dozens of times before. It’s great for their engaged members, who are all super helpful - but if it’s a reddit thread I can get my answer almost immediately, rather than asking, waiting and consuming someone else’s time for trivialities.
Sites like reddit at least can be readily searched from a conventional search engine, and can be crawled and stored externally in a pinch. Discord has its place, especially for game communities or other such personal things, but I’m not sure it’s ideal compared to a conventional forum as time passes and more information is built up and either lost or hidden away.
Their search makes me want to pull my hair out.
Why can't I just search the history with grep? That's a feature I would pay for (if anyone at Discord is reading this and wants my $10/month)
IDEs just gray out the unused variables and that is an 1000x better way of handling this issue.
With the usual warnings approach, you can rely on compiler/IDE/pre-commit tooling to find unused variables - they'll all nag you until it's fixed. With Zig's autofix approach, those problems are immediately silenced and you don't have any help from the compiler or tooling to find unused variables. It's quite an ironic outcome if you think about it.
[1]: https://github.com/ziglang/zig/pull/12803