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

241–250 of 323 posts

Re: My “grand vision” for Rust

#241

Post by School-Cotton »

9rx wrote: post #224
baby wrote: post #109

Earlier quoted context omitted.

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 does have sum types — but the syntax is awkward and a bit transparent, so many don't recognize it as being there, and those that do don't love using it.

Can you enlighten us to what you’re talking about instead of vagueposting like this? What’s the supposed way of simulating sum types in go?

Re: My “grand vision” for Rust

#242

Post by 3836293648 »

bigfishrunning wrote: post #220
OptionOfT wrote: post #215

Earlier quoted context omitted.

What about doing something that Java does with the throws keyword? Would that make the checking easier?

I think that's exactly what's being asked for here (via the "panic effect" that the article refers to) although, I think i'd prefer a "doesn't panic" effect just to keep backwards compatibility (allowing functions to panic by default)

Or effect aliases. But given that it's strictly a syntactic transformation it seems like make the wrong default today, fix it in the next edition. (Editions come with tools to update syntax changes)

Re: My “grand vision” for Rust

#243

Post by 9rx »

School-Cotton wrote: post #241
9rx wrote: post #224

Earlier quoted context omitted.

Go does have sum types — but the syntax is awkward and a bit transparent, so many don't recognize it as being there, and those that do don't love using it.

Can you enlighten us to what you’re talking about instead of vagueposting like this? What’s the supposed way of simulating sum types in go?

I am not sure how would you would simulate them. With enums and structs, I suppose?

However, it also has true sum types:

    type SumType interface { isSumType() }
    type A string
    func (A) isSumType()
    type B int
    func (B) isSumType()
But as you can see the syntax leaves a lot to be desired and may not be all that obvious to those who are hung up thinking in other languages.

Re: My “grand vision” for Rust

#244

Post by harpiaharpyja »

olalonde wrote: post #135
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…

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.

I mean, you're asking for a fundamentally different directing for the language with different tradeoffs? Why are you commenting on an article about Rust? Not everyone wants the same tradeoffs that you do.

Re: My “grand vision” for Rust

#245

Post by satvikpendem »

Rusky wrote: post #58
satvikpendem wrote: post #21

Earlier quoted context omitted.

Yoshua works directly on developing the language, and mentions he is working on these features specifically (he is part of the effects initiative), I'm not sure you won't see these features in Rust.

Yoshua is part of the "loud contingent" being described. He's not on the lang team, and he's been "working on" things like keyword generics for years without any indication that they are going to make it into the language.

> We (Oli, Niko, and Yosh) are excited to announce the start of the Keyword Generics Initiative, a new initiative 1 under the purview of the language team

https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...

Maybe he's not on the language team (I haven't read enough into Rust governance structures to know definitively) but it's not like he's on some random person working on this. And yes, work takes time, I actually disagreed with his initial approach where his syntax was to have a bunch of effects before the function name, and everyone rightly mentioned how messy it was. So they should be taking it slow anyway.

Re: My “grand vision” for Rust

#246

Post by lsuresh »

There are some solid ideas here and would definitely apply to the IVM engine we're building. I'm curious if some of these effects could play a role in faster rust compilation times (e.g. nopanic..)?

Re: My “grand vision” for Rust

#247

Post by throwaw3y »

IshKebab wrote: post #213
awesan wrote: post #151

Earlier quoted context omitted.

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.

The problem isn't implicit things happening. He's talking about this problem. Can this code panic? foo(); You can't easily answer that in Rust or Zig. In both cases you have to walk the entire call graph of the function (which could be arbitrarily large) and check for panics. It's not feasible to do by hand. The compiler could do it though.

"Panic-free" labels are so difficult to ascribe without being misleading because temporal memory effects can cause panics. Pusher too much onto your stack because the function happened to be preceded by a ton of other stack allocations? Crash. Heap too full and malloc failed? Crash. These things can happen from user input, so labelling a function no_panic just because it doesn't do any unchecked indexing can dangerously mislead readers into thinking code can't crash when it can.

Re: My “grand vision” for Rust

#249

Post by thomasmg »

ivanbakel wrote: post #196
awesan wrote: post #172

Earlier quoted context omitted.

In Zig, dividing by 0 does not panic unless you decide that it should or go out of your way to use unsafe primitives [1]. Same for trying to allocate more memory than is available. The general difference is as follows (IMO): Rust tries to prevent developers from doing bad things, then has to include ways to avoid these checks for cases where it cannot prove that bad things are actually OK. Zig (and many others such a…

Could you clarify what's going on in the Zig docs[0], then? My reading of them is that Zig definitely allows you to try to divide by 0 in a way the compiler doesn't catch, and this results in a panic at runtime. I'd be interested if this weren't true, since the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; i…

> the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; incredibly cumbersome or underperformant type systems/analyses which ensure that denominators are never 0.

I don't think it's very cumbersome if the compiler checks if the divisor could be zero. Some programming languages (Kotlin, Swift, Rust, Typescript...) already do something similar for possible null pointer access: they require that you add a check "if s == null" before the access. The same can be done for division (and remainder / modulo). In my own programming language, this is what I do: you can not have a division by zero at runtime, because the compiler does not allow it [1]. In my experience, integer division by a variable is not all that common in reality. (And floating point division does not panic, and integer division by a non-zero constant doesn't panic either). If needed, one could use a static function that returns 0 or panics or whatever is best.

[1] https://github.com/thomasmueller/bau-lang/blob/main/README.m...

Re: My “grand vision” for Rust

#250

Post by zozbot234 »

throwaw3y wrote: post #247
IshKebab wrote: post #213

Earlier quoted context omitted.

The problem isn't implicit things happening. He's talking about this problem. Can this code panic? foo(); You can't easily answer that in Rust or Zig. In both cases you have to walk the entire call graph of the function (which could be arbitrarily large) and check for panics. It's not feasible to do by hand. The compiler could do it though.

"Panic-free" labels are so difficult to ascribe without being misleading because temporal memory effects can cause panics. Pusher too much onto your stack because the function happened to be preceded by a ton of other stack allocations? Crash. Heap too full and malloc failed? Crash. These things can happen from user input, so labelling a function no_panic just because it doesn't do any unchecked indexing can dangerou…

There's plenty of independent interest in properly bounding stack usage because this would open up new use cases in deep embedded and Rust-on-the-GPU. Basically, if you statically exclude unbounded stack use, you don't even need memory protection to implement guard pages (or similar) for your call stack usage, which Rust now requires. But this probably requires work on the LLVM side, not just on Rust itself.

Failable memory allocations are already needed for Rust-on-Linux, so that also has independent interest.

Post reply on HN