9 ms·

This seems like a stretch, or it seems very limited to the specific people mentioned in the article. I find it hard to believe that scientists who have speciali

• adamnemecek 6y ago
  Scientists will write whatever makes most sense. Julia is comparably easy as python it’s just that it has more advanced features.
  • st1x7 6y ago
    It's considerably more difficult than Python, people just get misled by the similar syntax. The advanced features that you're mentioning aren't optional in Julia, especially if you care about performance.
    • dnautics 6y ago
      But you don't care about performance with Julia. You just write your thing. Then you complain to the community that it's slow, and they optimize it for you! Only half kidding.
    • adamnemecek 6y ago
      Which part of Julia is difficult?
      • xiphias2 6y ago
        For me it was understanding the type unification rules. After a long time I read the original dissertation papers, and only that was the time when I finally understood what method is being called why at what point. While method dispatch is the most interesting part of Julia, it's the most complex as well.
      • st1x7 6y ago
        Compared to Python? Just about everything starting from simple things like how to create a simple data structure, how to convert a variable to a different type, how to understand any error message that you get, how to open a file or modify a visualisation and extending all the way up to overarching concepts like the typing system, importing foreign code and managing dependencies.
        • adamnemecek 6y ago
          How is making a structure in Julia harder than in python?
        • jonniedie 6y ago
          A simple data structure: struct ASimpleDataStructure a b end Convert a variable to a different type: x = 1 x = Float64(x) Open a file: open(“a_file.txt”) Import foreign code: using PyCall so = pyimport(“scipy.optimize”) so.newton(x -> cos(x) - x, 1)
          • adamnemecek 6y ago
            Yeah defining a strict in python would be more lines.
          • st1x7 6y ago
            This really isn't constructive. - I had none of those examples in mind (for example by foreign code I was referring to code written in a different project, not to using a different language). No, I don't need you to give me code snippets on how to do my actual list. - Obviously Julia can do everything that Python can. And most of it will look ergonomic, short and simple. The difficult part isn't whether the language can do it once you know how, it's how quickly you can get to figuring it out when you don't know it. - So what makes the small things difficult is really the mix of unhelpful error messages and the limited resources online. This is my overall point - if you take someone who hasn't written code in either Python or Julia, give them access to online search and ask them to complete almost any task, they'll do it faster and with less effort in Python.
• brundolf 6y ago
  Most of Rust's difficulty comes from the borrow-checker. And if you're mostly doing linear work, if you're doing a lot of math, if you have a lot of pretty flat data structures, if you mostly keep things on the stack, then you may not run up against the borrow-checker that often. I would assume (I don't know for sure) that scientific computing tends to do more of this kind of stuff, and not as much heap-juggling/heterogeneous data modeling as, say, a web server.
  • johncolanduoni 6y ago
    I’ve done simulation work using Rust and in particular the Rayon data-parallelism library and this has been my experience. The kind of organization of data you need to do for good cache behavior (e.g. split data by phases of algorithm, divide work by memory destination and only randomly read when possible) meshes quite well with the borrow checker restrictions.
  • ephimetheus 6y ago
    Really depends I guess. I can tell you that at least for HEP, especially for the LHC experiments, software is nothing like what you describe. Parts are designed and optimized in such a way but I would imagine it it to be a gigantic effort to try and wrangle with the borrow checker for the rest of the software.
• bosswipe 6y ago
  I agree, a memory managed language will always beat the borrow checker in expressiveness, ergonomics, simplicity, maintainability. Unless you're writing system-level or low-latency apps I don't see the benefit to Rust. If you need better-than-python performance there are many good memory-managed LLVM or JVM/.Net options available.
• whymauri 6y ago
  >I find it hard to believe that scientists who have specialized very narrowly in their domain will also want to be full-time software engineers too and choose one of the most complex languages on top of that. I think it's really field-dependent. I know academics/profs in the computational biology space that accumulate a looot of software over time from their colleagues/students. Also, it's not the scientists/PIs writing the software :P
  • walleeee 6y ago
    Yes. And a lot of that software collects dust after the paper it produced is published :/ Academia needs to recognize and incentivize software (including maintenance) as a research output, and make funding available for more research software engineers.
    • sida 6y ago
      Do these software collect dust and rust over time? ok sorry.. bad dad joke..
      • walleeee 6y ago
        wish I'd thought of that...
      • pvorb 6y ago
        This just made me discover the Dust programming language[1]. [1]: https://bilalhusain.com/dust/ https://bilalhusain.com/dust/
        • ibraheemdev 6y ago
          There is also DustJS [1]. It is much more popular. 1: https://github.com/linkedin/dustjs https://github.com/linkedin/dustjs
    • mattkrause 6y ago
      Amen! More long-term staff scientist jobs of all stripes! One lesson I hope people take away from AlphaGo/AlphaFold (and a lot of the work coming out of the Allen Institutes, Broad, etc) is that some really amazing work can be done when big groups of experienced people can work together on a project.
• ThrowawayR2 6y ago
  Scientists didn't have a problem writing Fortran, back in its day. I doubt they'd have a problem with Rust or even C++ if they needed to.
  • a-nikolaev 6y ago
    And that Fortran on average was pretty bad. Any language that requires certain level of discipline will have hard time to be adopted at a large scale. And this is why Python, R, and "C/C++" are still the best friends for most people in scientific software development.
• proverbialbunny 6y ago
  It may help to remember that the previous go-to language for scientists was Fortran. Of course, not all scientists, but a very much alive subset that still use it today. I'm a data scientist and I know Rust. Though, to be fair, I'm probably not the type the article is describing.
• 7thaccount 6y ago
  I'm also highly sceptical. In my experience scientific software is mostly restricted to: C, C++, Fortran, Python, R, Matlab/Simulink, Mathematica, Julia, and Excel. I would think VERY few doing numerical computing or statistical or other engineering computations would have the bandwidth to really dive into Rust. I also wouldn't consider it stable enough for many projects (although I'm sure it's fine for some).
  • proverbialbunny 6y ago
    Rust is easier than C++ for this kind of work because of its packages. In some ways Rust is closer to Python for prototyping an idea to see if it works. Rust gets challenging when you have to deal with large systems, which is not a problem for research. Researchers / scientists will sometimes not even write functions. It's that small of a scope.
    • st1x7 6y ago
      > Researchers / scientists will rarely even write functions. It's that small of a scope Scientific computing can mean so many different things that if feels like some of us are talking past each other in this thread. The person in the article talks about needing to get out every ounce of performance and writing an application that identifies genome variants at scale. You're talking code so small that it doesn't need functions. Those are completely different worlds. Choosing Rust for something that small is a waste of time. Expecting the people who write so little code that their code doesn't require functions, to be comfortable with Rust is even a bigger stretch.
      • proverbialbunny 6y ago
        The code I'm talking about needs to run fast (or be type safe) or you wouldn't consider using Rust. But internally in a library or a function that gets ran over and over again and needs to run super fast often isn't a lot of lines of code. So what I mean by a researcher may not even write a function is, they write the meat of the algorithm, it gets handed off to software engineers, and they turn it into a library or OOP it or whatever, and then run it on servers. My current project in Python is massive compared to a normal one atm and it's about 2-3 pages of code in Jupyter. In Rust, if the libraries are there, it would be about the same size. I have 8 functions atm. It's also the end of the project and I'm in talks with data engineers to wrap it in OOP. They'll handle the IO. Or at least, that's how I've always done it and I've done a project in Rust.