8 ms·

Cool! Writing math-heavy code in Julia is such a pleasure. C++ is a pain, numpy is alright but Julia just makes sense. I really wish I could use it for my day-j

by fnands 3y ago

Cool! Writing math-heavy code in Julia is such a pleasure. C++ is a pain, numpy is alright but Julia just makes sense. I really wish I could use it for my day-job. Back when I was on ATLAS we mostly did things in C++. If I never have to do another matrix multiplication in C++ again it will be too soon.

sampo 3y ago
> C++ is a pain Fortran would be less painful than C++, for math-heavy code.
- fnands 3y ago
  Julia code is actually very Fortran-like (if Fortran was designed in the 21st century). I did some Fortran in undergrad, and while it's pleasant to work with, if you have to do anything beyond numerical calculations you are basically screwed.
- jampekka 3y ago
  Yes, but Fortran is outright hell outside mathy stuff. C++ has the features as a language to be almost Fortran level pain for math heavy. But the libraries tend to fall short. E.g. Eigen kind of does it, but it will just explode with a thousand line compile error when you least expect it. Also it's missing some quite elemental stuff like ND arrays. And getting code to work across even minor Eigen versions is a crapshoot. Xtensor seems to have some potential, although it was too buggy to use back when I last tried it. However, due to many fundamental design mistakes in C++ I'm not really expecting any code, including math heavy, to be very plesant or productive in it.
  - m_mueller 3y ago
    Why would you need Fortran for anything other than math? To put it differently, what’s the problem with just using 2 languages, e.g. Fortran plus Python with f2py?
    - adgjlsfhk1 3y ago
      Sometimes you want to write fast code for things that aren't purely numerical (e.g. any string processing such as CSV/Arrow/JSON etc) or things that are mostly numerical but benefit from abstractions (like generic algorithms so you can run programs in arbitrary precision or autodifferentiation). Fortran is pretty good for writing 3 loops over a double precision matrix. Aside from "why not Fortran" the "why not 2 languages" is because moving your implimentation to a language few of your users know creates a big barrier between users and developers of your code. In Python, ~90% of users don't even know the language that the packages they use are written in which makes it a lot harder for them to become contributors. Using a single language means that as users learn how to use libraries they are also learning how to contribute to them in the future.
jampekka 3y ago
C++ is pain, numpy is pain if you need a loop, numba and cython are pain if you need any more complex data structures. Sadly Julia is pain too if you don't do REPL/notebook (which you shouldn't). Julia has the design to solve the two language problem but not the implementation. And will probably never have because Julia community refuses to see this as a problem.
- cosmic_quanta 3y ago
  What's the two language problem? One language for a high level interface and one language for low level, high performance computations?
  - adgjlsfhk1 3y ago
    exactly
- qsort 3y ago
  I'm starting to think that the two language problem is not really solvable at the language level. Maybe it is, but there's a significant friction. High level naturally pushes you towards abstract types, GC, not caring about allocation, do what I mean not what I said. Low level naturally pushes you towards concrete types, deterministic mallocs, do what I said not what I mean. e.g. do I want integers like Python or integers like C? Yes.
  - markkitti 3y ago
    > do I want integers like Python or integers like C? Yes. Julia has BigInt and Cint. Maybe there could be a more Pythonic implementation that scales between machine types and BigInt. That would not be hard to implement in Julia. I just have not found a good use case. What I like about Julia is that I can do both the high level and low level in Julia. Abstract code becomes concrete due to late binding. You can access Libc.malloc and Libc.free if needed. See GPUCompiler.jl The effect system exists. If you can prove no side effects, eager finalization is also possible. That is the finalizer and deallocation will run deterministically. It's new though so effect analysis is a mostly manual affair at the moment.
Joel_Mckay 3y ago
Julia does have binary executable generation options, but most people only find this out after a few weeks. And yes, one can also call it as a library (.so or .a) from within C/C++ . Julia is the first unique language I've been excited about in decades, as it can often outperform C, C++, and numpy in several use-cases. The only downside is until the 170MB+ lib is cached by the kernel, it gets panned by BS perf stats due to initial i/o constrained load times on some platforms. Good luck, and have a great day =)
timbaboon 3y ago
How much of that is down to C++ and how much of it is just ROOT? ;)
- fnands 3y ago
  Little bit of column A, little bit of column B ;-)

