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

281–290 of 323 posts

Re: My “grand vision” for Rust

#281

Post by Levitating »

xorvoid wrote: post #278

I'm pretty conflicted on this comment section. A lot of people are expressing a lot of fear of C++ bloat. I get that. I'm not sure what the right answer for Rust is, but I'm fairly convinced that these type system ideas are the future of programming languages. Perhaps it can be added to rust in a reasonable and consistent way that doesn't ultimately feel like a kludgy language post-hoc bolt on. Time will tell. There…

> There is a serious risk to getting it wrong and making the language simply more complicated for no gain.

I think the Rust team/community is well-aware of this. Which is why Rust has such a well-defined RFC life-cycle.

At the other end, one of the biggest complaints about Rust is that many features seem eternally locked behind nightly feature gates.

Re: My “grand vision” for Rust

#282

Post by xorvoid »

Levitating wrote: post #281
xorvoid wrote: post #278

I'm pretty conflicted on this comment section. A lot of people are expressing a lot of fear of C++ bloat. I get that. I'm not sure what the right answer for Rust is, but I'm fairly convinced that these type system ideas are the future of programming languages. Perhaps it can be added to rust in a reasonable and consistent way that doesn't ultimately feel like a kludgy language post-hoc bolt on. Time will tell. There…

> There is a serious risk to getting it wrong and making the language simply more complicated for no gain. I think the Rust team/community is well-aware of this. Which is why Rust has such a well-defined RFC life-cycle. At the other end, one of the biggest complaints about Rust is that many features seem eternally locked behind nightly feature gates.

I feel the same confliction about this organizational policy. It has been refreshing that they haven't just jammed half-baked ideas into stable like C++ has done for decades. But, yes, it's frustrating to bump into an issue and discover that a fix has been proposed and implemented but has never been moved to stable in 5-10 years. Some things feel like they're languishing in nightly forever.

I don't personally have a solution to propose to this problem. I generally appreciate their caution and long-term considering. It's refreshing coming from C++. I suppose one could argue that they've overcorrected in the other direction. Unclear.

Deeper than that, I think there's a philosophical dispute on whether languages should or shouldn't even evolve. There are people with C-stability type thinking that would argue that long-term stability is so important that we should stop making changes and etch things into stone. There is some merit to that (a lot of unhelpful churn in modern programming). But, failure to modernize is eventually death IMHO. I think C is slowly dying because of exactly this. It will take quite a while because it is critical computing infrastructure. But, few people remain that defend it's viability. The arguments that remain are of the form "we simply don't have a viable replacement yet".

Perhaps you can even take the view that this is the lifecycle of programming languages. They're not supposed to live forever. That could be a reasonable take. But then you really have to confront the problem of code migration from old languages to new languages. That is a very very hard unsolved problem (e.g. see: COBOL).

Language evolution is foundationally a hard problem. And I'm not unhappy with Rust's approach. I think no one has managed to find an ideal approach.

Re: My “grand vision” for Rust

#283

Post by aw1621107 »

QuantumNoodle wrote: post #260
aw1621107 wrote: post #230

Earlier quoted context omitted.

> Could you share a situation where the behavior is necessary? The effects mentioned in the article are not too uncommon in embedded systems, particularly if they are subject to more stringent standards (e.g., hard realtime, safety-critical, etc.). In such situations predictability is paramount, and that tends to correspond to proving the absence of the effects in the OP.

Ah, the embedded application. Very valid point. I'm guilty of forgetting about that discipline. I do wonder if it is possible to bin certain features to certain, uh, distributions(?), of rust? I'm having trouble articulating what I mean but in essence so users do not get tempted to use all these bells and whistles when they are aimed at a certain domain or application? Or are such language features beneficial for all…

I guess the no_std/alloc/std split is sort of like what you're talking about? It's not an exact match though; I think that split is more borne out of the lack of built-in support some targets have for particular features rather than trying to cordon off subsets of the language to try to prevent users from burning themselves.

On that note, I guess one could hypothetically limit certain effects to certain Rust subsets (for example, an "allocates" effect may require alloc, a "filesystem" effect may require std, etc.), but I'd imagine the general mechanism would need to be usable everywhere considering how foundational some effects can be.

> Or are such language features beneficial for all applications?

To (ab)use a Pixar quote, I suppose one can think of it as "not all applications may need these features, but these features should be usable anywhere".

Re: My “grand vision” for Rust

#284

Post by pjmlp »

VorpalWay wrote: post #280
pjmlp wrote: post #279

Earlier quoted context omitted.

PTC and Aicas would disagree there. As might microEJ, Meadows, F-Secure, Astrobe and a few others.

> PTC and Aicas would disagree there. Never heard of either. You will have to expand on your reasoning. Microcontrollers do outnumber classical computers though, that is just a fact. So i don't see why there is anything to disagree about there. Even GPUs have helper microcontrollers for thermal management and other functions.

They have been selling real time bare metal Java runtimes for embedded systems, widely deployed across weapon systems in battleships and missile tracking units, factory automation, satellites, and other similar systems for the last decades.

I bet many of those helper microcontrollers, are still Assembly, compiler specific C, and if there is Rust support, most likely only no_std fits, thus no async anyway.

Re: My “grand vision” for Rust

#285

Post by chiffaa »

