Rustee devs are strange. It feels as if they are on a mission. I don't fully understand it.
My “grand vision” for Rust
131–140 of 323 posts
Re: My “grand vision” for Rust
#132the most exciting thing about rust is that AI agents are good at writing it because its so highly structured
Re: My “grand vision” for Rust
#133I do not write Rust. I have left c++ cause of the feature creep of the last years that made it even harder to read c++. Reading code is so important. Make language not unfriendly for readers and value the time people put into learning a language. I have seen many c++ programmers leaving cause they feel its an other language now
Re: My “grand vision” for Rust
#134The rust maintainers need to learn from the mistakes of the c++ design committee and understand that not adding a feature at all is in itself a desirable feature. For example, your section on effects: > Functions which guarantee they do not unwind (absence of the panic effect) * I actually don’t see how this is any more beneficial than the existing no_panic macro https://docs.rs/no-panic/latest/no_panic/ > Functions…
You just know some guy will try to make cli code no-panic/deterministic use a bunch of crap and think he achieved something.
Just not allowing complex code is so much better than this.
Just even being able to look at a piece of code and trace what it is doing is 1000x more valuable than this. I regretted almost every time I allowed Traits/generics into a codebase
Re: My “grand vision” for Rust
#135I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…
Can we get a version of Rust that swaps lifetimes and ownership for a GC and a JS-style event loop? I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker.
Re: My “grand vision” for Rust
#136I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…
Can we get a version of Rust that swaps lifetimes and ownership for a GC and a JS-style event loop? I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker.
Re: My “grand vision” for Rust
#137It's hard to see features through the programming language theory jargon, but solid theoretical foundations have worked well for Rust so far. Jargon terms like "sum types" or "affine types" may seem complicated, but when you see it's actually "enums with data fields", it makes so much sense, and prevents plenty of state-related bugs. Proposed "effects" mean that when you're writing an iterator or a stream, and need t…
What worked for rust is having enums, sane-ish error handling, having sane integer types and the borrow checker, good tooling. The rest is just not that useful compared to how much garbage it creates
Re: My “grand vision” for Rust
#138I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…
I experienced the same kind of fatigue when I read "there are three directions of development which I find particularly interesting: [three things I never heard about nor particularly want to get familiar with]" in the article.
And later, when I read "Because though we’re not doing too bad, we’re no Ada/SPARK yet" I couldn't help thinking that there must be a reason why those languages never became mainstream, and if Rust gets more of these exciting esoteric features, it's probably headed the same way...
Re: My “grand vision” for Rust
#139I'm not sure why people are so deeply scared. these are all pretty neat features for people who will need them (off rip seemingly mostly in the embedded world). It's not like the inclusion of these forces you to use them — I've never had to deal with unsafe rust for shipping web stuff, and I highly doubt I'd have to deal with most of these. For modeling's sake it would be nice to have pattern types and view types, I…
People will push this crap into production codebases and link to these articles when you say you don’t want complexity. Best way to manage is to not make it possible, like go.
You indirectly deal with this kind of thing when compiling web server code too. It compiles super slow and can have weird errors. This is because the people who build the web stack in rust used a million traits/generics/macros etc.
Even if you look at something like an io_uring library in rust, it uses a bunch of macros instead of just repeating 3 lines of code.
Re: My “grand vision” for Rust
#140No-one ever has the "Grand Vision" to cut something down to it's essential 25% and delete the rest.
Unless there's a conscious and constant effort to keep things simple, a programming language or software project will grow to consume all available resources, developers' time, intellectual capacity, and funding.