luthaf

> I found their interfaces especially for simple things (traversing atoms/bonds in a molecule) quite unwieldy.

Somehow the same for me, this is part of why I started my own project (http://chemfiles.org). I have the impression that for cheminformatics you want to see molecules as graphes, is this true or is a list of bonds enough for usual purposes?

I have heard of OEChem but never used it. I'll try to find some documentation to have a look.

What do you think is missing in the current offering (OpenBabel, RDKIT, maybe some other I am missing)?

Context: I do research in computational chemistry, and write an open source library for this, that could be used for cheminformatics too. I don't really know what is needed for this though, since I never touched cheminformatics.

Better distributed computing libraries and semantics (MPI, OpenSHMEM, ...). At the language level, it is not completely clear how RMDA and lifetimes/references should interact.

Better GPGPU support, for CUDA and OpenCL, ideally with direct compilation of Rust code to GPU assembly.

I have a C++ project that is available in multiple languages (Python, Rust, Fortran, Julia and JS), and I decided not to use SWIG partly because of this issue. Instead, I manually maintain a clean C API with everything that I need, and manually wrap this API using whatever is available in other languages. It is a bit more work (and thus incentivize me not to break the API ^^), but allow me to mix and match various ownership semantics throughout the API.

Yep, I will definitively try to compile my Rust MD code to emscripten and give it a look! There are quite a few JS molecules visualizers, so the outcome can be pretty nice for teaching.

Yes, but `using MyModule` is (was?) the default and preferred way to use a module. Which is equivalent to recommend everyone to do `from module import *` in Python.

Yep, Julia is a very nice language with very good performances. But I abandoned it because it is not (yet?) oriented toward library development, and more usable in exploratory style.

I ran into issues a year ago when trying to organize a library with more than 8000 loc, when the "dump everything into a global namespace" started to be more a hassle and less a nice way to get stuff done. I am waiting for it to stabilize a bit before giving a second try.

> I don't know the particular multidimensional array discussion you experienced, but evolving a language takes slow time, and meanwhile people experiment with what is possible out-of-tree, like with the ndarray library, which seems to be well respected.

A Fortran-like multidimensional library could effectively happen out of tree, but ndarray is closer to Python's numpy.ndarray than to Fortran arrays. And this means that ndarray can not support negative indexing (see here: https://github.com/bluss/rust-ndarray/issues/152). I started a prototype of Fortran like array here: https://github.com/Luthaf/mudi, if anyone want to look at the code or even work on this.

My only problem at the time was that `Index` must always return a reference, and cannot return a new struct. From my understanding, this could be solved with the HKT/ATC work.

> Right now there is a focus on SIMD in Rust, which is crucial for this domain, so there is progress being made.

This is very exciting! And knowing the Rust community, we may even get a cross-platform cross-architecture SIMD library with a nice API!

> there is starting to be funding for software maintenance

Any reference concerning this point? I am interested!