Rust 1.46

Dlang has had CTFE for a long time. The engine just needs to be rewritten to reduce memory usage. https://tour.dlang.org/tour/en/gems/compile-time-function-ev...

> supports a much larger set of features that even constexpr supports

This sounds promising. Can you give examples? I don't know Rust at all, and the reason I like C++ is its metaprogrammability.

I wonder why && and || are not allowed in const functions?

> All boolean operators except for && and || which are banned since they are short-circuiting.

I guess I'm missing something obvious but why does the short circuiting break const-ness?

> Anyways, I guess this gets easier over time, right?

Yes.

> Should I avoid using closures all over the place?

Not necessarily.

> Should my code look more like C and less like Haskell?

Yes. Others sometimes don't like to hear this, but IMO, Rust is not at all functional. Passing functions around is not ergonomic (how many function types does Rust have again? Three?). Even making heavy use of Traits, especially generic ones, is difficult.

Rust is very much procedural. Java-style OOP doesn't work because of the borrowing/ownership. And FP style function composition doesn't work without Boxing everything. But then you'd need to be careful about reference cycles.

>the borrow checker, I do conceptually understand lifetimes, but actually using them is tricky.

I've been using Rust for a little over year, almost daily at work, and for several projects. I have a pretty good intuition about how the borrow checker works and what needs to be done to appease it. That said, I don't think I'm any closer to understanding lifetimes. I know conceptually how they are supposed to work (I need the reference to X to last as long as Y), but anytime I think I have a situation that could be made better with lifetimes, I can't seem to get the compiler to understand what I'm trying to do. On top of that very little of my code, and the code I read actually uses lifetimes.

I don't have time for an exhaustive answer, so I'll give you some rules of thumb when using Functional-style combinators:

* If you need to keep unchanged the input, you must either use a reference-to (.iter()) or copy-of (.iter().cloned()) of each item

* If you don't need the input ever again, you should move the items (.into_iter())

These rules follow for each step of the chain.

I very very often write very Functional code in Rust and I find it natural and easier to reason about than imperative-style code. The example I could find the fastest: https://github.com/thenewwazoo/aoc2019/blob/master/src/day10...

Edit: another example (this one uses types that are Copy so the copies are implicit) https://github.com/thenewwazoo/cryptopals/blob/master/src/tr...

Another edit: I am not a Functional programmer, and have never known Haskell or any Lisp. Erlang is as close as I've ever gotten. I've found Rust to be a fantastic language for writing Functionally.

> I do understand the basic rules of the borrow checker

It ends up being doable. I dabbled in ATS, developed Stockholm syndrome, and now Rust ain't too bad.

Higher-order functions are difficult in Rust or with linear/affine types in general. Haven't looked at what Rust does recently.

> Should I avoid using closures all over the place? Should my code look more like C and less like Haskell?

When in Rome do as the Romans :)

Anyway, some fun imperative programming stuff you can do in Rust that is fickle in Haskell (or OCaml/Standard ML).

Ah, if you’re making dsl code or functional combinators, you usually want to ‘move’ your values instead of ‘borrowing’ them.

example:

fn add(mut self) -> Self { self }

fn add(self) -> Self { self }

instead of:

fn add(&mut self) {}

fn add(&self) {}

With this, you will be able to ‘store’ closures easily and apply them later. No more fighting with the borrow checker over where to borrow as mut or not. You will also avoid a few copies.

This echoes my experience with learning Rust over the past few weeks (coming from Elixir).

There is a lot to like, understand lifetimes conceptually, but it's hard.

Yep. I made my first Rust script last week and the amount of care required is similar to C++.

It is definitely not easier compared to C++, contrasting with D, which is easier than C++.

However, the program worked correctly at the first try, which I guess it is also a consequence of the Rust model.

> The ecosystem feels very sane [] compared to npm

Now that's damning with faint praise.

Sometimes you will be annoyed by changes I guarantee it BUT since 1.0 that's decreased a lot and compared to npm it's night and day. You'll think you're dealing with C in relative terms of stability if npm is your baseline :D

https://doc.rust-lang.org/stable/book/ is not purely problems, but does have some problem chapters. (I am a co-author.)

https://doc.rust-lang.org/stable/rust-by-example/ is the "by example" introduction, which is all about sample programs, but feels a bit dated, IMHO. Still not incorrect, but not up-to-date.

You may also like the O'Reilly book, or Rust In Action, which use more fully-featured example programs more heavily than The Book does.

Meta-answer: my default when picking up a new language is usually to learn just enough to be able to start writing code, and then learn new things piecemeal as necessary to solve whatever thing I'm working on, and it sounds like you're hoping to do something like that here.

