[J0-nas]

I don't know the astrophysics domain at all but shouldn't there be more arguments for Go?

* Safer than C

* Almost as fast as C

* Good concurrency support

* High productivity due to simple abstractions and good tooling

Is the downside of a GC language really relevant? Does astrophysics suffer from "stop the world interrupts" or is it just because of the performance? The Go GC is already really fast.

[claudius]

> * Almost as fast as C

That's the key point. Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C.

A grad student (if paid properly) costs maybe 60k €/year. In comparison, we regularly spend more than 250k on new and faster computers, not including maintenance, the electricity bill etc. If you can make software even 50% faster by increasing development time, this is nearly always worth it in an academic setting. Note that the benchmark implementation shown here is a very simple example, normally computing jobs take days to weeks (multiplied by however many cores you can sensibly use) of CPU time.

Decreasing runtime also increases productivity a lot, since the turnaround time becomes shorter; waiting 3 versus 6 weeks for results is a noticeable difference.

Additionally, these tools rarely have safety concerns: In my own code, there is no "untrusted user input". There is correct user input (good) and incorrect user input (mostly it will crash, with common mistakes it will try to notify the user). Safety is handled by the operating system (such that you can’t overwrite someone else’s data, for example).

This means that the only advantage Go could have over C/C++ in academia is the "good concurrency support". However, concurrency in HPC is usually handled via OpenMP (shared memory) or MPI (distributed memory) parallelisation. This takes a while to get used to, but is very different (and in a sense much easier) than e.g. the typical case for a web server, where you wish to serve as many users as possible at the same time using as little CPU time as possible – a busily waiting loop is horrible in the latter case but perfectly fine in the former (under some circumstances).

So overall, languages are not interesting in the academic HPC crowd if they sacrifice speed for anything, which, incidentally, makes Rust also interesting, because that is precisely not the case (apparently, under some circumstances, etc.pp.).

[J0-nas]

I'd agree but

> Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C.

I think this is what is most flawed in the paper. For (some) concurrent problems Go is about as fast as C [1].

But then again, I don't know what kind of computing requirements they have. Is there a reason why GRP computing isn't mentioned? They are really efficient and CUDA isn't that hard to learn.

> Rust allows the user to avoid common mistakes such as the access to invalid memory regions and race conditions

They seem to care about safety.

[1] https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

[claudius]

> I think this is what is most flawed in the paper. For (some) concurrent problems Go is about as fast as C [1].

Certainly, this was really only taken as a ballpark estimate of the performance difference. Looking at your link, it seems to have been slightly overestimating the difference, though the general point still stands: C is (in most cases) faster and there is (nearly) no case in which Go beats C.

> Is there a reason why GRP computing isn't mentioned?

> They are really efficient and CUDA isn't that hard to learn.

Sorry, not sure if you mean GPU instead of GRP in the first sentence. CUDA helps to some degree, but not always, e.g. when you are memory bandwidth bound (common in tensor networks in physics). I have no experience with Monte Carlo methods and can’t comment on whether they substantially benefit from CUDA; I know of at least one (Quantum Monte Carlo) code which runs much faster on a standard Xeon than on the Xeon Phi, though.

> They seem to care about safety.

Yes of course safety is nice to have and I’ll gladly learn Rust when I have some free time to get that safety at hopefully zero cost. But sacrificing performance is simply not competitive, if you can throw someone with gdb at the problem and get essentially the same "safety".

[bluejekyll]

> if you can throw someone with gdb at the problem and get essentially the same "safety".

That's an odd tradeoff. That time of debugging could be significantly longer than just writing the software in a safe language. Seems like a bad tradeoff, and in many scenarios, bugs can lead to very bad things that you can't recover from. I've experienced all of these, having to fix them over long periods of time (not all my code, but sadly some was): data loss, concurrency (tough to debug in gdb), major memory leaks (even from std libs), corrupted data because of misused non null terminated c strings, array out of bound issues. Each one of these took weeks to track down, maybe because I'm not smart, which is a valid criticism; with Rust I've never had issues with any of those (2 years and running), and given that I'm not smart, it helps me by telling me where I got something wrong.

