Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My “grand vision” for Rust

blog.yoshuawuyts.com

Post reply on HN
Print view View original

161–170 of 323 posts

Re: My “grand vision” for Rust

#161

Post by mrsmrtss »

simonask wrote: post #79
phplovesong wrote: post #67

async rust is the worse async out there. I prayed that rust did not include a async at all. But the JS devs pushed it thru. That pretty much sealed my rust use. Im still salty.

You know what, I’ve heard people say this and thought “OK, maybe these other languages with GCs and huge runtimes really do something magical to make async a breeze”. But then I actually tried both TypeScript and C#, and no. Writing correct async code in those languages is not any nicer at all. What the heck is “.ConfigureAwait(false)”? How fun do you really think debugging promise resolution is? Is it even possible…

In .NET 11 C# async management moved to the runtime, mostly eliminating heap allocations and also bringing clean stack traces. You really only need to think about ConfigureAwait(false) when building shared libraries or dealing with UI frameworks (even there you mostly don't need it).

Re: My “grand vision” for Rust

#162

Post by ozgrakkurt »

anon291 wrote: post #146
ozgrakkurt wrote: post #139

Earlier quoted context omitted.

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…

3 lines of code that may need to change is much more complex than a macro that signals intent.

https://docs.rs/io-uring/latest/io_uring/opcode/index.html

You can click the source code link and read the code here. Macros aren’t needed at all if every single operation isn’t a different type.

Re: My “grand vision” for Rust

#163

Post by tialaramex »

awesan wrote: post #151
sam0x17 wrote: post #127

Earlier quoted context omitted.

I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work…

IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic, cannot allocate unless the developer wrote the allocation, etc. Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.

Huh? It seems to me that in these respects the two languages are almost identical. If I tell the program to panic, it panics, and if I divide an integer by zero it... panics and either those are both "the developer wrote the thing" or neither is.

Re: My “grand vision” for Rust

#164

Post by aw1621107 »

simplesocieties wrote: post #122

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

> I actually don’t see how this is any more beneficial than the existing no_panic macro

I think looking at the caveats listed in the no_panic docs should give you some ideas as to how a "proper" no_panic effect could improve on the macro.

Furthermore, a "proper" effect system should make working with effects nicer in general - for instance, right now writing functions that work independently of effects is not particularly ergonomic.

> The vast majority of rust programs don’t need such validation.

I think you also need to consider the niches which Rust wants to target. Rust is intended to be usable for very low-level/foundational/etc. niches where being able to track such effects is handy, if not outright required, so adding such support would be unblocking Rust for use in places the devs want it to be usable in.

> And for those that do, the Ferrocene project is maintaining a downstream fork of the compiler where this kind of feature would be more appropriate.

Given this bit from the Ferrocene website:

> Ferrocene is downstream from Rust

> It works with existing Rust infrastructure and the only changes made in the code were to cover testing requirements of ISO 26262, IEC 61508 and IEC 62304 qualification. All fixes are reported upstream for constant improvement.

I would suspect that such changes would be out of scope for the Ferrocene fork because that fork is more intended to be a qualified/certified Rust more than Rust + completely novel extensions.

> The compiler itself provides a powerful api via build.rs and proc macros which let downstream maintainers build their desired customization.

Given the complexity of the features listed this feels tantamount to asking each individual consumer to make their own fork which doesn't seem very likely to attract much interest. IIRC async even started off like that (i.e., using a macro), but that was painful enough and async thought to be useful enough to be promoted to a language feature.

I'm curious to what extent one can implement the described features using just build.rs/proc macros in the first place without effectively writing a new compiler.

Re: My “grand vision” for Rust

#165

Post by ozgrakkurt »

ChadNauseam wrote: post #153
ozgrakkurt wrote: post #137

Earlier quoted context omitted.

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

You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).

Generics are incredibly overused in rust like most other features. I’m pretty sure most programs don’t need generics outside of use cases like HashMap

Re: My “grand vision” for Rust

#166

Post by aw1621107 »

ozgrakkurt wrote: post #159
ChadNauseam wrote: post #153

