These would be great additions. I don't get why people don't want powerful type systems. Let the language work for you!
My “grand vision” for Rust
101–110 of 323 posts
Re: My “grand vision” for Rust
#102Thank God for Zig
Elaborate.
Re: My “grand vision” for Rust
#103This may be too much advanced type theory for a useful language. You can go all the way to formal verification. This is not enough for that. Or you can stop at the point all memory error holes have been plugged. That's more useful. You can go way overboard with templates/macros/traits/generics. Remember C++ and Boost. I understand that Boost is now deprecated. I should work some more on my solution to the back-refere…
> I understand that Boost is now deprecated. Huh?? Boost is used basically everywhere.
Not at all. Most of the good parts of boost are now part of the standard library, and the rest of boost that is of high quality have stand-alone implementations, like ASIO, pybind11 (which was heavily influenced by Boost.python), etc...
A lot of the new stuff that gets added into boost these days is basically junk that people contribute because they want some kind of resume padding but that very few people actually use. Often times people just dump their library into boost and then never bother to maintain it thereafter.
Re: My “grand vision” for Rust
#104From the historical sources I could find online, it appears that Rust's borrow system was independently invented, or at least they don't mention linear logic or anything substructural. This is kind of interesting to me, especially given the reactions in this thread, and ties into the general difficulty of PL research to find acceptance among practitioners, especially when presented by researchers (which I think is re…
I don't remember where I read it, but I think Rust cited Cyclone as an influence, a variation of C with "region-based" memory management - more or less the literature name for "lifetimes". I think Rust may be the first to use it directly for stack variables, however.
Re: My “grand vision” for Rust
#105Really excited for the possibilities here.
People undoubtedly thought going for Affine types was too much, and even simple things like null safety or enums-with-values and the prevalence of Result saw debate with minimalists voicing concerns.
A world where you could write a Rust program that is memory leak free with Affine types is one I want to live in. Haskell can do it now, but its just not easy and Rust has beat out Haskell with its mix of ML-strength types and practicality.
IMO these changes maintain Rusts winning mix of academia and practicality. Heres a proof point — dependent types weren't mentioned :)
Re: My “grand vision” for Rust
#106I 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…
> Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile;
I didn't understand that you were making fun of verbosity until the word 'domicile'. I must be one of those insufferable people who expresses simple thoughts with ornate vocabulary...
The article was comprehensible to me, and the additional function colorings sound like exciting constraints I can impose to prevent my future self from making mistakes rather than heavy winter gear. I guess I'm closer to the target audience?
Re: My “grand vision” for Rust
#107When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the ker…
I also found it really unintuitive what needs to be made mutable. And still do to some degree.
When I first had learned that rust had this concept of “opt-in” mutability, I thought that it must then be an accepted pattern that we make as little as possible be mutable in an attempt to help us better reason about the state of our program. I had come to rust after learning some clojure so I was like “ahh! Immutable by default! So everything’s a value!”
But in reality it feels like rust code is not “designed” around immutability but instead around appeasing the borrow checker - which is actually pretty easy to reason about once you get the hang of the language. But it’s a ton to learn up front
Re: My “grand vision” for Rust
#108When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the ker…
> got stuck on this task with misleading error messages for the longest time.
Could you elaborate on that? We consider misleading error messages to be bugs and would like to know more on case we could fix them.
Re: My “grand vision” for Rust
#109I 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 really think that golang makes it easy to read code, rust makes it easy to write code. If Golang had sum types it would be a much nicer language to write complex applications with
Re: My “grand vision” for Rust
#110Earlier quoted context omitted.
Thanks for posting this! As a long-time Rust user (and contributor, in the good old days), the thing that has always fascinated me about Rust is the healthy balance it strikes between academic brilliance and industry pragmatism. Radical changes like the ones suggested by the OP risk damaging that balance IMO. I'd rather put up with some language quirks and see Rust achieve "boring technology" status... But who knows,…
The lack of use cases in that document is a concern. They're all "nice to have" features, but is the payoff there for real work? The "effects" section mentions properties useful for a proof system. But it's not part of a proof system. If it were, most of those could be found automatically by static analysis, without bothering the programmer. (I was doing that decades ago in a very early proof of correctness system.)…
"View types" addresses one of the top pain points of the borrow checker, which is disjoint borrows on a single value. The compiler can understand values where only some fields are borrowed, so e.g. you can mutably borrow the currently-unborrowed fields, but there's no way to write these partial borrows and so you cannot write functions that either take or return these borrows. This often means having to restructure code to split up one struct into several child structs just to be able to borrow those substructs independently.