by fnands 3y ago

sampo 3y ago

> C++ is a pain Fortran would be less painful than C++, for math-heavy code.

fnands 3y ago
Julia code is actually very Fortran-like (if Fortran was designed in the 21st century). I did some Fortran in undergrad, and while it's pleasant to work with, if you have to do anything beyond numerical calculations you are basically screwed.
jampekka 3y ago
Yes, but Fortran is outright hell outside mathy stuff. C++ has the features as a language to be almost Fortran level pain for math heavy. But the libraries tend to fall short. E.g. Eigen kind of does it, but it will just explode with a thousand line compile error when you least expect it. Also it's missing some quite elemental stuff like ND arrays. And getting code to work across even minor Eigen versions is a crapshoot. Xtensor seems to have some potential, although it was too buggy to use back when I last tried it. However, due to many fundamental design mistakes in C++ I'm not really expecting any code, including math heavy, to be very plesant or productive in it.
- m_mueller 3y ago
  Why would you need Fortran for anything other than math? To put it differently, what’s the problem with just using 2 languages, e.g. Fortran plus Python with f2py?
  - adgjlsfhk1 3y ago
    Sometimes you want to write fast code for things that aren't purely numerical (e.g. any string processing such as CSV/Arrow/JSON etc) or things that are mostly numerical but benefit from abstractions (like generic algorithms so you can run programs in arbitrary precision or autodifferentiation). Fortran is pretty good for writing 3 loops over a double precision matrix. Aside from "why not Fortran" the "why not 2 languages" is because moving your implimentation to a language few of your users know creates a big barrier between users and developers of your code. In Python, ~90% of users don't even know the language that the packages they use are written in which makes it a lot harder for them to become contributors. Using a single language means that as users learn how to use libraries they are also learning how to contribute to them in the future.

jampekka 3y ago

C++ is pain, numpy is pain if you need a loop, numba and cython are pain if you need any more complex data structures. Sadly Julia is pain too if you don't do REPL/notebook (which you shouldn't). Julia has the design to solve the two language problem but not the implementation. And will probably never have because Julia community refuses to see this as a problem.

cosmic_quanta 3y ago
What's the two language problem? One language for a high level interface and one language for low level, high performance computations?
- adgjlsfhk1 3y ago
  exactly
qsort 3y ago
I'm starting to think that the two language problem is not really solvable at the language level. Maybe it is, but there's a significant friction. High level naturally pushes you towards abstract types, GC, not caring about allocation, do what I mean not what I said. Low level naturally pushes you towards concrete types, deterministic mallocs, do what I said not what I mean. e.g. do I want integers like Python or integers like C? Yes.
- markkitti 3y ago
  > do I want integers like Python or integers like C? Yes. Julia has BigInt and Cint. Maybe there could be a more Pythonic implementation that scales between machine types and BigInt. That would not be hard to implement in Julia. I just have not found a good use case. What I like about Julia is that I can do both the high level and low level in Julia. Abstract code becomes concrete due to late binding. You can access Libc.malloc and Libc.free if needed. See GPUCompiler.jl The effect system exists. If you can prove no side effects, eager finalization is also possible. That is the finalizer and deallocation will run deterministically. It's new though so effect analysis is a mostly manual affair at the moment.

Joel_Mckay 3y ago

Julia does have binary executable generation options, but most people only find this out after a few weeks. And yes, one can also call it as a library (.so or .a) from within C/C++ . Julia is the first unique language I've been excited about in decades, as it can often outperform C, C++, and numpy in several use-cases. The only downside is until the 170MB+ lib is cached by the kernel, it gets panned by BS perf stats due to initial i/o constrained load times on some platforms. Good luck, and have a great day =)

timbaboon 3y ago

How much of that is down to C++ and how much of it is just ROOT? ;)

fnands 3y ago
Little bit of column A, little bit of column B ;-)