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

301–310 of 323 posts

Re: My “grand vision” for Rust

#301

Post by sam0x17 »

QuantumNoodle wrote: post #261
abeppu wrote: post #235

Earlier quoted context omitted.

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

Sorry I don't understand. The result we all want is at compile-time ensuring some behavior cannot happen during runtime. OP argues we need for features built into the language, I am trying to understand what behavior we cannot achieve with the current primatives. So far the only compelling argument is embedded applications have different requirements (that I personally cannot speak to) that separate their use case fr…

For example, in substrate-based blockchains if you panic in runtime code, the chain is effectively bricked, so they use hundreds of clippy lints to try to prevent this from happening, but you can only do so much statically without language level support. There are crates like no_panic however they basically can't be used anywhere there is dynamic memory allocation because that can panic.

Same thing happens in real time trading systems, distributed systems, databases, etc., you have to design some super critical hot path that can never fail, and you want a static guarantee that that is the fact.

Re: My “grand vision” for Rust

#302

Post by hocuspocus »

palata wrote: post #204
hocuspocus wrote: post #100

Earlier quoted context omitted.

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…

You can run Scala on Android and it's been done but it never worked well nor was given priority. Which is understandable as the commercial entities behind Scala already struggle to build the ecosystem and tooling in spaces where the language shines.

For instance the Android runtime has chronically lagged behind mainline JVM bytecode versions, iirc once Scala started to emit Java 8 bytecode, Android was stuck on Java 6.

Kotlin had other obvious advantages on Android like its thin standard library or the inlining of higher-order functions.

Re: My “grand vision” for Rust

#304

Post by VorpalWay »

pjmlp wrote: post #298
VorpalWay wrote: post #288

Earlier quoted context omitted.

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.

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

Not sure what you mean here. For Rust there is only one de facto compiler currently, though work is ongoing on gccrs (not to be confused with rustc_codegen_gcc, which only replaces the llvm backend but keeps the rest of the compiler the same). Work is also ongoing on an official spec. But as it currently stands there are no compiler specific extensions.

If you meant the attribute I mentioned for embassy? That is just processed by a rust proc-macro, similar to derives with serde is used to generate (de)serialisation code. It too adds custom attributes on members.

Re: My “grand vision” for Rust

#305

Post by Rusky »

satvikpendem wrote: post #245
Rusky wrote: post #58

Earlier quoted context omitted.

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

The thing is that anyone can show up and spend time discussing ideas in Rust project spaces. From the outside it is easy to confuse that with actual movement toward landing changes in the language.

(The communication aspect of this is something that has bothered me many times in the past- even people who are lang team members often phrase things in a way that makes it sound like something is on its way in, when it's still just in the stage of "we're kinda noodling with ideas.")

Re: My “grand vision” for Rust

#306

Post by kbolino »

School-Cotton wrote: post #252
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.

interfaces in go aren’t types, so no, that’s not a sum type, it’s just an interface. The set of objects that can fulfill that interface is not just string and int, it’s anything in the world that someone might decide to write an isSumType function for.

Interfaces in Go are structurally typed but they're still types. A variable of an interface type has two components: a pointer to its dynamic type information, including virtual method table, and a pointer to its value. When you consider that any compiled Go program has a finite set of known types concretely implementing each of its interfaces, they essentially become discriminated unions, albeit without Rust's compact inline representation (unless the dynamic type is itself a thin pointer).

Re: My “grand vision” for Rust

#307

Post by jbritton »

estebank wrote: post #108
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…

> got stuck on this task with misleading error messages for the longest time. Could you elaborate on that? We consider misleading error messages to be bugs and would like to know more on case we could fix them.

It appears the error message has been improved.

Re: My “grand vision” for Rust

#308

Post by wtetzner »

jstanley wrote: post #303
wtetzner wrote: post #75

Earlier quoted context omitted.

Can you explain how this is relevant here?

Adding a new feature to unify existing features is perfectly isomorphic to defining a new standard to unify existing standards.

It's not though, unless the new feature and existing features continue to exist as disjoint things. If the new feature subsumes the old ones, then you've reduced the number of features in the language.

Re: My “grand vision” for Rust

#309

Post by nsm »

wewewedxfgdf wrote: post #68

No-one ever has the "Grand Vision" to cut something down to it's essential 25% and delete the rest.

https://without.boats/blog/revisiting-a-smaller-rust/

I think there is a programming language hole for a Rust-like language, but with GC and green threads. One that dispenses with single-ownership, and async/await footguns.

Something like F#/Kotlin is closest in terms of developer experience.

Unfortunately, we are really lacking a language that skews badly on some other axis

- F# - tainted by being Windows only for really long and being Microsoft. - Kotlin - tainted by the JVM - Java 24+ - has virtual threads, sum types, match expressions and other niceties, but tainted by the JVM again (Verbosity included, but this is not really a factor with IDEs and LLMs.)

Note that the opinions above are not mine, but "consensus". I'd say they are all unfair opinions.

I feel like people end up favoring new languages, simply because of novelty. Like, inevitably, somebody is gonna say Gleam. I'm all for having existing BEAM users getting access to new languages, but I'm not sure why one would pick a BEAM language for non-server applications when the developer tooling story for CLI apps, line-of-business apps and so on is so much stronger for the .NET and JVM ecosystems. No offense to the Gleam folks intended.

Re: My “grand vision” for Rust

#310

Post by aw1621107 »

12_throw_away wrote: post #300
aw1621107 wrote: post #212

Earlier quoted context omitted.

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

Sure, but those are arguably more like implementation details as far as end users are concerned, aren't they? At least off the top of my head I'd imagine tokio would require Send + Sync for tasks due to its work-stealing architecture regardless of whether it uses Wake or RawWaker/RawWakerVTable internally.

I find it interesting that there's relatively recent discussion about adding LocalWaker back in [0] after it was removed [1]. Wonder what changed.

[0]: https://github.com/rust-lang/libs-team/issues/191

[1]: https://github.com/aturon/rfcs/pull/16

Post reply on HN