6 ms·

I just started using Julia last week. The REPL-based workflow and the compile time latency just need to go. Stop defending it. Its a problem. It harms adopt

I just started using Julia last week. The REPL-based workflow and the compile time latency just need to go. Stop defending it. Its a problem. It harms adoption. Fix it and move on and you'll stop hearing endless complaints about it. Sometimes the endless complaints have a point and you need to listen to it. Coming from a decade-long history with ruby I do think that dynamic, duck-typed languages are inherently flawed, but c'est la vie and Julia is miles better than Matlab. I'm not looking at Julia to be exactly like go or rust, I want automatic differentiation. Don't particularly care about the memory bloat either. Newbie documentation does need to be a whole lot better. I suspect that would probably get fixed if the compilation and REPL-centric issues got fixed and it wasn't so immediately hostile to your time on day 1. Package management also needs to get better. Rubygems gets the shape mostly right if you don't look too close at the details, cargo seems to be excellent. Languages created in the past 10 years really should have strong package management from the start and not treat it as an afterthought and not try to reinvent the wheel without understand the successful systems that have come before them. But really its about the compilation and REPL-centric issues. That should have been a requirement for 1.0, and I can't believe that a language that is nearly 10 years old could have that bad of an initial workflow for users.

linspace 5y ago
All languages make compromises and Julia has decided to not compromise in execution speed. I say this not because I don't think compilation time sucks but because 10 years is not that much time for solving a complex problem. How many years in Python without proper parallelism (I don't think the answer is the multiprocessing lib)? I think Julia package system is good but since I come from Python maybe it doesn't mean that much.
- lamontcg 5y ago
  Stop making excuses for it. It is a 10 year old language and this is a crippling day #1 newbie workflow and productivity issue. Just say "yeah, that's a horrible experience and really needs to be top priority now that they've closed on a $24M funding deal"
  - krastanov 5y ago
    You do know that it is actually a top priority, right? And you have seen the measurable (order of magnitude) progress done since v1 was released, right? This is not even getting into the interesting reasons for why this problem exists and what amazing features are enabled after this tradeoff was taken.
    - lamontcg 5y ago
      I'd buy that argument if it was still around 2017. I get to own my own reaction to the language and after I did "julia mytest.jl" on a script that plotted a differential equation I thought to myself "oh well its just a new language", then I looked up that it was nearly 10 years old and I thought it was a bad joke.
      - krastanov 5y ago
        The first stable version of the language is 3 years old... How do you expect to be taken seriously with such obviously silly statements?
stabbles 5y ago
> Package management also needs to get better. In my experience it is close to perfect. What issues did you encounter?
- lamontcg 5y ago
  Might just be the REPL-centric workflow and lack of docs again and the general experience of "WTF does `activate .` even do?"
  - stabbles 5y ago
    You might want to pick up a course on using google, cause the first hit on "julia package manager" is the documentation: https://docs.julialang.org/en/v1/stdlib/Pkg/ https://docs.julialang.org/en/v1/stdlib/Pkg/ "WTF does `activate .` even do?" If you then read it, it says "If you are ever stuck, you can ask Pkg for help:". (@v1.6) pkg> ?activate activate activate [--shared|--temp] [path] Activate the environment at the given path, or the home project environment if no path is specified. The active environment is the environment that is modified by executing package commands. [...] Also the docs tell you in a highlighted blue bubble that if you don't want to use the "REPL-centric workflow" there is also the API: > This guide relies on the Pkg REPL to execute Pkg commands. For non-interactive use, we recommend the Pkg API. The Pkg API is fully documented in the API Reference section of the Pkg documentation.
    - lamontcg 5y ago
      Most other language have cli gools like `gem` or `cargo` and if you're in a directory with a Project.toml why do you even need to remember to do that all the time?
      - stabbles 5y ago
        If you're in a directory with a Project.toml do julia --project and it's activated. The downside of a separate cli tool is that it's unclear what julia version you're using. E.g. pip vs pip3.
jakobnissen 5y ago
I don't think comments like these are helpful, or get us anywhere. The latency is not simply a bug to fix - it is a consequence of the compilation model, which is also what makes Julia so great. It's like wanting to use Rust, but demanding that the Rust devs fix the annoying problem that you have to compile your code before running it. After all, Python doesn't have this problem, so why don't the Rust devs just stop being lazy and fix it like Python did?
- andi999 5y ago
  Most compiled languages allow for incremental build. I can understand that a clean compile needs 15 minutes or whatever. But why does it take long when you compile a small change? (or maybe this has been fixed?)
  - jakobnissen 5y ago
    It doesn't take long to compile a small change. But the way compilation works is different than other languages. Julia doesn't cache compiled code (well, it caches some of it), because that's fiendishly hard to do in a dynamic language that allows dynamically redefining what functions mean. So whenever you start a new Julia process, it has to compile tons of things from scratch. You can use the Revise.jl package, however. It keeps track of the files you've imported and updates the code whenever a file is changed. This causes only minor latency, similar to an incremental build.
    - lamontcg 5y ago
      Julia isn't that unique, most dynamic languages compile code on startup into bytecode and execute it on a JIT VM, and they all allow dynamically redefining the world at runtime as well. Revise.jl inside the REPL is annoying as hell to use when you start messing with structs. It isn't a big ask to just have `julia whatever.jl` not take minutes to compile the entire world. Stop defending it like every Apple fanboy on mac forums trying to convince me that the touchbar is great. And Revise.jl kind of proves the fact that incremental compilation is entirely possible. If it wasn't possible at all due to $maximum_dynamic_insanity that wouldn't even work.
