I like how this highlights the pitfalls of using `as` to cast between types. The article says to prefer using `try_into()` instead of `as`, which is a good suggestion when available, but `as` lets you cast between floats and ints, while `try_into` is not implemented for these type conversions. I think the reasoning is it is unclear `try_into` should fail when it had to round a decimal number down or only when the float was something above the bounds or `NaN`. Regardless it seems like a missed opportunity in the standard library.

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

For floats you do end up having to use `as` which is unfortunate. However the amount of things that can go wrong is too vast for `TryInto`.

The article also says "If you upcast u32 to u64, you can use the keyword as". I would avoid this. In these cases you can just use `.into()`. This is infallible and will raise errors if refactoring causes that conversion to no longer be infallible. (In which case you can fix it or migrate to `.try_into()`)

I think the floating point case is similar. Keep `as` super suspicious, but sometimes you do want to do it.

Also, in generic code write try_into() and don't sweat it, for the cases which can't actually fail in the monomorphised results the error type is Infallible, that's an Empty Type (an enum with no variants, as distinct from a Zero Size Type which is a struct with no members) and so no error handling code is emitted.

The compiler can't even imagine what the code should look like, after all this type can't exist, does it fit in a register? How do we perform operations on it? If we try to actually realise an empty type by e.g. dereferencing a pointer to it that somebody gave us from a C API the Rust compiler will reject that as nonsense.

These types of GRBs are caused by the death of massive stars with low metallicity, not active galactic nuclei. There absolutely could be a GRB inside of the milky way galaxy pointed at us, but it is very unlikely.

Very cool!

I don't understand the motivation about lifetimes in sync rust not being able to be arbitrary. I'm also confused because most of the time went you want to send data around in a async context you wrap it in `arc`, which has the pretty much analogous `rc` in a sync context which would also solve the lifetimes issue. Is there something I am missing?

In C++, this will compile:

    class T {
        public:
            T(int & m): member{m} {}
            int & member;
    }

    T MakeT(int m) {
        return T(m);
    }
    
    int main() {
        const auto t = MakeT(10);
        std::cout << t.member << std::endl; // UB <- member has actually been destroyed
    }

Rust will correctly observe that the lifetime of m in `MakeT` is lower than the T object returned and will refuse to compile

I agree with you but just for completeness the rust equivalent is unsafe { *ten_things.get_unchecked_mut(11) = blah }

Which goes to show that usually the unsafe methods are more verbose and annoying to deal with. Devs won't reach for them just out of laziness.

This would be really cool! you should open up a RFC for it.

Leaks can happen in rust. The guarantee safe rust makes is that memory leaks cannot result in undefined behavior.

There are similar issues in Rust to the one Hickey talks about in Java, in terms of cognitive overload and difficulty in a human parsing the program. However, I've found rust largely avoids issues with a bunch of different classes and with their own specific interfaces with a bunch of getters and setters in the HTTP servlet example because of Trait interface reuse.

Former academic scientist, now software engineer.

I think this article misses the point that rarely in science is the code the actual product/deliverable. The way a scientific code should be judged is it performant enough to answer my question in a reasonable amount of time, clear enough to another reader (which face it 99% of the time, in science the only other reader will likely be your future self or a student with little coding experience), and does it give the correct result in a reproducible way. To my eye, the first "bad" example is actually the best to all these questions.

To my mind it feels more like how can I use my scientific coding I have to do as a way to improve my software engineering skills. Which isn't a bad endeavor and might make leaving academic science easier for you, heck I did the same thing. However, in my humble opinion, it won't make you write "better" scientific code.

For a job interview I did the same parallelization of a`isPrime` in Rust, and it the basically as simple as the one for Julia, replacing a call of `into_iter()` with `into_par_iter()`. I also show the strong scaling relationship, which i wish all things talking about concurrency did. Link for the curious: https://github.com/pcrumley/parallel_primes_rs