New week, new Rust! What are you folks up to?
RStats crate - RStats
Working on using https://crates.io/crates/rustdb (the high-performance SQL database in Rust I made a while back ) for creating a webserver/website(s). Getting to know Linux and Nginx, in the past I used Windows server for my cloud servers. Also, figuring out how to send emails in Rust ( I think lettre is the crate to use, but I haven't tried it yet ).
Trying to get a good grip of the state of scientific rust. Especially for the area of high performance computing on supercomputers. If anyone has inputs I'd appreciate it.
Some stuff I have already looked at
Look also at my RStats. Any comments will be appreciated. Though I have not yet paid any attention to multithreading.
@SebastianJL, honestly, I think doing maths in Rust is a pain (as compared with Fortran and Julia) but for good reasons Rust is the only programming language I would start a scientific project in. I've actually started one but it has nothing to do with supercomputers and high performance computing...
One problem is that while Julia is sold as a 'scientific language', Rust is sold as a 'memory-safe' language. Most scientists do not really think or care about the 'memory safety'. Rust is infamously 'difficult' while most scientists I know do not know any programming language or at best can code a little bit in Python.
This week I don't code in Rust, sorry! I've started a small project in x86-64 Assembly for Fedora Silverblue.
I've used lettre, and I like it -- though I recently discovered mail-send, which you might want to consider as well.
Working overtime to write Java, the time to write rust has been reduced recently
I too thought that rust is a pain in the beginning. An there is certainly stuff that I would rather do with python where the work is quick and without much pain. But rust has in the year I use it as a hobby already thought so much about flow of data, using types correctly etc. etc. simply by teaching me with the compiler messages. (And a lot of googling trying to understand these messages). So I think it is a really good candidate for high performance stuff where we traditionally would have used c/c++ or fortran. Because you can programm just as good in those languages, but it is hard because only hours of searching for bugs will teach you what you are doing wrong. In rust the compiler will tell you right away.
I even think it has the potential to teach scientists better coding in a shorter amount of time. As long as they actually need that knowledge. For example I am in a new study direction at UZH called
Computational Science. None of us is a hero in in
c++ most are beginners. The problem here is that we always learned to do stuff with python as we only used it in the context of normal scientific work where it is more then enough performance wise (often it is actually better since you get high level interfaces and cannot mess up the low level implementation). But now it starts to become a problem, as the tasks we need to solve become more complex and learning c++ on the fly is a real hassle. I think here
rust is potentially a solution as it can be learned much faster then
c++. And yes, I actually mean that^^.
@SebastianJL, no I do not think Rust is a pain and I never thought Rust was a pain. What I'm saying is that (1) doing specifically maths (but not other things) is quite complicated in Rust as compared with e.g., Fortran and Julia, and (2) for some reason (I don't fully understand) Rust is widely believed to be difficult.
I'd say I'm rather a beginner in programming* and there are certainly lots of thing I do not know and understand. One of them is, why is Rust considered difficult? In January a started a project in Pascal which is traditionally used in education and believed to be easy. But after struggling to resolve numerous problems which apparently have no solution in Pascal, I rewrote my program in Rust. Starting from zero Rust knowledge, it took me two days to rewrite it from Pascal into Rust and all the issues disappeared.
Rust has good documentation (including blog posts, etc.) and a wonderful community on this forum which will help in case of any problem. And I've recently gave a try lots of languages, just wasting time--nothing compares to Rust. Certain languages such as e.g., Crystal are being sold as 'easy' but try to code something in a language missing documentation! Julia has a better syntax for maths than Rust but it is buggy as hell.
Rust is well-documented and works without issues and in consequence it is the easiest programming language I've ever given a try.**
*I mean, in my childhood I programmed quite a lot Windows Batch files, a little bit in Pascal, and tried some Assembly. But then, I had almost two decades of break, and I'm just recently back to programming.
**Still, there are things I'd rather write in x86 Assembly or some interpreted language such like Lua. But for most of my needs Rust looks like the only reasonable choice.
@piotr Well your lack of experience in other languages might actually make it easier for you to learn rust then for others. Some constructs frequently used in other languages don't translate well to rust. Like for example trees (a favourite in beginner programming courses). Anything that might give you a hard time with the borrow checker and lifetimes.
Also it seems like you are a little angry at me. Sorry if I offended you in some way.
@SebastianJL, no I'm not angry with you--my English sucks when I'm sleepy. Sorry! And I was pleased to see that you starred my project on GitHub.
I have never had a problem with the borrow checker. At least, not a problem I couldn't resolve in 30 seconds just following suggestions given by the compiler.
Switching from Pascal (and Batch) into Rust at the beginning my biggest problem was to find an alternative for all my 'gotos'. Now, my best solution is to call functions placed in a library.
Well, supposedly the reason for creation of Carbon is the lack of compatibility of Rust. I don't know C and C++ but reading the Carbon forum I had an impression the devs get rather easily irritated by just mentioning anything but C++. There must be other reasons than strictly technical.
Working on a language server for Factorio mods written in Rust. Barely starting, but still.
Now, reading my post I think it was very badly redacted, so once again I'm sorry if it looked impolite. Also, English is in fact my third natural language after Polish and Spanish. And... it is much harder than Rust, believe me.
I simply have never had (or don't remember) those kinds of problems people over and over talk about on the Internet. What "fight with the borrow checker" in Rust!? On one hand, just like you say @SebastianJL, I don't know C and C++, so I probably never had the same kind of habits many people have. On the other hand, as I said I've learnt some Assembly, so I possibly have a different understanding of what is "difficult".
I'm only really familiar with C so I'm not sure what fancy things are done in C++ but in C the most memory management I'm used to is checking if a pointer isn't null and if so it's probably good lol. The rust compiler is much stricter than the C compiler and that takes some getting used to lol.
Like in C you can send anything anywhere and the compiler does not care
I've been working on a GTK notes app in Rust! I've done a little bit with rust but never GTK
But this is precisely what makes coding in Rust simple! If I'm a beginner programmer (and I am) I like the compiler telling me what I'm doing wrong. Rust should be promoted as being beginner-friendly.
I wrote buggy Pascal and Python codes I had no idea how to fix. I'm not going to use these languages anymore. The same happens when I'm coding in Assembly--I only receive error message during the runtime, and in most cases I get no error messages--the program simply does not work and for a beginner programmer it may be difficult to figure out why. But still, I personally prefer Assembly over Python.
Rust has lots of benefits and some of them apply even to scientific programming.
The borrow checker, etc., you can get used to.
The main block for me was its fussiness when it comes to numeric types, insisting on treating them all as being totally different. So, when your data sometimes comes with decimal points and sometimes does not, it presents a rather unnecessary obstacle. Implementing generic Vecs yourself is non trivial and it is time that every scientist would probably consider better spent on scientific problems. Luckily, I am a bit of both, so I coped, in the end. I must say that it took me more time than the science side, though.
More specifically, I had voluminous data which for reasons of fitting into memory was quantised into bytes (16:1 reduction). I needed generic methods which would work both over
&[u8] and &[f64].
Working on a new version of my BitMan crate. While the first version worked very well and was very fast, it was a bit of a pain to use in real world projects. I'm well into a complete rewrite that should make it easy to use and still very fast. No ETA for the new release yet.