I have my eyes on Rust, mainly for no GC and its ownership system, and Nim for its clean, Python-like syntax but with C performance.
I also have Julia in my mind for my next scientific computing (image processing, DSP) project.
Re:Rust for Python Programmers
by untothebreach on Wednesday May 27, 2015 @09:15AM
(#9611073)
I keep on messing around with Julia, but I never stick with it. I have nothing in particular against the language, but I don't do a lot of scientific computing, so my motivations to use it are not that great.
Re:Rust for Python Programmers
by juliangregorian on Wednesday May 27, 2015 @10:03AM
(#9611369)
I think Julia gets unfairly pigeonholed. It's got a great concurrency story, for example. I know what you mean though, it always seems to be the language I'll write my "next" project in.
Why can't it be used for general computing?
It can. However, Julia made a very strong push to target the scientific computing niche (very strong array support, ease of writing tight loops in native code, etc) - and such it has a very quickly growing ecosystem of high quality scientific packages.
In comparison, Julia has relatively few web frameworks, GUI toolkits, etc..
Re:Rust for Python Programmers
by untothebreach on Wednesday May 27, 2015 @12:59PM
(#9612727)
Sure it can. But why would I pick it up over, say, rust? Rust gives me the productivity of a dynamic language, and the speed of a systems language. Julia gives the same. So, given similar pros/cons, the choice comes down to aethsetics, and Julia just didn't give me a compelling enough reason to switch.
Re:Rust for Python Programmers
by the_mitsuhiko on Wednesday May 27, 2015 @09:59AM
(#9611347)
The main problem with nim is that you can't really pair it with Python whereas you can have Rust and Python call each other if you want.
Re:Rust for Python Programmers
by chrisheller on Wednesday May 27, 2015 @12:03PM
(#9612309)
Have you played around with Nimborg? That allows embedding Python in Nim fairly easily.
https://github.com/micklat/NimBorg
I've been able to call into the Nim side from Python by treating the Nim code as C functions to call. That works, but it would be interesting to come up with a more Pythonic way of doing that.
Can you expand on why that is?
Re:Rust for Python Programmers
by the_mitsuhiko on Wednesday May 27, 2015 @10:57AM
(#9611802)
Nim requires a runtime to operate. Figuring out how to safely share the runtime between different Python extensions requires the cooperation of all of those extensions. You probably also need to move all nim code into a thread.
Re:Rust for Python Programmers
by untothebreach on Wednesday May 27, 2015 @10:26AM
(#9611529)
Just a guess, but it is probably because they each have their own GCs, and that makes it harder* to ensure that objects created in language A, from language B, haven't been collected when language B needs them again.
* harder, but not impossible
As @mitsuhiko says in the article, it is very easy to export symbols from a Rust library so that they can be used via CFFI, so the possibility of "dropping down to Rust" instead of "dropping down to C" is very attractive to me.