2 ms·
> You can have all those wrapped under a high level API, with much nicer implementations, with more support, more documentation, more eyeballs (due to more adop
by Recurecur 6y ago
> You can have all those wrapped under a high level API, with much nicer implementations, with more support, more documentation, more eyeballs (due to more adoption) in a "slow" language.
You 'can' have those things, but 'should' you? Julia is well designed, so 'nicer' is not a given. Julia is also quite a high level language with excellent metaprogramming facilities. Otherwise, everything you listed is based on adoption level.
Why use a "slow" language if you don't have to? Especially when the faster language is actually better designed...
- coldtea 6y ago>You 'can' have those things, but 'should' you? As opposed to what? Wait for Julia to catch up in 10 years? If so, yes, you absolutely should get those things from where they're already available. >Why use a "slow" language if you don't have to? Because that's where the action is, and who gets those niceties first. Julia hasn't even fixed their slow startup/load situation all these years...
- Recurecur 6y agoProgress is sadly not instant. Julia seems to be gathering momentum rather than losing it. The future looks bright if trends continue! (As to the startup time problem, significant progress is being made... Have you looked at standalone binaries?)