mbauman 5y ago
I've never seen anyone say that latency is a good thing or that it's not a priority. It's a hard problem and it's being worked on and it's getting significantly better — particularly over the past three releases. It's disingenuous to suggest the latency gripes aren't being heard or respected. Now what I see frequently is that folks *do* regularly suggest workflows that work for them. Sometimes too zealously, yes. And indeed REPL-based workflows aren't for everyone. On documentation I whole-heartedly agree. The manual hasn't seen a major re-structuring since its inception AFAIK — and it's long overdue.
- deleted 5y ago
  [deleted]

linspace 5y ago

All languages make compromises and Julia has decided to not compromise in execution speed. I say this not because I don't think compilation time sucks but because 10 years is not that much time for solving a complex problem. How many years in Python without proper parallelism (I don't think the answer is the multiprocessing lib)? I think Julia package system is good but since I come from Python maybe it doesn't mean that much.

lamontcg 5y ago
Stop making excuses for it. It is a 10 year old language and this is a crippling day #1 newbie workflow and productivity issue. Just say "yeah, that's a horrible experience and really needs to be top priority now that they've closed on a $24M funding deal"
- krastanov 5y ago
  You do know that it is actually a top priority, right? And you have seen the measurable (order of magnitude) progress done since v1 was released, right? This is not even getting into the interesting reasons for why this problem exists and what amazing features are enabled after this tradeoff was taken.
  - lamontcg 5y ago
    I'd buy that argument if it was still around 2017. I get to own my own reaction to the language and after I did "julia mytest.jl" on a script that plotted a differential equation I thought to myself "oh well its just a new language", then I looked up that it was nearly 10 years old and I thought it was a bad joke.
    - krastanov 5y ago
      The first stable version of the language is 3 years old... How do you expect to be taken seriously with such obviously silly statements?

stabbles 5y ago

> Package management also needs to get better. In my experience it is close to perfect. What issues did you encounter?

lamontcg 5y ago
Might just be the REPL-centric workflow and lack of docs again and the general experience of "WTF does `activate .` even do?"
- stabbles 5y ago
  You might want to pick up a course on using google, cause the first hit on "julia package manager" is the documentation: https://docs.julialang.org/en/v1/stdlib/Pkg/ https://docs.julialang.org/en/v1/stdlib/Pkg/ "WTF does `activate .` even do?" If you then read it, it says "If you are ever stuck, you can ask Pkg for help:". (@v1.6) pkg> ?activate activate activate [--shared|--temp] [path] Activate the environment at the given path, or the home project environment if no path is specified. The active environment is the environment that is modified by executing package commands. [...] Also the docs tell you in a highlighted blue bubble that if you don't want to use the "REPL-centric workflow" there is also the API: > This guide relies on the Pkg REPL to execute Pkg commands. For non-interactive use, we recommend the Pkg API. The Pkg API is fully documented in the API Reference section of the Pkg documentation.
  - lamontcg 5y ago
    Most other language have cli gools like `gem` or `cargo` and if you're in a directory with a Project.toml why do you even need to remember to do that all the time?
    - stabbles 5y ago
      If you're in a directory with a Project.toml do julia --project and it's activated. The downside of a separate cli tool is that it's unclear what julia version you're using. E.g. pip vs pip3.

jakobnissen 5y ago

I don't think comments like these are helpful, or get us anywhere. The latency is not simply a bug to fix - it is a consequence of the compilation model, which is also what makes Julia so great. It's like wanting to use Rust, but demanding that the Rust devs fix the annoying problem that you have to compile your code before running it. After all, Python doesn't have this problem, so why don't the Rust devs just stop being lazy and fix it like Python did?

andi999 5y ago
Most compiled languages allow for incremental build. I can understand that a clean compile needs 15 minutes or whatever. But why does it take long when you compile a small change? (or maybe this has been fixed?)
- jakobnissen 5y ago
  It doesn't take long to compile a small change. But the way compilation works is different than other languages. Julia doesn't cache compiled code (well, it caches some of it), because that's fiendishly hard to do in a dynamic language that allows dynamically redefining what functions mean. So whenever you start a new Julia process, it has to compile tons of things from scratch. You can use the Revise.jl package, however. It keeps track of the files you've imported and updates the code whenever a file is changed. This causes only minor latency, similar to an incremental build.
  - lamontcg 5y ago
    Julia isn't that unique, most dynamic languages compile code on startup into bytecode and execute it on a JIT VM, and they all allow dynamically redefining the world at runtime as well. Revise.jl inside the REPL is annoying as hell to use when you start messing with structs. It isn't a big ask to just have `julia whatever.jl` not take minutes to compile the entire world. Stop defending it like every Apple fanboy on mac forums trying to convince me that the touchbar is great. And Revise.jl kind of proves the fact that incremental compilation is entirely possible. If it wasn't possible at all due to $maximum_dynamic_insanity that wouldn't even work.

mbauman 5y ago

I've never seen anyone say that latency is a good thing or that it's not a priority. It's a hard problem and it's being worked on and it's getting significantly better — particularly over the past three releases. It's disingenuous to suggest the latency gripes aren't being heard or respected. Now what I see frequently is that folks *do* regularly suggest workflows that work for them. Sometimes too zealously, yes. And indeed REPL-based workflows aren't for everyone. On documentation I whole-heartedly agree. The manual hasn't seen a major re-structuring since its inception AFAIK — and it's long overdue.

deleted 5y ago
[deleted]