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

231–240 of 323 posts

Re: My “grand vision” for Rust

#231

Post by 9rx »

ajxs wrote: post #167
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.

Unless you are going back to CGI, web backends are systems.

Re: My “grand vision” for Rust

#232

Post by zozbot234 »

kibwen wrote: post #228
ChadNauseam wrote: post #155

Earlier quoted context omitted.

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…

> I honestly just don't believe that Rust is more complex to onboard to compared to languages like Python. Most people conflate "complexity" and "difficulty". Rust is a less complex language than Python (yes, it's true), but it's also much more difficult, because it requires you to do all the hard work up-front, while giving you enormously more runtime guarantees.

Doing the hard work up front is easier than doing it while debugging a non-trivial system. And there are boilerplate patterns in Rust that allow you to skip the hard work while doing throwaway exploratory programming, just like in "easier" languages. Except that then you can refactor the boilerplate away and end up with a proper high-quality system.

Re: My “grand vision” for Rust

#233

Post by dilawar »

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…

> 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.

At a new job, I am writing my first microservice in golang. Used to be a Rust/C++ (kernel) and Python/PHP/JS dev (fullstack). Rust is allowed by team is heavily invested in go already.. I don't think I'll be able to convince them to learn rust! Lol

Re: My “grand vision” for Rust

#234

Post by School-Cotton »

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.

> Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic

The zig compiler can’t possibly guarantee this without knowing which parts of the code were written by you and which by other people (which is impossible).

So really it’s not “the developer” wrote the thing that does the panic, it’s “some developer” wrote it. And how is that different from rust?

Re: My “grand vision” for Rust

#235

Post by abeppu »

QuantumNoodle wrote: post #226
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…

I have no argument against using the right tool for a job. Decorating a function with a keyword to have more compile-time guarantees does sound great, but I bet it comes with strings attached that affect how it can be used which will lead to strange business logic. Anecdotally, I have not (perhaps yet) run into a situation where I needed more language features, I felt rust had enough primatives that I could adapt the…

> Could you share a situation where the behavior is necessary? I am curious if I could work around it with the current feature set.

But this kinda isn't about "behavior" of your code; it's about how the compiler (and humans) can confidently reason about your code?

Re: My “grand vision” for Rust

#236

Post by kibwen »

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.

It's clear that you don't understand the use cases that async in Rust was designed to accommodate.

> Also the ecosystem is setup so you have to use tokio and everything has to be an Arc.

It's clear that you're not at all familiar with the Rust async ecosystem, including Embassy.

Re: My “grand vision” for Rust

#237

Post by harpiaharpyja »

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…

Look, included in the concepts the article discusses are features that people have been wanting for a very long time.

Like, the ability to have multiple mut references to a struct as long as you access disjoint fields? That's amazing!!! A redo of Pin that actually composes with the rest of the language? That's pretty awesome too.

I think you're getting tied up because the the author is describing these features in a very formal way. But someone has to think about these things, especially if they are going to implement them.

Ultimately, these are features that will make Rust's safety features (which really, are Rust's reason for existing) more ergonomic and easier to use. That's the opposite of what you fear.

Re: My “grand vision” for Rust

#238

Post by room271 »

Rust needs to be careful that it doesn't invite the type-programming crowd in too much. Even if individual features are helpful, the cultural effect on the programming language in terms of the community (i.e. libraries and idioms) can really fragment and destroy a language. Scala, which I programmed in for many years, is a good example -- lots of great features but ultimately overwhelmed by typesafe abstractions that held theoretical appeal but hampered readability and fragmented the community. (Lack of backwards compatibility and poor tooling also hurt Scala no doubt about it, just as slow compile times hurt Rust.)

Re: My “grand vision” for Rust

#239

Post by kibwen »

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…

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

The vast majority of Rust programs would benefit from such validation existing in the language, even if they never bother to explicitly leverage it themselves. For example, a non-panicking effect would be beneficial for both compilation times (don't bother pessimistically emitting unwinding glue for the enormous number of functions that don't need it, only to attempt to optimize it away later) and runtime performance (the guaranteed absence of the aforementioned glue reduces potential branch points and code size, which leads to better inlining and vectorization).

Re: My “grand vision” for Rust

#240

Post by School-Cotton »

baby wrote: post #109
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…

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

Go makes it easy to read each line of code, not necessarily to understand what the system as a whole is doing.
Post reply on HN