now Julia can (and should) be considered as a serious option for your next project
Yeah. I’d love for a greenfield project to come my way where I’d be perfectly justified in using Julia. It looks quite shiny, and feels great every time I’ve kicked the tires. But I’m not going to shoehorn Julia into an existing system just for its own sake. Even if it were possible to do 95% of what is typically done with the incumbent Python data science tools, with no downsides (I have no idea if that’s the case, I’m just saying hypothetically), the cost/benefit analysis of actually replacing any particular production system still typically favors sticking with the devil you know, and that slows down the global rate of change through network and residual effects. Also, many practitioners aren’t especially enthusiastic about programming language technology per se, and will be reluctant to adopt something new even when it’s clearly better. I’m not saying it won’t happen; I hope it does, but I think it’s important to recognize that replacing a whole thriving ecosystem can be a very long road.
I have learned that if you run with --compile=min you usually won’t get the 30 second startup time, but it’s still too slow for most real world use I agree.
Yeah. I’d love for a greenfield project to come my way where I’d be perfectly justified in using Julia. It looks quite shiny, and feels great every time I’ve kicked the tires. But I’m not going to shoehorn Julia into an existing system just for its own sake. Even if it were possible to do 95% of what is typically done with the incumbent Python data science tools, with no downsides (I have no idea if that’s the case, I’m just saying hypothetically), the cost/benefit analysis of actually replacing any particular production system still typically favors sticking with the devil you know, and that slows down the global rate of change through network and residual effects. Also, many practitioners aren’t especially enthusiastic about programming language technology per se, and will be reluctant to adopt something new even when it’s clearly better. I’m not saying it won’t happen; I hope it does, but I think it’s important to recognize that replacing a whole thriving ecosystem can be a very long road.
As long as starting a new process can take >30 seconds of startup, for a medium sized project, it will never be production ready.
I have learned that if you run with
--compile=min
you usually won’t get the 30 second startup time, but it’s still too slow for most real world use I agree.I love Julia, but so far in my testing it is still too slow for daily use
Julia has a high fixed startup cost, which is different than being “slow” (but is important for some use cases).
High startup cost, yes. Not a fixed startup cost, since it gets bigger with more packages or bigger packages being used by the program, etc.
Julia is slow, compared to what?
Ruby and Haskell are my main comparison points. I started a thread about it here: https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384 which seemed to indicate that the core devs are aware of the problem and actively working on it.
This outputs “1” without a warning:
Is that intentional?
Yes. Those
2
s have typeInt64
, so that expression is equivalent toBigInt(2)^0
.There’s an entry in the FAQ explaining why they did it that way.
The FAQ is pretty sweet and has good explanations for these design choices. Thanks