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

Why scientists are turning to Rust (2020)

nature.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Why scientists are turning to Rust (2020)

#31

Post by rich_sasha »

Animats wrote: post #25
pizza234 wrote: post #17

Earlier quoted context omitted.

> Is Rust substantially better at this? When I read frustrations about Rust, it seems to be mostly about the Borrow Checker... does that affect "pedestrian" code, like "take this 4-dimensional array and munge it with an arcane for-loop"? Or, here's a basic immutable class with some fields and some methods, make it available in Python? I think language complexity in general is not a problem; language consistency is. I…

> the article seems to be a puff piece; it takes one case and generalizes it. Agreed. I write mostly in Rust, but I don't recommend it unless you have a hard problem. If you need C/C++ speed, and there's enough complicated state coordination that you need safe threading and allocation control, Rust is useful. For typical webcrap, use Go. That's the job for which Google created Go.

Python sort of suffers from a lack of reliable fast companions. Here's a rough look of the field:

- Things like Cython... let's just say experience is mixed. IME it is very hard to reason with its performance, and quickly it gets about-as-complex as writing your tight loop in a "natively fast" language.

- C++ is the standard Python companion, and frankly it can integrate amazingly well. You can define types in C++, native C++ functions, and define conversions between C++/Python. Then you can seamlessly make a C++ object in Python, pass it to the function and get the type back. It's not just about the speed, but also about the ability to really merge two languages together. BUT getting to that point is a massive pain of template errors.

- You could do it all in C, manually incrementing and decrementing refcounters. I'll leave it there.

- Other languages like Nim, Fortran and who knows what else seem to offer a limited ability to merge the codebases. You can use them, it seems, as a crutch to patch up some Python slowness here and there, but not as a comprehensive "here's two codebases that live side by side".

- Rust..? Might it be a replacement for C++ here? And is its complexity manageable.

Re: Why scientists are turning to Rust (2020)

#32

Post by Fomite »

jrimbault wrote: post #15
Fomite wrote: post #6

Field specific, to be sure, but I know literally zero scientists turning to Rust.

Yeah. I have one physicist friend, and as I far I know from casual conversion with them, the whole team at his lab don't even know if they are writing C or C++. And explaining python to him, because he's required to teach a bit of it, was a rabbit hole of explaining fractal things. My impression is that at least a number of scientists don't know and don't care.

Yeah, in my field its:

R >>>>>>> Python >> Julia > Everything Else

This of course ignores that a bunch of the underlying code for both the R and Python things people use is written in other languages, because they'll never really look at that code.

Re: Why scientists are turning to Rust (2020)

#33

Post by nivenkos »

isaacg wrote: post #10

This article describes pretty much exactly why I turned to Rust for my scientific computing - high speed, far easier to use than C or C++, less bug prone.

You can't run it on GPUs and IPUs/TPUs like C++ though?

I like Rust but all the scientists I know work with C++/Python (PyTorch) nowadays due to that.

Re: Why scientists are turning to Rust (2020)

#34

Post by isofruit »

BiteCode_dev wrote: post #14

Yeah no, "scientists", this wonderful general category that means nothing and everything, in general, are not turning to Rust. Programming is a niche. Rust is a, albeit amazing and gaining traction at a fast pace, niche in this niche. 99% of mathematicians, physicists and biologists I have worked with have not even tried programming yet. And if they do, they will start with the stuff their friends are already using:…

Full agreement here. My past experience in the bioinformatics field taught me pretty much that "scientists" at large are just as afraid of the terminal as the average person. The science-folks more specialized on informatics typically are folks focusing on being able to use one language. Not use it well, mind you, just able to produce functional, untested code.

Given that, I highly doubt any of them are even aware of languages beyond python and java and maybe they're aware that C and C++ exists but are scary.

Re: Why scientists are turning to Rust (2020)

#35

Post by timeon »

rob74 wrote: post #21
rapsey wrote: post #16

Earlier quoted context omitted.

Rust users are very enthusiastic about Rust, because it fixes so much annoying shit you have to deal with in C/C++. It really brings back a lot of joy to programming. The borrow checker is an issue when you are a beginner and have to unlearn all the bad practices you were doing in C/C++.

I would say the borrow checker is an issue if you come from most other mainstream languages, because Rust's approach of trying to automate memory management without having a garbage collector is quite unique. Also, as a person interested in Rust, but who hasn't yet found the time (and strength of mind) to really commit to learning it: the main difference between C++ and Rust is the cruft that C++ has accumulated over…

> But seeing the pace of new features introduced into Rust, I'm a bit worried that some of the older features will soon be declared "non-best practice" and turn into C++-style cruft.

Is it just because you see additions of new features in general or there are some specific issues? For me new features do not make 'bad practice' from old ways. As example in older versions you had to be more explicit with lifetimes, but that is just convenience.

Re: Why scientists are turning to Rust (2020)

#36

Post by isofruit »

okasaki wrote: post #7

Are they? I worked with bioinformaticians and now physicists and rust has never come up. > Köster, now at the University of Duisburg-Essen in Germany, was looking for a language that offered the “expressiveness” of Python but the speed of languages such as C and C++. In other words, “a high-performance language that is still, let’s say, ergonomic to use”, he explains. What he found was Rust. He must not have looked v…

Yeh, that tracks with my experience. I'd imagine nim to be a somewhat nice learning experience if one already is used to python and the indentation. And with nimpy the integration into existing python codebases is pretty smooth sailing.

Re: Why scientists are turning to Rust (2020)

#37

Post by tialaramex »

rob74 wrote: post #21
rapsey wrote: post #16

Earlier quoted context omitted.

