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

311–320 of 323 posts

Re: My “grand vision” for Rust

#311

Post by thomasmg »

rapnie wrote: post #299
thomasmg wrote: post #251

Earlier quoted context omitted.

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.

Well, the parent wrote "I honestly just don't believe that Rust is more complex to onboard to compared to languages like Python." And you wrote "The language itself is not more complex to onboard." So... to contract Rust with Scala, I think it's clearer to write "The language itself is not more complex to onboard _than Scala_."

To that, I completely agree! Scala is one of the most complex languages, similar to C++. In terms of complexity (roughly the number of features) / hardness to onboard, I would have the following list (hardest to easiest): C++, Scala, Rust, Zig, Swift, Nim, Kotlin, JavaScript, Go, Python.

Re: My “grand vision” for Rust

#312

Post by pjmlp »

VorpalWay wrote: post #304
pjmlp wrote: post #298

Earlier quoted context omitted.

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

It means that being constrained to C compiler dialect for tiny CPUs instead of ISO C proper, or being constrained to [no_std] instead of the whole Rust capabilities and ecosystem, isn't seen under the same light as when it is C++, Swift, Go, Java or whatever else might also be constrained for the same purpose.

Re: My “grand vision” for Rust

#313

Post by baroudi »

Introducing more colors (or effects) without a way to abstract over them will cause a lot of issues. It is already painful to work with async, one have to either accept a lot of code duplication or to perform some obscure black magic with the macro system.

Also, the language is already inelegant with each monad having its own syntactic sugar (result, option and async).

Re: My “grand vision” for Rust

#314

Post by mananaysiempre »

OptionOfT wrote: post #215
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.

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

Something like that, except you probably also want to be able to express things like “whatever the callback I’m passed can throw, I can throw all of that and also FooException”. And correctly handle the cases when the callback can throw FooException itself, and when one of the potential exceptions is dependent on a type parameter, and you see how this becomes a whole thing when done properly. But it’s doable.

Re: My “grand vision” for Rust

#315

Post by [deleted] »

thomasmg wrote: post #249
ivanbakel wrote: post #196

Earlier quoted context omitted.

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

[deleted]

Re: My “grand vision” for Rust

#316

Post by ivanbakel »

thomasmg wrote: post #249
ivanbakel wrote: post #196

Earlier quoted context omitted.

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

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

For Rust, this is not accurate (though I don't know for the other languages). The type system instead simply enforces that pointers are non-null, and no checks are necessary. Such a check appears if the programmer opts in to the nullable pointer type.

The comparison between pointers and integers is not a sensible one, since it's easy to stay in the world of non-null pointers once you start there. There's no equivalent ergonomics for the type of non-zero integers, since you have to forbid many operations that can produce 0 even on non-0 inputs (or onerously check that they never yield 0 at runtime).

>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... In my experience, integer division by a variable is not all that common in reality

That's another option, but I hardly find it a real solution, since it involves the programmer inserting a lot of boilerplate to handle a case that might actually never come up in most code, and where a panic would often be totally fine.

Coming back to the actual article, this is where an effect system would be quite useful: programmers who actually want to have their code be panic-free, and who therefore want or need to insert these checks, can mark their code as lacking the panic effect. But I think it's fine for division to be exposed as a panicking operation by default, since it's expected and not so annoying to use.

Re: My “grand vision” for Rust

#317

Post by VorpalWay »

pjmlp wrote: post #312
VorpalWay wrote: post #304

Earlier quoted context omitted.

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

It means that being constrained to C compiler dialect for tiny CPUs instead of ISO C proper, or being constrained to [no_std] instead of the whole Rust capabilities and ecosystem, isn't seen under the same light as when it is C++, Swift, Go, Java or whatever else might also be constrained for the same purpose.

Hm, I haven't come across such sentiment. It is fairly well understood that if you use C++ for example on embedded, you are limited as to what features you can use. I remember coming across that when using PlatformIO for Arduino many years ago, certain parts of STL was just missing.

The other languages you mentioned I have no personal experience of in embedded (and hardly outside embedded either), but I understand they are less common (apart from Java possibly, but only in certain niches). There is also Ada/SPARK and MicroPython (which always seemed more like an educational thing for people new to programming). I haven't used either.

I would like to add that it feels like no-std rust is less constrained than freestanding C to me. I haven't managed to figure out why exactly. Perhaps the ecosystem of crates in Rust for embedded is just better, with many crates offering a way to opt out of the std-parts (plus a number of good libraries aimed directly at no-std). Perhaps it is that it is easy to add alloc to no-std if you are working on a higher end embedded system (with obvious tradeoffs in code size, memory usage etc). Or perhaps the no-std parts of rust simply contains more than freestanding C.

Re: My “grand vision” for Rust

#318

Post by jk-pasha »

There’s one other way to look at it - in the age of vibe coding it makes sense to make the language more safe. Easier for the AI not to shoot itself in the foot.

But we’re gonna need better tools for reading this new denser code packed with gotchas. That’s for sure.

Re: My “grand vision” for Rust

#319

Post by rapnie »

thomasmg wrote: post #311
rapnie wrote: post #299

Earlier quoted context omitted.

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

Well, the parent wrote "I honestly just don't believe that Rust is more complex to onboard to compared to languages like Python." And you wrote "The language itself is not more complex to onboard." So... to contract Rust with Scala, I think it's clearer to write "The language itself is not more complex to onboard _than Scala_." To that, I completely agree! Scala is one of the most complex languages, similar to C++. I…

I see the confusion. ChadNauseam mentions Python to another comment of mine, where I mentioned Gleam. In your list hardest-to-easiest perhaps Gleam is even easier than Python. They literally advertise it as "the language you can learn in a day".

Re: My “grand vision” for Rust

#320

Post by jstanley »

wtetzner wrote: post #308
jstanley wrote: post #303

Earlier quoted context omitted.

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.

The same is true of standards.
Post reply on HN