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

291–300 of 323 posts

Re: My “grand vision” for Rust

#291

Post by simonask »

gf000 wrote: post #223
simonask wrote: post #78

Earlier quoted context omitted.

I would also have liked to see some motivational examples, but I think the most interesting upside of an effect system is composability. Rust is actually really unique among imperative languages in its general composability - things just compose really well across most language features. The big missing pieces for composability are higher-kinded types (where you could be generic over Option, Result, etc.), and effect…

> Rust is actually really unique among imperative languages in its general composability Can you compare it to some other imperative language? Because I really don't see anything particularly notable in Rust that would give it this property.

I’m mainly comparing to the progeny of C, where the biggest difference is the fact that almost everything is an expression in Rust.

No need for ternary operators. C# unsafe blocks can only appear as statements (so you cannot delegate from a safe to an unsafe constructor, e.g.). C++ cannot return from the middle of an expression.

A related aspect is the type system, which composes with expressions in really interesting ways, so things like constant array sizes can be inferred.

Re: My “grand vision” for Rust

#292

Post by andriy_koval »

chirsz wrote: post #142
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…

You can see: * no-panic: https://docs.rs/no-panic/latest/no_panic/ * Safe Rust has no undefined behavior: https://news.ycombinator.com/item?id=39564755

would be great to have no alloc too as op requested.

Re: My “grand vision” for Rust

#293

Post by [deleted] »

kbolino wrote: post #286
Horusiath wrote: post #130

Earlier quoted context omitted.

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

[deleted]

Re: My “grand vision” for Rust

#294

Post by wasabi991011 »

Folcon wrote: post #259
kibwen wrote: post #227

Earlier quoted context omitted.

> I genuinely struggled to follow the concepts in this article I read the HN comments before I read the OP, which made me worry that the post was going to be some hifalutin type wonkiness. But instead the post is basically completely milquetoast, ordinary and accessible. I'm no type theorist--I cannot tell you what a monad is--and I confess that I don't understand how anyone could be intimidated by this article.

I think you're underestimating your competency Things like effects aren't obvious to people, at least based on my experience of trying to teach it to people

I don't agree, the article isn't going deep into effects.

The intro where they describe effects as essentially being "function colors" (referring to another article fairly often linked in hackernews) plus give lots of concrete examples (async, const, try) seems like more than enough to be obvious to the readers.

Re: My “grand vision” for Rust

#295

Post by andriy_koval »

63stack wrote: post #199
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 don't think this is an old man rant, I think you made a reasonable argument. Rust is certainly at risk of becoming just as complex as c++. I would love to introduce more rust at work, but I dread that someone is going to ask about for , use , differences between impl X vs Box , or Pin/Unpin, and I don't have proper answers either.

> but I dread that someone is going to ask about for, use, differences between impl X vs Box, or Pin/Unpin, and I don't have proper answers either.

its an issue in "someone", all those answers can be received in under 1min from AI.

Re: My “grand vision” for Rust

#296

Post by MaulingMonkey »

Turskarama wrote: post #219
ben-schaaf wrote: post #214

Earlier quoted context omitted.

I can't find anything related to division returning an error type. Looking at std.math.divExact, rem, mod, add, sub, etc. it looks to me like you're expected to use these if you don't want to panic.

Actually you're right, I was going by the source code which was in the link of the comment you replied to, but I missed that that was specifically for divExact and not just primitive division.

(Rust has a similar fn: https://doc.rust-lang.org/std/primitive.isize.html#method.ch... )

Re: My “grand vision” for Rust

#297

Post by andriy_koval »

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

you can use smart pointers everywhere and stop be bothered by borrow checker.

Re: My “grand vision” for Rust

#298

Post by pjmlp »

VorpalWay wrote: post #288
pjmlp wrote: post #284

Earlier quoted context omitted.

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

PTC and Aicas aren't Java on smartcards, they are Java on high integrity computing where human lives might be at stake.

Interesting how compiler specific extensions are ok for C, with a freestanding subset, or Rust no_std, but when it goes to other languages it is no longer the same.

I stand corrected on async Rust then.

Re: My “grand vision” for Rust

#299

Post by rapnie »

thomasmg wrote: post #251
rapnie wrote: post #168

Earlier quoted context omitted.

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

Hm, you claim that Rust and Scala are not more complex to onboard than Python... but then you say you never used Python? If that's the case, how do you know? Having used both, I do think Rust is harder to onboard, just because there is more syntax that you need to learn. And Rust is a lot more verbose. And that's before you are exposed to the borrow checker.

I am not mentioning Python at all. I contrasted Rust with Scala.

Re: My “grand vision” for Rust

#300

Post by 12_throw_away »

aw1621107 wrote: post #212
ozgrakkurt wrote: post #192

Earlier quoted context omitted.

"Tight control over memory use" sounds wrong considering every single allocation in rust is done through the global allocator. And pretty much everything in rust async is put into an Arc. I don't understand what kind of use case they were optimizing for when they designed this system. Don't think they were optimizing only for embedded or similar applications where they don't use a runtime at all. Using stackfull coro…

> "Tight control over memory use" sounds wrong considering every single allocation in rust is done through the global allocator. In the case of Rust's async design, the answer is that that simply isn't a problem when your design was intentionally chosen to not require allocation in the first place. > And pretty much everything in rust async is put into an Arc. IIRC that's more a tokio thing than a Rust async thing in…

> > And pretty much everything in rust async is put into an Arc.

> IIRC that's more a tokio thing than a Rust async thing in general. Parts of the ecosystem that use a different runtime (e.g., IIRC embassy in embedded) don't face the same requirements.

Well, if you're implementing an async rust executor, the current async system gives you exactly 2 choices:

1) Implement the `Wake` trait, which requires `Arc` [1], or

2) Create your own `RawWaker` and `RawWakerVTable` instances, which are gobsmackingly unsafe, including `void*` pointers and DIY vtables [2]

[1] https://doc.rust-lang.org/std/task/trait.Wake.html

[2] https://doc.rust-lang.org/std/task/struct.RawWaker.html

Post reply on HN