3 ms·
The best bet for Julia might be to be a Trojan horse in the Python ecosystem. By making the best of breed packages in specific domains it can become the first p
by socialdemocrat 6y ago
The best bet for Julia might be to be a Trojan horse in the Python ecosystem. By making the best of breed packages in specific domains it can become the first pick in the Python community rather than C/C++ based packages.
If Julia is the engine that drives all the critical parts in Python rather than C/C++, then it has a way to get the foot in the door. People will stop and ask: Why am I using Python if I could just use Julia directly?
- andi999 6y agoBecause you want a snappy repl?
- FridgeSeal 6y agoEvery major release has improved performance in the language and its use, and it doesn’t really take that much before most of the stuff you do is already compiled and you get a repl experience far superior to pythons.
- michaericalribo 6y agoThat may be true for elaborate analyses, but doesn’t really address exploratory analysis that changes dramatically from command to command. The use case for REPL-driven data science is experimentation, not performance
- phillc73 6y agoThe same with R. There's already the excellent JuliaCall[1] package, for embedding Julia code in R. Listed in the README are some R packages, using Julia code through JuliaCall. [1] https://github.com/Non-Contradiction/JuliaCall https://github.com/Non-Contradiction/JuliaCall
- jakobnissen 6y agoTo make Julia compelling as library code, it would have to be statically compiled. Having a massive laggy Julia runtime embedded in a library seem like a complete no-starter to me. I'm convinced Julia will eventually be able to be compiled statically, but doing that will likely make it feel decidedly un-Julia like (e.g. no dynamic dispatch, no type inference failure), to the point where a library maker would probably just want to use an actual static language instead.