Be safe out there people...

[bachmeier]

> languages are not interesting in the academic HPC crowd if they sacrifice speed for anything,

It depends. If it takes 8 weeks for the program to run using a high-level language, but 1 week for it to run using a faster language, dropping down to C to cut the running time down to 6.5 days doesn't help if it take several weeks to do it, and you are not sure that you won't have to rerun the program due to hard-to-find bugs.

[mike-cardwell]

I think you misunderstand what "safety" refers to in the context of programming. It's not about flaws in your program being attacked, it's about writing correct programs.

[AlexeyBrin]

I think you are completely missing the point here. The HPC world is mostly concerned with the speed at which you get results, safety means almost nothing in this domain. What people typically do is to test their code against known input/output and check the relative error.

It is easier to debug and improve a fast program when you can have some result in 1 day versus same algorithm implemented in a slower language that takes one week.

[mike-cardwell]

I have only been addressing your comments on safety. I have not addressed any of your comments on performance.

[pjmlp]

Fortran already covers those points, and it has a very nice libraries with several decades of work.

I don't see how Go would be a better option than it.

[criddell]

I looked at the Rust documentation's getting started page and it says:

> If you’re using more than one word in your filename, use an underscore: hello_world.rs rather than helloworld.rs.

Is the use of underscores a recommendation or a limitation?

[mdzn]

Of course it's just a recommendation. Why would you think otherwise? To Rust, module name is just a bunch of characters, it doesn't recognize words anyhow.

[flukus]

It's a recommendation that you'll find everywhere in rust. By default camelCasing will output compiler warnings. It's my only complaint about the language so far, underscores aren't very typing friendly.

[steveklabnik]

It's kinda both. Since module names are identifiers, you can't use -s in them. You can still make it work, I believe, with the path attribute, but you'd need to do it on every mod declaration.

[easytiger]

Why would one care about safety in a science context?

[mike-cardwell]

Because they want the correct results?

[claudius]

During the past years of coding in C++ in the context of tensor networks in condensed matter physics, I have never encountered the case where a programming error which would have been caught in Rust or Go lead to incorrect results. Yes, there were plenty of crashes and plenty of hard to debug issues, but it was always obvious that something was wrong way before any results were calculated/printed/output.

[ZoFreX]

I was thinking the same thing when I read this quote:

> For instance, a common source of error is the access to invalid memory regions, which produces random execution behaviors and affects the scientific interpretation of the results.

Such errors are astronomically more likely to cause crashes than silent errors in calculations.

[mike-cardwell]

Does your statement in some way address my point that "wanting correct results" is a legitimate reason to "care about safety in a science context" ?

[claudius]

Yes: Safety does not get you correct results where non-safety would have given you wrong results. Safety gives you correct results in some cases where non-safety would have given you no result. Those cases are easy to identify and can be solved using standard debugging techniques.

So safety gets you faster development: less debugging, easier parallelisation etc., but it does not give you correct results, nor does it give you those results by spending less computational time.

[mike-cardwell]

You legitimately can not imagine a scenario where a program is written which could give a result that appears correct but isn't due to a bug?

And you legitimately can't imagine how reducing the likelihood of making bugs by using a language+compiler which can identify/prevent more of them would help?

I'll leave you to it then.

[pjmlp]

While I appreciate Rust and Go, this can already be achieved by using the well established Fortran.

Fortran 2008 is already quite modern in language features and doesn't suffer from C safety issues.

EDIT: typo.

[sidlls]

One wouldn't, generally, at least in the astrophysics domain. The kinds of guarantees Rust makes don't add anything.

[pjmlp]

Not getting incorrect results due to UB with signed arithmetic or corrupted data sets?

Then again, Fortran would cover these scenarios and is better established.

[sidlls]

Arithmetic in these contexts is done with floats. Any errors that would result in signed arithmetic issues would thrash so many other things about the problem that protections against UB would rarely be an issue. It's a legitimate possible use case, but not one to justify a choice in one language over another.

And your point about Fortran is great. I used that and C++ for my research and never once encountered an issue that Rust's guarantees would have helped with.