Earlier quoted context omitted.

You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).

Yes rust async isn’t good imo. You can do basically the same thing with stackfull coroutines. Also the ecosystem is setup so you have to use tokio and everything has to be an Arc.

> You can do basically the same thing with stackfull coroutines.

...Minus the various tradeoffs that made stackful coroutines a nonstarter for Rust's priorities. For example, Rust wanted:

- Tight control over memory use (no required heap allocation, so segmented stacks are out)

- No runtime (so no stack copying and/or pointer rewriting)

- Transparent/zero-cost interop over C FFI (i.e., no need to copy a coroutine stack to something C-compatible when calling out to FFI)

Re: My “grand vision” for Rust

#167

Post by ajxs »

QuantumNoodle wrote: post #94

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

At the risk of sounding like a language zealot, have you ever looked at Ada? It was explicitly designed to be very readable, and for use in safety-critical systems. Ada isn't perfect in all the ways Rust isn't, and it might not be the right choice for your system, but if you're writing systems software it's worth a look. If you're writing a web backend on the other hand, it's not worth a look at all.

Re: My “grand vision” for Rust

#168

Post by rapnie »

ChadNauseam wrote: post #155
rapnie wrote: post #145

Earlier quoted context omitted.

Perhaps there are similarities to Scala, from my anecdotal observation. Coming from Java and doing the Scala coursera course years ago, it feels like arriving in a candy shop. All the wonderful language features are there, true power yours to wield. And then you bump into the code lines crafted by the experts, and they are line for line so 'smart' they take a real long time to figure out how the heck it all fits toge…

I honestly just don't believe that Rust is more complex to onboard to compared to languages like Python. It just does not match my experience at all. I've been a professional rust developer for about three years. Every time I look at python code, it's doing something insane where the function argument definition basically looks like line noise with args and kwargs, with no types, so it's impossible to guess what the…

The language itself is not more complex to onboard. For Scala also not. It feels great to have all these language features to ones proposal. The added complexity is in the way how expert code is written. The experts are empowered and productive, but heightens the barrier of entry for newcomers by their practices. Note that they also might expertly write more accessible code to avoid the issue, and then I agree with (though I can't compare to Python, never used it).

Re: My “grand vision” for Rust

#169

Post by aw1621107 »

hrmtst93837 wrote: post #158
zozbot234 wrote: post #9

Earlier quoted context omitted.

> The language already has too many features. That's actually the point. Many of these additions can be phrased as unifying existing features and allowing them to be used in previously unusable ways and contexts. There's basically no real increase in user-perceived complexity. The Rust editions system is a key enabler of this, and C++ has nothing comparable.

[flagged]

> and they force [] libraries to support multiple modes at once,

I'm not entirely sure I agree? I don't think any library except for the standard library needs to "support multiple modes at once"; everything else just sets its own edition and can remain blissfully unaware of whatever edition its downstream consumer(s) are using.

> which is a different kind of maintenance tax than evolving C++ compilers and feature test macros impose.

I'm not sure I agree here either? Both Rust and C/C++ tooling and their standard libraries needs to support multiple "modes" due to codebases not all using the same "mode", so to me the maintenance burden should be (abstractly) the same for the two.

> Require RFCs to include an interaction test matrix, compile time and code size measurements, and a pass from rust-analyzer and clippy

IIRC rustc already tracks various compilation-related benchmarks at perf.rust-lang.org. rustc also has edition-related warnings [0] (see the rust-YYYY-compatibility groups), so you don't even need clippy/rust-analyzer.

[0]: https://doc.rust-lang.org/rustc/lints/groups.html

Re: My “grand vision” for Rust

#170

Post by zozbot234 »

conorbergin wrote: post #125
esafak wrote: post #102

Earlier quoted context omitted.

Elaborate.

I don’t think PL theory driven design produces good systems languages.

Rust as it exists today is very much "PL theory" driven. It's not necessarily a good language, but it's been consistently ranked as the #1 "most loved" by Stack Overflow for the past few years.
Post reply on HN