voorwerpjes

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

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?

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