dtolnay wrote: post #277
chiffaa wrote: post #143

Earlier quoted context omitted.

There are ways to handle these effects without bloating up normal applications. For example, using attributes implemented as intrinsics, which wouldn't really affect anything that isn't using them. The thing is, some of these things are very useful in specific domains, and all these domains are closely related to the ideas of safety. Nondeterminism and IO are important for purity/referential transparency, which is a…

If a piece of code does not panic in panic=unwind, then it does not panic in panic=abort either. So having coverage of panic=unwind would be sufficient to guarantee that code cannot panic. The caveat you mention with panic=abort would only apply to code that is unable to build for panic=unwind, which is uncommon.

Oh, then I misremembered and misunderstood the note, my apologies

On that note, thank you for all your work!

Re: My “grand vision” for Rust

#286

Post by kbolino »

Horusiath wrote: post #130
nemothekid wrote: post #112

Earlier quoted context omitted.

I've been on both sides of the fence here - I've bounced between two camps: 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. 2. A widely used, production, systems language that implements PL-theory up until the year ~2000. (Effects, as described in this article, was a research topic in 1999). I started with (1), but as I started to get more and more exposed to (2), you s…

> 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. I was looking for something like that and eventually found Crystal ( https://crystal-lang.org ) as a closest match: LLVM compiled, strong static typing with explicit nulls and very good type inference, stackfull coroutines, channels etc.

Go does not use LLVM at all and never has. It uses its own compiler and its own (quirky) assembler. Of course, this does not matter to most people, but LLVM compilation can be both a blessing (good interop with C/FFI) and a curse (changes to LLVM internals causing issues for languages other than C/C++).

Re: My “grand vision” for Rust

#287

Post by kbolino »

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

Earlier quoted context omitted.

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.

This forms a closed set of types (A, B, nil -- don't forget nil!) but the compiler doesn't understand it as such and complains that the following type-switch is not exhaustive ("missing return"):

  func Foo(s SumType) bool {
    switch s.(type) {
    case A: return true      
    case B: return true
    case nil: return true
    }
  }
Also, you, the package author, may know what constitutes SumType, but the consumers of your package don't, at least not without source. Moreover, you can spread A, B, and any other implementations of SumType across many source files, making it hard to answer the question even with source. This is even a problem for the standard library, just consider go/ast and its Decl, Expr, and Stmt interfaces, none of which document what types actually implement them.

Re: My “grand vision” for Rust

#288

Post by VorpalWay »

pjmlp wrote: post #284
VorpalWay wrote: post #280

Earlier quoted context omitted.

> PTC and Aicas would disagree there. Never heard of either. You will have to expand on your reasoning. Microcontrollers do outnumber classical computers though, that is just a fact. So i don't see why there is anything to disagree about there. Even GPUs have helper microcontrollers for thermal management and other functions.

They have been selling real time bare metal Java runtimes for embedded systems, widely deployed across weapon systems in battleships and missile tracking units, factory automation, satellites, and other similar systems for the last decades. I bet many of those helper microcontrollers, are still Assembly, compiler specific C, and if there is Rust support, most likely only no_std fits, thus no async anyway.

Java on smartcard etc is a thing. I haven't met anyone who used that and actually like it. And it is apparently nothing like normal java.

Many microcontrollers are indeed still running C, but things are starting to change. Esperif has official support for Rust for example, and other vendors are experimenting with that too. Many other microcontrollers have good community support.

> if there is Rust support, most likely only no_std fits, thus no async anyway.

This is just plain incorrect. The beauty of async in rust is that it does work on no_std. You don't need an allocator even to use Embassy. Instead becuause async tasks are perfectly sized, you can reserve space statically at compile time, you just need to specify with an attribute how many concurrent instances of a given task should be supported.

Re: My “grand vision” for Rust

#289

Post by 9rx »

kbolino wrote: post #287
9rx wrote: post #243

Earlier quoted context omitted.

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.

This forms a closed set of types (A, B, nil -- don't forget nil!) but the compiler doesn't understand it as such and complains that the following type-switch is not exhaustive ("missing return"): func Foo(s SumType) bool { switch s.(type) { case A: return true case B: return true case nil: return true } } Also, you, the package author, may know what constitutes SumType, but the consumers of your package don't, at lea…

> but the compiler doesn't understand ...

Right — While it does has sum types, it doesn't have some other features found in other languages.

But, of course, if one wanted those features they would talk about those features. In this discussion, we're talking specifically about sum types, which Go most definitely does have.

> nil -- don't forget nil!

This is why alternative syntax has never been added. Nobody can figure out how to eliminate nil or make it clear that nil is always part of the set in a way that improves upon the current sum types.

Re: My “grand vision” for Rust

#290

Post by simonask »

mrsmrtss wrote: post #197
simonask wrote: post #175

Earlier quoted context omitted.

You speak in the past tense, but .NET 11 is not released yet at time of writing. Runtime-async is not the current reality.

True, it's in preview currently, but actually .NET is already very efficient with async today also - https://hez2010.github.io/async-runtimes-benchmarks-2024/ (.NET9 tested here).

Sure, it’s really fine for what it does, but it is not significantly easier to deal with than Rust async, and remains fundamentally unsuited in several scenarios where Rust async works really well.
Post reply on HN