[spenczar5]

Most code in science is written by grad students and postdocs. For them, trying new language is an enormous career risk. Your advisor might not understand it, and you might be all alone in your department if you try Nim.

That makes any sort of experimentation a really tough sell.

As a rule, I have found scientific computing (at least in astronomy, where I work) to be very socially pressured. Technical advantages are not nearly as important as social ones for language or library choice.

Change does happen, but extremely slowly. I am not exaggerating when I say that even in grant applications to the NSF as recently as 2020, using Python was considered a risky use of unproven technology that needed justification.

So, yeah, Nim is going to need a good 30 years before it could plausibly get much use.

[wenc]

Yep, going against the grain in graduate school is counterproductive unless there's a compelling reason.

Many grad students forget that their main purpose is to generate research results and to publish papers that advance the field, not to play around with cool programming languages (unless their research is about coding).

Here's a bunch of mistakes I made in grad school which unnecessarily lengthened my time in the program (and nearly made me run out of stipend money):

* Started out in Ruby because I liked the language, but my research involved writing numerical codes, and at the time there just wasn't much support for it so I ended up wasting a lot of time writing wrappers etc. There was already an ecosystem of tools I could use in MATLAB and Python but nooo, I wanted to use Ruby. This ended up slowing me down. I eventually gave in to MATLAB and Python and boy everything just became a lot easier.

* Using an PowerPC-based iBook instead of an Intel Linux machine. Mac OS X is a BSD (plus I was using a PPCarch) and Brew didn't exist back then, so I ended up troubleshooting a lot of compile errors and tiny incompatibilities because I liked being seen to be using a Mac. When I eventually moved to Linux on Intel, things became so much easier. I could compile stuff without any breakages in the one pass.

I also knew a guy who used Julia in grad school because it was the hot new performant thing when all the tooling was in Python. I think he spent a lot of time rejigging his tooling and working around stuff.

Ah the follies of youth. If only someone had pulled me aside to tell me to work backwards from what I really needed to achieve (3 papers for a Ph.D.) and to play around with cool tech in my spare time.

I guess the equivalent of this today is a grad student in deep learning wanting to use Rust (fast! memory-safe! cool!) even though all the tooling is in Python.

[Rebuff5007]

A grad student using a new language definitely definitely does not face any career risk IMO... I cant imagine a single professor or recruiter caring about something like this over material progress in their work.

My guess is that grad students are swamped and are looking for the shortest path to getting an interesting result, and that is most likely done with a tool they already somewhat know.

The question for Nim, like many other new products, is: why is it worth the onboarding cost?

[sevagh]

My professor would have asked me what the relevance of Nim is to the actual subject of the research. Going against the grain has a cost, unless you're studying Nim itself.

[Jtsummers]

And not only that, your code is likely to become the next student's code. The professor doesn't need to understand it, per se, but they do need to ensure it's useful for future maintainers/extenders. Will the next Aerospace Engineering grad student coming in understand Nim or be motivated enough to learn Nim and have time to continue the work? They likely already had Fortran, Matlab, or Python experience (which depends on their undergrad and when they went to school). Picking a novel language for the research group needs to have value for the group going forward, not just to satisfy the curiosity or taste of the RA.

[baq]

None, but neither is Python…?

[sevagh]

Depends on the surrounding body of work. In my case, 99% of papers in my references had Python/PyTorch implementations. Which is the entire point of this post.

[baq]

Absolutely but being the devil’s advocate here - also what does that have to do with the research?

It’s good engineering and good management but research shouldn’t really care.

[sevagh]

Fair enough. Somebody some day wrote the first paper in Python :shrug: