45 ms·
The best thing about julia is the interop with essentially any language you can name. Want to call numpy? using PyCall np = pyimport("numpy") res = np.fft.ff
by adamnemecek 6y ago
The best thing about julia is the interop with essentially any language you can name. Want to call numpy?
using PyCall
np = pyimport("numpy")
res = np.fft.fft(rand(ComplexF64, 10))
The interop with matlab and cpp is similarly painless.
https://github.com/JuliaInterop/Cxx.jl https://github.com/JuliaInterop/Cxx.jl
- ed25519FUUU 6y agoWhy interop with a language that already solves the problems? Just use that language.
- adamnemecek 6y agoBecause julia is a better language. Numpy is written in C, why use python when you can use C?
- Enginerrrd 6y agoBecause it's a PITA sometimes to use c++. It's easy to accidentally go out of bounds on stuff. I've arguably got a lot more experience doing scientific programming in c++ and FORTAN, than I do in python. Yet for quick prototyping where performance is almost never an issue, I still elect to use python because it lets me wrap my head around the problem faster. I spend less time fixing stupid errors and thinking about coding and more problem thinking about the problem I really need to solve. Julia might be even better, I've heard good things, I've just never used it though. In the scientific computing and data science world that I deal with, I'd say at least 95% of the time there's never a need to jump from a hacked together prototype to a more production level product.
- xh-dude 6y agoMy experience with Julia is not deep, but I’ve found it’s really nice to iterate on something that floats towards something that flies in one ecosystem. It’s not harder than Python to get the working implementation up and going - really there is a lower volume of idiosyncrasies.
- roywiggins 6y agoThe only annoying thing I've found is the startup time for the REPL / notebook environments, unless you keep one running all the time. Importing biggish libraries takes some time even if they're already compiled. I ended up making a custom system image with the libraries I always use (Plots, etc) which does help on that front. That's a fairly minor gripe, mind you. It's still great.
- marmaduke 6y agoSome libraries implement i/o formats taht you'd never want to spend time implementing, but are available in Python. Nibable is an exmaple, of neuroimaging formats I never want to understand the details of, but would need to work in Julia.
- owlie 6y agoHey neat! I use Nibabel in my work! Small world. :>
- DNF2 6y agoIf language X solves 9 of my 10 problems, and language Y solves the last one of my problems, I can either, A: use language X and call out to language Y to solve all my 10 problems. Or, B: use just language Y to solve 1 of my 10 problems. You suggest alternative B?
- StreamBright 6y agoI do not want to use C/C++ at all. I would like to use Numpy and Pandas because those projects are essential to my workflow.
- cossatot 6y agoI agree that this is great, but I think saying it's Julia's best attribute is underselling the language quite a bit. Personally I like how effectively it can replace those languages, at least for future projects.
- adamnemecek 6y agoYou are right. One of the best things.
- ZephyrBlu 6y agoWhy is language interop not this simple for everything? It seems insane to me that it's this easy in Julia, yet most other languages are completely incompatible without transpiling one into the other.
- adamnemecek 6y agoMagic of macros.
- eigenspace 6y agoTo be fair, there are no macros in that example. Just good ol polymorphism and exceptionaly hackable semantics.
- adamnemecek 6y agoPycall does rely on macros and so do essentially all the other interop packages.
- eigenspace 6y agoSure, they all provide nice macro interfaces, but nothing in the above example required those macros as far as I understand. This is not to say macros aren't awesome.
- adamnemecek 6y agoI'm pretty sure that macros are involved in the invocation of the python function.