Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Easy Mode Rust

llogiq.github.io

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Easy Mode Rust

#31

Post by MuffinFlavored »

ojosilva wrote: post #29

This: > add .await after every function call, and then remove it again wherever the compiler complains Should be something Rust (and JS runtimes!) should somehow check/complain. It's just too easy to forget to await on a function returning a Future/Promise. Rust at least will complain if the returning types don't match some expected value and hint a helpful "help: consider `await`ing on the `Future`". Typescript, wel…

> It's just too easy to forget to await on a function returning a Future/Promise.

Is there not a way with linting configurations to bump this warning to a "compile time error" (unless marked ignore or something)?

Re: Easy Mode Rust

#32

Post by kbolino »

oconnor663 wrote: post #4
herecomethefuzz wrote: post #2

Cool cheatsheet. As someone new to Rust, what are the benefits versus Go, C++, and C?

Rust can: - Do the things C and C++ can do. - Without the memory corruption issues those languages are infamous for. - With the conveniences you'd expect of any post-internet language. (A library ecosystem that's unified around a standard build system and package manager, an async IO story, UTF-8 strings, etc.)

Rust does not have offsetof (the real deal, not some pointer-based hack in a third-party crate) and using FFI to call C or C++ practically requires bindgen which is not stable, not part of the standard library, and tricky to configure in a portable way. Rust also doesn't have a stable ABI yet though slow progress is being made.

If you can write pure Rust in a single library/binary these aren't major issues but as a drop-in replacement for C/C++ in many of the areas where those languages are heavily used today, the edges can be surprisingly sharp.

Re: Easy Mode Rust

#33

Post by kbolino »

foldr wrote: post #5
herecomethefuzz wrote: post #2

Cool cheatsheet. As someone new to Rust, what are the benefits versus Go, C++, and C?

Sibling doesn't really cover the benefits vs. Go, so here's my attempt at a list. * Rust offers memory safety without a GC. You may or may not want a GC. If you don't, then Rust is the better option. * More broadly, Rust has a C++-like focus on providing zero cost abstractions. Go is generally happy to accept a small runtime cost for abstraction. * Rust can generate small WASM targets because it doesn't need to bundl…

Good summary. This also illustrates why the Go compiler is much faster than the Rust compiler: it does a lot less work, pushing problems down to run time.

Re: Easy Mode Rust

#34

Post by Galanwe »

Expurple wrote: post #27
Galanwe wrote: post #25

Earlier quoted context omitted.

> I honestly can't see a modern, programmer-friendly language not having proper discriminated union types in 2024 Does that really need to be part of the language though, or as long as you can code it, or have it in the standard library, it's fine? What can Rust's unions do that std::variant cannot?

Rust's language-level support for pattern matching (including exhaustiveness checking) is very nice. Most languages with sum types have this feature. It's hard to imagine one without the other. I haven't used `std::variant` much, but I remember finding it unergonomic. Real-world C++ code uses `std::variant` way less often than Rust/functional code uses sum types. Probably, for that reason UPDATE: also, some advantage…

I agree, the lack of pattern matching is a bummer. You should retry std::variant with the lambda overload trick though. It's kind of okay in terms of syntax.

    using MyDiscreminatedUnion = std::variant;

    MyDiscreminatedUnion var = MyType2{};

    std::visit(overload {
        [](MyType1 t1) {...},
        [](MyType2 t2) {...},
        [](auto t) {...},
   }, var);

Re: Easy Mode Rust

#35

Post by eddd-ddde »

MuffinFlavored wrote: post #31
ojosilva wrote: post #29

This: > add .await after every function call, and then remove it again wherever the compiler complains Should be something Rust (and JS runtimes!) should somehow check/complain. It's just too easy to forget to await on a function returning a Future/Promise. Rust at least will complain if the returning types don't match some expected value and hint a helpful "help: consider `await`ing on the `Future`". Typescript, wel…

> It's just too easy to forget to await on a function returning a Future/Promise. Is there not a way with linting configurations to bump this warning to a "compile time error" (unless marked ignore or something)?

Yes now a days every sensible project comes with a linter by default that will tell you when you are using a promise wrong.

Re: Easy Mode Rust

#36

Post by eddd-ddde »

kbolino wrote: post #32
oconnor663 wrote: post #4

Earlier quoted context omitted.

Rust can: - Do the things C and C++ can do. - Without the memory corruption issues those languages are infamous for. - With the conveniences you'd expect of any post-internet language. (A library ecosystem that's unified around a standard build system and package manager, an async IO story, UTF-8 strings, etc.)

Rust does not have offsetof (the real deal, not some pointer-based hack in a third-party crate) and using FFI to call C or C++ practically requires bindgen which is not stable, not part of the standard library, and tricky to configure in a portable way. Rust also doesn't have a stable ABI yet though slow progress is being made. If you can write pure Rust in a single library/binary these aren't major issues but as a d…

For those kind of applications zig can do a more close feel to C while removing some of the pains such as error handling, matching, null checks, slices, etc.

Re: Easy Mode Rust

#37

Post by ollysb »

krab wrote: post #13

The self-modifying code mentioned in the Macros section could be automated in an IDE! That is, your IDE should be able to show you the expansion of a macro at that specific place. This feature would help me much more to understand what's going on than navigation to the macro source. I'm not sure if there are any IDEs supporting (temporary) macro expansion already. The output showing all macros expanded is usually too…

For that matter it would be nice to expand any function call in place. That way you could view a full call stack in a single view.

Re: Easy Mode Rust

#38

Post by Galanwe »

Sharlin wrote: post #30
Galanwe wrote: post #25

Earlier quoted context omitted.

> I honestly can't see a modern, programmer-friendly language not having proper discriminated union types in 2024 Does that really need to be part of the language though, or as long as you can code it, or have it in the standard library, it's fine? What can Rust's unions do that std::variant cannot?

`std::variant` is very awkward to use, and has design compromises because it doesn't have language support. Besides, the ability to write something like `std::variant` as a pure library type first requires you to have a very complex type system, more complex than Rust's, and certainly more complex than a "simple" language such as C or Go would ever consider adopting. C++ is going to have pattern matching "any year no…

Right, I'm not trying to argue that std::variant is better than native language support. By definition, a language construct will always be easier to write and read.

All I'm saying is that the current state of std::variant makes it okay enough to use type safe discriminated unions.

Visit + overload is not that far away from pattern matching in terms of readability, clang does warn on non exhaustive switch cases, etc.

Re: Easy Mode Rust

#39

Post by elbear » 

    for item in items.iter() {
      if predicate(item) {
        items.push(modify(item));
      }
    }
This is not a good idea in Python either. You are better off creating a new list in which you accumulate all items, both modified and unmodified.

Re: Easy Mode Rust

#40

Post by steveklabnik »

kbolino wrote: post #32
oconnor663 wrote: post #4

Earlier quoted context omitted.

Rust can: - Do the things C and C++ can do. - Without the memory corruption issues those languages are infamous for. - With the conveniences you'd expect of any post-internet language. (A library ecosystem that's unified around a standard build system and package manager, an async IO story, UTF-8 strings, etc.)

Rust does not have offsetof (the real deal, not some pointer-based hack in a third-party crate) and using FFI to call C or C++ practically requires bindgen which is not stable, not part of the standard library, and tricky to configure in a portable way. Rust also doesn't have a stable ABI yet though slow progress is being made. If you can write pure Rust in a single library/binary these aren't major issues but as a d…

Offsetof was just stabilized btw https://doc.rust-lang.org/stable/core/mem/macro.offset_of.ht...
Post reply on HN