Rust users are very enthusiastic about Rust, because it fixes so much annoying shit you have to deal with in C/C++. It really brings back a lot of joy to programming. The borrow checker is an issue when you are a beginner and have to unlearn all the bad practices you were doing in C/C++.

I would say the borrow checker is an issue if you come from most other mainstream languages, because Rust's approach of trying to automate memory management without having a garbage collector is quite unique. Also, as a person interested in Rust, but who hasn't yet found the time (and strength of mind) to really commit to learning it: the main difference between C++ and Rust is the cruft that C++ has accumulated over…

Rust's Edition system allows it to deprecate and eventually remove syntax that's now considered a mistake, yet that syntax still exists (forever!) for anybody who doesn't want to learn the modern way to write it.

Let's take two serious C++ proposals I've looked at over the past years and imagine if it had Editions (it doesn't, Vittorio's similar Epochs proposal was shot down and won't be coming back). First a try operator. C++ doesn't have one of these, it would be usual to spell it ? but that's prohibited in C++ by the existence of a ? character as part of the ternary operator ?:. If you had Editions you could abolish ?: in a new Edition or change the way it is parsed so that some weird utterances now don't work because ? is the try operator, without them the proposers instead reluctantly suggest ?? (which is already an operator in some languages and it isn't try...)

Second, pattern matching with _ as a wildcard in the pattern. C++ doesn't do that today. Unfortunately _ is a valid identifier in C++ and people use it. Not a lot of people, but enough for it to be a real pain if this stopped working. So the proposers reluctantly suggest you could write __ in this case. If you had Editions you could forbid _ in a new Edition and in that Edition have the nicer _ while __ is provided in older Editions if they want new pattern matching.

Editions only cover syntax (they're actually mutating the Abstract Syntax Tree at compile time) but because this affords some great opportunities for backward compatible changes, it encourages people to get creative and do even more. For example Rust's arrays learned to be IntoIterator. But that's not a syntax change, so how did that remain compatible? Well, there's a hack, if you have an edition prior to 2021 Edition, then one function from IntoIterator is hidden from resolution by the hack, so that array.into_iter() does what it did in your edition before arrays were IntoIterator. But every other feature works, so you can write "for thing in array", you can pass arrays to functions which need an iterator, and so on, and in newer editions the hack isn't used so array.into_iter() does what you'd expect given arrays are now IntoIterator.

Re: Why scientists are turning to Rust (2020)

#38

Post by isofruit »

rich_sasha wrote: post #31
Animats wrote: post #25

Earlier quoted context omitted.

> the article seems to be a puff piece; it takes one case and generalizes it. Agreed. I write mostly in Rust, but I don't recommend it unless you have a hard problem. If you need C/C++ speed, and there's enough complicated state coordination that you need safe threading and allocation control, Rust is useful. For typical webcrap, use Go. That's the job for which Google created Go.

Python sort of suffers from a lack of reliable fast companions. Here's a rough look of the field: - Things like Cython... let's just say experience is mixed. IME it is very hard to reason with its performance, and quickly it gets about-as-complex as writing your tight loop in a "natively fast" language. - C++ is the standard Python companion, and frankly it can integrate amazingly well. You can define types in C++, n…

I do not have any experience with C++ and thus none about its python interop, which makes it hard for me to compare it to nim's python interop which I do have some experience with.

Given that, I'm curious what bits of C++/python interop are easier.

I'm mostly asking because my experience of nim-python interop consisted of: Compile nim module with nimpy imported. Put compiled nim module somewhere where your python can find it. write `import ` in the python file Done, you now have access to the exported functions and symbols defined in the nim module.

Is it that C++ wouldn't need any additional imports to make it work that makes it more seamless?

Re: Why scientists are turning to Rust (2020)

#39

Post by okasaki »

ansgri wrote: post #11
okasaki wrote: post #7

Are they? I worked with bioinformaticians and now physicists and rust has never come up. > Köster, now at the University of Duisburg-Essen in Germany, was looking for a language that offered the “expressiveness” of Python but the speed of languages such as C and C++. In other words, “a high-performance language that is still, let’s say, ergonomic to use”, he explains. What he found was Rust. He must not have looked v…

Rust seems to get serious corporate support, which future-proofs it and guarantees ecosystem growth. Not sure about Nim. Edit: others mentioned Julia, and it indeed looks like a valid choice since they don’t seem to program embedded or safety-critical stuff.

Well, maybe, but IME expecting scientists to have high level thoughts like that about programming language ecosystems is expecting too much.

Re: Why scientists are turning to Rust (2020)

#40

Post by rapsey »

rob74 wrote: post #21
rapsey wrote: post #16

Earlier quoted context omitted.

Rust users are very enthusiastic about Rust, because it fixes so much annoying shit you have to deal with in C/C++. It really brings back a lot of joy to programming. The borrow checker is an issue when you are a beginner and have to unlearn all the bad practices you were doing in C/C++.

I would say the borrow checker is an issue if you come from most other mainstream languages, because Rust's approach of trying to automate memory management without having a garbage collector is quite unique. Also, as a person interested in Rust, but who hasn't yet found the time (and strength of mind) to really commit to learning it: the main difference between C++ and Rust is the cruft that C++ has accumulated over…

> the main difference between C++ and Rust is the cruft that C++ has accumulated over the decades,

The pace of change in C++ considerably higher. Rust has regular releases, but the changes to the language tend to make it simpler to use as they remove limitations and improve the std.

Also it is not just cruft even if you ignore all the safety that Rust provides by default. The package system and ease of compilation alone makes the jump worthwhile.

Post reply on HN