I found that approach for Rust in particular to not work well at all, and have colleagues who've reported the same. There are some fairly complicated, fundamental concepts that are unique to Rust that I think need to be tackled before you can really do much of anything (mostly borrowing and lifetimes), and that's not immediately obvious from starter programs -- because of lifetime elision, some early programs can look deceptively familiar, but there's a bunch of barely-hidden complexity there, and as soon as you start to stray from the tutorial path, you'll run headfirst into a wall of compiler errors that you're not yet equipped to understand. For Rust I'd highly recommend just reading a book cover to cover first (either TRPL or the O'Reilly one), and then starting to write code.

One thing I'd be wary of is Googling error messages and taking answers from Stack Exchange. Rust has mutated (heh) a fair bit over the years and many SE answers to noob problems are obsolete and sometimes incorrect. At the very least check the datestamp on any answer and be wary of anything more than a year or two old. This goes double if the answer has some extremely awkward looking syntax with lots of modifiers and underscores sprinkled throughout. There's probably a better way to do it now, or an alternative solution that works better. Or maybe you're just trying to do something that Rust makes hard, like concurrent processing on a shared data structure.

The manual is safer even though it's harder to find your exact problem and solution, especially when you're just starting out.

Trying to implement anything in Rust will set you up for a crash-course. Even the simplest non-trivial programs will introduce you to the Rust borrow checker, a major feature absent in C# / Python.

Once you've learned the basics (plenty of links in the siblings, including the official Rust Book), this is a key (and entertaining!) unofficial resource that really hammered home for me the ways that Rust is different from the C family when it comes to working with references: https://rust-unofficial.github.io/too-many-lists/

It also taught me about Boxes and Rc's, which are essential for certain kinds of things, and which I don't remember being covered in the main Rust Book at all

You might check out https://exercism.io/tracks/rust . Some are a little heavy in the math department but personally I've always found test drive learning useful when learning a new language thanks to instant feedback.

You could try this: https://github.com/rust-lang/rustlings

I am in similar boat. Python centric data scientist. Very tempted to try to learn Rust so I can accelerate certain ETL tasks.

Question for Rust experts: On what ETL tasks would you expect Rust to outperform Numpy, Numba, and Cython? What are the characteristics of a workload that sees order-of-magnitude speed ups from switching to Rust?

I like to implement something I have already done before. In my case, the ID3 algorithm has a nice balance of challenge, experience and documentation available. You could try to write it for a specific case, where you structure your data, and then apply it to a generic case.

Try to do some graphics programing with thr backend of your choice. There is also this cool nanovg port https://github.com/cytecbg/gpucanvas. Run the demo in examples to see the nanovg demo.

try to write ETL in rust

Write a chip8 emulator in Rust.

Never worked with Rust, but I am pretty sure that having a function be pure is not enough to evaluate it at compile time.

Rust has no notion of purity. This would require something like an effect system.

const functions can't directly do any IO or even allocation - at the moment.

But this can be easily circumvented, eg by using a proc macro that does IO.

Sidenote: even in Haskell the function signature doesn't guarantee purity, due to unsafePerformIO.

An interesting history note: Rust used to have an effects system which included actually being able to annotate a function as pure.

Do you have an example? I'm having trouble understanding how zip would be used in practice.

Yes, any time you move computation to compile time, it makes the compile time take longer. As always it is a tradeoff.

One thing that people may not realize, especially now that we have loop. You may expect this to hang the compiler:

    const fn forever() -> ! {
        loop {
            
        } 
    }
    
    static FOO: u32 = forever();

    error[E0080]: could not evaluate static initializer
     --> src/lib.rs:2:5
      |
    2 | /     loop {
    3 | |         
    4 | |     } 
      | |     ^
      | |     |
      | |_____exceeded interpreter step limit (see `#[const_eval_limit]`)
      |       inside `forever` at src/lib.rs:2:5

Yeah, but only if you use them to compute significant items during compilation.

The upside of course is that any computation you compute at compile time is a computation that you don't compute at runtime. For some applications this trade off is definitely worth the cost of admission.

At the end of the day it's a trade off that will have to be made in light of the scenario it's being used in. Being able to make that decision is a good thing.

There can be fuzziness here depending on exactly when it lands, but generally, if something lands in nightly, it'll be in stable two releases after the current stable.

You can! Just not through `const fn`. Rust has macros, which at their limit are capable of running arbitrary Rust code that manipulates syntax and communicates with the compilation process, just like in a good old Lisp.

Why isn’t `const fn` like this too? One word answer: determinism. Rust takes type/memory/access/temporal safety very seriously, and consequentially you can’t use anything in a `const fn` that isn’t fully deterministic and doesn’t depend in any way on platform-specific behavior. This includes, for example, any floating-point computation, or any random number generation, or any form of I/O, or handling file paths in an OS-specific way, or certain kinds of memory allocation. The span of things possible in `const fn`s has been expanding over time, and will in the nearish future largely overtake C++’s direct counterpart of it (`constexpr` functions) in capability. But some things will intentionally never be possible in `const fn`s, for the reasons given above.

https://doc.rust-lang.org/edition-guide/rust-next/const-fn.h...

https://blog.rust-lang.org/2020/08/18/laying-the-foundation-...