4 ms·

I suppose if you're coming from Python, you could use Rust (with PyO3) instead of C/C++/Cython in something similar to the Numpy/ML lower-level implementations.

I suppose if you're coming from Python, you could use Rust (with PyO3) instead of C/C++/Cython in something similar to the Numpy/ML lower-level implementations. But I wish there were a language that solved the two-languages problem (fast vs. easy to work with). I find Rust quite verbose.

dagw 4y ago
But I wish there were a language that solved the two-languages problem That's the whole pitch of Julia.
sundarurfriend 4y ago
> But I wish there were a language that solved the two-languages problem (fast vs. easy to work with). That is the motivation and purpose of Julia. For some people's workflows it already seems to have solved the problem, but in general the "easy to work with" part is still in progress IMO. Some of it is the (in)famously annoying compilation delays, but a large part of it is just a tooling and ecosystem thing (both of those sides of the issue are being actively worked on). The difference from C/C++/other low level languages is that it's not the language itself that's difficult to work with, it's the current tools and workflows that are suboptimal. The language is pretty well-designed and fun to work with, so there's hope that it can actually solve the two-language problem for a wider variety of devs and their needs.
pjmlp 4y ago
Julia, Common Lisp, Scheme, OCaml, Haskell, F#, D,..
zozbot234 4y ago
> But I wish there were a language that solved the two-languages problem (fast vs. easy to work with). I find Rust quite verbose. Rust itself can be made "easy to work with" at the cost of boilerplate. You end up with code that's littered with idiomatically superfluous uses of things like .clone(), interior mutability, Cow<>, perhaps even such exotic features as the Any trait for encoding "dynamic" behavior. The flip side is that it's easier to refactor this code and make it more correct and performant; "simply" replace the boilerplate with proper Rustic code and deal with the resulting compile errors. It's a very viable strategy that has no direct equivalents in other languages, not even in C/C++.

dagw 4y ago

But I wish there were a language that solved the two-languages problem That's the whole pitch of Julia.

sundarurfriend 4y ago

> But I wish there were a language that solved the two-languages problem (fast vs. easy to work with). That is the motivation and purpose of Julia. For some people's workflows it already seems to have solved the problem, but in general the "easy to work with" part is still in progress IMO. Some of it is the (in)famously annoying compilation delays, but a large part of it is just a tooling and ecosystem thing (both of those sides of the issue are being actively worked on). The difference from C/C++/other low level languages is that it's not the language itself that's difficult to work with, it's the current tools and workflows that are suboptimal. The language is pretty well-designed and fun to work with, so there's hope that it can actually solve the two-language problem for a wider variety of devs and their needs.

pjmlp 4y ago

Julia, Common Lisp, Scheme, OCaml, Haskell, F#, D,..

zozbot234 4y ago

> But I wish there were a language that solved the two-languages problem (fast vs. easy to work with). I find Rust quite verbose. Rust itself can be made "easy to work with" at the cost of boilerplate. You end up with code that's littered with idiomatically superfluous uses of things like .clone(), interior mutability, Cow<>, perhaps even such exotic features as the Any trait for encoding "dynamic" behavior. The flip side is that it's easier to refactor this code and make it more correct and performant; "simply" replace the boilerplate with proper Rustic code and deal with the resulting compile errors. It's a very viable strategy that has no direct equivalents in other languages, not even in C/C++.