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

201–210 of 323 posts

Re: My “grand vision” for Rust

#201

Post by Turskarama »

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…

More specifically, Zig will return an error type from the division and if this isn't handled THEN it will panic, kind of like an exception except it can be handled with proper pattern matching.

Re: My “grand vision” for Rust

#202

Post by scottlamb »

jbritton wrote: post #99

When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the ker…

`std::net::TcpStream`? Interestingly, it doesn't need to be mutable if you know the trick.

* It implements `Write` for `TcpStream` which is likely what you were using. And `Write` requires `&mut`, probably because the same trait is used for writing to application buffers (e.g. through `BufWriter` or just to a `Vec`). So this doesn't compile: [2] I think the error message is pretty good; maybe it's improved since you tried. It doesn't though suggest the trick below.

* It also implements `Write` for `&TcpStream`. So if you use the awkward phrasing `(&stream).write_all(b"asdf")`, you don't need mutable access. [3] This allows you to use it with anything that takes the trait, without requiring mutability. You might need this if say you're reading from the socket from one thread while simultaneously writing to it from another thread.

It's a vaguely similar situation with the most common async equivalent, `tokio::net::TcpStream`. The most straightforward way to write to it is with a trait that needs mutable access, but it is possible to write to a shared reference by not using a trait. They also have these `split` and `into_split` methods to get mutable access to something that implements the read traits and something that implements the write traits.

[1] https://doc.rust-lang.org/std/net/struct.TcpStream.html

[2] https://play.rust-lang.org/?version=stable&mode=debug&editio...

[2] https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: My “grand vision” for Rust

#203

Post by devnullbrain »

simplesocieties wrote: post #124
undeveloper wrote: post #120

I'm not sure why people are so deeply scared. these are all pretty neat features for people who will need them (off rip seemingly mostly in the embedded world). It's not like the inclusion of these forces you to use them — I've never had to deal with unsafe rust for shipping web stuff, and I highly doubt I'd have to deal with most of these. For modeling's sake it would be nice to have pattern types and view types, I…

This was the exact same argument used to push new c++ features and look where the language is now.

...a far better place than 2011.

Re: My “grand vision” for Rust

#204

Post by palata »

hocuspocus wrote: post #100
palata wrote: post #97

Earlier quoted context omitted.

> JetBrains also wants to make Kotlin target every platform under the sun So did Scala long before. It's just that Kotlin got a lot more traction for different reasons.

Not to the same extent. Scala.JS and Kotlin.JS are somewhat comparable, other targets not so much. There was no serious attempt at making Scala target mobile devices, even during the window of opportunity with Scala on Android.

> even during the window of opportunity with Scala on Android.

I don't understand this. You can run any pure Java jar on Android, pretty sure you can do that with Scala too? It's not exactly a "different platform" in terms of programming language. Sure it needs tooling and specific libraries, but that's higher level than the programming language.

Jetbrains is doing interop with Swift (Kotlin -> ObjC -> Swift and more recently Kotlin -> C -> Swift), which Scala never did. But I don't really see how this is relevant in this conversation.

Re: My “grand vision” for Rust

#205

Post by gpderetta »

simplesocieties wrote: post #124
undeveloper wrote: post #120

I'm not sure why people are so deeply scared. these are all pretty neat features for people who will need them (off rip seemingly mostly in the embedded world). It's not like the inclusion of these forces you to use them — I've never had to deal with unsafe rust for shipping web stuff, and I highly doubt I'd have to deal with most of these. For modeling's sake it would be nice to have pattern types and view types, I…

This was the exact same argument used to push new c++ features and look where the language is now.

you mean better than ever?

Re: My “grand vision” for Rust

#206

Post by devnullbrain »

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…

A state machine is a perfect example of a case where you would benefit from linear types.

Some things just need precise terminology so humans can communicate about them to humans without ambiguity. It doesn't mean they're inherently complex: the article provides simple definitions. It's the same for most engineering, science and language. One of the most valuable skills I've learned in my career is to differentiate between expressions, statements, items, etc. - how often have you heard that the hardest problem in software development is coordinating with other developers? If you learn proper terminology, you can say exactly what you mean. Simple language doesn't mean more clear.

I wasn't born knowing Rust, I had to learn it. So I'm always surprised by complaints about Rust being too complex directed at the many unremarkable people who have undergone this process without issues. What does it say, really? That you're not as good as them at learning things? In what other context do software people on the internet so freely share self-doubt?

I also wonder about their career plans for the future. LLMs are already capable of understanding these concepts. The tide is rising.

Re: My “grand vision” for Rust

#207

Post by secondcoming »

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.

Then why are you using rust for these tasks?

Re: My “grand vision” for Rust

#208

Post by secondcoming »

Animats wrote: post #24

This may be too much advanced type theory for a useful language. You can go all the way to formal verification. This is not enough for that. Or you can stop at the point all memory error holes have been plugged. That's more useful. You can go way overboard with templates/macros/traits/generics. Remember C++ and Boost. I understand that Boost is now deprecated. I should work some more on my solution to the back-refere…

Boost is stronger than ever.

Re: My “grand vision” for Rust

#209

Post by krautsauer »

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 "caveats" section in its docs hints at it, but to be explicit: no_panic is a band-aid that can break when changing optimizer options or compiler/llvm version. It's not a good option for library crates, e.g.

That being said, I'm not at all happy with all the complexity and ecosystem fragmentation that async brought. I understand what you're saying. But surprise panics is a bit of a pain point for me.

Re: My “grand vision” for Rust

#210

Post by lionkor »

ozgrakkurt wrote: post #192
aw1621107 wrote: post #166

Earlier quoted context omitted.

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

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

You can do rust async by moving instead of sharing data, for example
Post reply on HN