4 ms·
Like other people, the startup isn't much of a problem to me since I can easily adapt (and even prefer) a REPL based development and for the stuff I use Julia t
by ddragon 7y ago
Like other people, the startup isn't much of a problem to me since I can easily adapt (and even prefer) a REPL based development and for the stuff I use Julia that one time cost is more than worth it, but the problem of the initial JIT lag is that it affects the first impression of the language, which probably has a significant effect in adoption and good word of mouth from people who didn't stay enough to appreciate the compromises being done.
Julia language development seems to be guided towards avoiding making damaging mistakes on the long run (for example focusing early on having a stable programmable multi-stage compilation, very efficient union-types and state of the art multithreading so the library ecosystem can grow with the correct assumptions). But the "time to first plot" is something that can be solved (regardless of it being hard or easy) at any time "with no consequences", since libraries written with the expectation of a slow startup will work just as well when that problem is solved. Though the compiler team did acknowledge the issue and are prioritizing it post 1.3.
I do wonder if focusing on doing the very simple things well first (like python does right now), would be a better strategy, or it would just make people ignore the language because the simple things are already covered everywhere and not interesting enough for bringing people (compared to the amazing stuff Julia can do with supercomputers/clusters and state of the art stuff like Zygote).
- ChrisRackauckas 7y ago>I do wonder if focusing on doing the very simple things well first (like python does right now), would be a better strategy, or it would just make people ignore the language because the simple things are already covered everywhere and not interesting enough for bringing people (compared to the amazing stuff Julia can do with supercomputers/clusters and state of the art stuff like Zygote). This is just the difficulty of open source. I am a mathematician by trade, so I work on DifferentialEquations.jl, Zygote.jl, new forward-mode AD, and showcase this stuff in neural differential equations as part of my work. While it would definitely be nice if someone focused on startup speeds, it's not going to be the DiffEq/Zygote people, because it's not the stuff that I/we know. Julia has tons of great scientists and mathematicians, so the libraries in that area are pretty fantastic already, but we do need to find some people who know how to write apps and do devops. I plan to actually find and hire some devops people to help out Julia here. Julia has shown from its libraries that it's worth supporting, so now we should tie a bow around it for less hardcore folks.
- ddragon 7y agoThat would be great if Julia can break into this area. I would really love to be able to easily write a Julia program that reads realtime input from Kafka (possibly a more mature RDKafka.jl, with multithreaded consumers), merges with data from postgres and redshift sources, sends for distributed processing using JuliaDB, which I can then integrate with Flux/Zygote models, all the while sending all metrics for Prometheus. All that with a custom admin API to access the data and manage the models and being easy to deploy in a cloud service.
- xiaodai 7y agoCan I be that person? I am rubbish at Devops now, but I can pick them up!