15 ms·

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was s

by smabie 5y ago

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook. Things that kind of suck about using Julia for production: 1. Never could get Revise to work, had to restart my REPL everytime I changed any code. Even though Julia 1.6 was a lot faster than 1.5, it still took too long. 2. Couldn't find a static type checker that actually worked (I tried JET and StaticLint). I feel like static typing is just so important for a production system, but of course the community isn't really interested because of the research focus. 3. Editor tooling. The LSP server absolutely sucks. I first tried using it with emacs (both lsp-mode and eglot mode), but it would crash constantly. I think switched to VSCode (much to my chagrin), and that worked marginally better though still very poorly. It was clear that the LSP server had no idea what was going on in my macro heavy code. It couldn't jump to definitions or usages much of the time. It could never correctly determine whether a variable was unused or misspelled either. Coupled with the lack of static type checking, this was extremely frustrating. 4. Never felt like the community could answer any of my questions. If you have some research or stats question, they were great, but anything else, forget about it. Will all of that being said, I do still use Julia for research and I find it works really well. The language is very nicely designed. All and all, I decided to ditch Julia and decided to go with Rust (after some consideration of OCaml, but unfortunately the multi-core story still isn't there yet) and am a lot happier.

Tainnor 5y ago
I would also add: 5. The module system is very primitive. 6. The testing framework is extremely barebones. I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.
- kruxigt 5y ago
  I agree with you guys. I have been coding in Julia for 2 years and very little has happened in tooling. For example, the graphical profiler is buggy. I love the language though. Hoping things will change!
- adgjlsfhk1 5y ago
  Anything in specific you feel like is missing from the module system and testing framework? Knowing what features people want helps a lot with setting development priorities.
  - smabie 5y ago
    It seemed to me that no one actually made projects that used the module system at all? Like no name spacing what so ever, just a bunch of include!s
    - krastanov 5y ago
      I feel like the DifferentialEquations package is a screamingly obvious counterexample to your claim. It has many sub-modules. Moreover, the whole point of multimethods is to live in the main semantic namespace, you do not need as many name spaces because there are no names to clash.
      - skybrian 5y ago
        I've only kicked the tires on Julia a bit, but it seems like while methods are less likely to clash, they still might if you happen to use the same name and argument types? Or maybe unexpected method resolution causes a bug?
        ddragon 5y ago
        While that might happen (and probably cause a method redefinition), there is an important convention that helps preventing it: your package must either own the function or at least one of the types used for arguments, otherwise you're practicing type piracy [1]. I've seen an automated scripts that can detect type piracy, so hopefully it could be part of a linting toolset eventually since not everyone might be aware, but at the very least popular packages shouldn't have them - or at least not in a way that may cause bugs (and if any package has it unintentionally it's probably worth creating an issue). [1] https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-type-piracy https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-t...
jampekka 5y ago
It's sad to see that the Julia ecosystem does not address these issues at all. Maybe Julia people are in some kind of bubble of people who like Julia and generalize that to all potential users and contributors. The true process is probably that people with other workflows (eg. non-REPL/Notebook) and past experiences (esp. more "general purpose" languages) just give up and are never heard of again. I've ranted about very similar things for some time now, and had some fruitful discussions, and I even offered to help to try to scratch some of the itches me and others are suffering from. I've now mostly given up too. It's a bit sad for me. I think Julia has many things right and the core concepts are potentially revolutionary. But for me it seems that Julia ecosystem is a bit too jealous of their discovery to let it free. Weird.
- jampekka 5y ago
  Actually not probably that weird. May be a sort of impedance mismatch between academia and software scenes. It's very common in academic circles to be quite jealous of ideas, especially good ones. The academic game is often to get your name associated with some good idea, and this is what carries a researcher in their career. I find this rather counterproductive and try to avoid it myself. I'm a researcher but I have a background in software development, and especially open source. Academia is way behind software in openness, which is rather bizarre as the institutional role of academia is usually seen as providing new ideas and challenging old thinking so the community can prosper. There's some kind of a bug in the current academic culture that causes it to freeze up when it should fulfill its promise to share its findings with the world. Probably a good way to debug this thing is to follow the money and why on earth do we have these weird hats and robes?
- orbots 5y ago
  I'm a Julia user who has also given up as a Julia community member. The bubble is real. I found too often when I wanted to do something outside of that bubble and asked for help, I got unhelpful advice which amounted to "why do you want do something outside of our bubble?"
  - dklend122 5y ago
east2west 5y ago
I agree with most of what you said and share your frustration with the tooling of Julia. However, I am not sure how well I would expect a static checker to work for Julia. Julia after all is a dynamical language, and while you may disagree with that choice, the dynamical typing permeates the language. There is no pattern matching and no language features to manipulate types, for example. Julia's AST and IR share a lot in basic data structure thanks in large part to Julia's dynamical nature. Since adding static typing to Julia at the current stage of its development would be almost an upheaval, I am not counting on it. This means there is an upper bound to how good the editing and refactoring tooling will be. I suspect the best will be a little below Pythong's tooling, because Python's class helps in disambiguating methods. One feature of Julia I think could be improved upon is the `include` statement to import code, similar to C's `include` macro directive. This makes finding functions within a package an absolute nightmare. I think this also restricts LSP's ability to find definition and usage since this tends to make Julia packages one big source file as far as the compiler is concerned. I saw that in Julia's compiler code, the core developers include C source files, not header files mind you, in other C source files, so perhaps the feature stems from their personal preference. Python's file-module may be too restricting, but Julia's including is too loose.
xiaodai 5y ago
What you've pointed out might all be valid. But they seem to be issues with maturity. When Python was at a similar age, did it have all these issues worked out? Not sure if you can generalize it to "Julia community isn't interested". If we have more ppl liking Julia and using it for general purpose computing (which it is capable of), then more of these tools will become mature overtime. Also, Julia is not in the same niche as Rust though, it's more like a Python, so not sure if the comparison is apt.
- pythrowaway 5y ago
  Problem for Julia is, the Python ecosystem gets better every year. Python might be getting better faster than Julia can catch up.
  - m_mueller 5y ago
    I highly doubt it for one core feature: performance. For a little while it looked like Python 4 might fix this (by using type hints to JIT) , but it was quickly given up. IMO a big shame as it is the one thing holding python back.
    - oscardssmith 5y ago
      I think Julia actually does a pretty good job of showing that the problem isn't types. The problem is semantics. Julia's restriction is eval to the global scope is a perfect example of this. It has a pretty minor on code, but a massive effect on performance. Python has a ton of things like this where a slightly different (and totally breaking) semantic change prevents optimization.
      - m_mueller 5y ago
        My poinr wasn’t about type system per se but the ability to compile code down to natively execute without going through an interpreter. Whether you solve that through type inference or type hints I honestly don’t care, but afaik Julia has an easier job by allowing you to make types explicit on the data structure side while being flexible for the algorithms. Semantics are certainly also a big part, but it would be nice to have first party support for what Numba does, JITing a reduced set of semantics but keep everything else compatible.
tbenst 5y ago
I use Julia as my main driver these days and have shared some of this experience but not all 1) I use VScode and have had 0 problems with Revise. It Just Works when using the Julia extension + built in REPL. I actually prefer the Julia environment to Python in VScode, I have way fewer problems when doing a Notebook-like workflow where I’m writing library code at the same time 2) Agreed, I also wish there was a better story here. I’m constantly frustrated by how little static support there is. It’s getting better though, eg precompilation in 1.6. 3) I haven’t had any issues here outside of the occasional update to VScode Julia extension that botches things 4) I’ve had quite a lot of luck on discourse and GitHub issues, as well as slack for the occasional small question Rust is great for use cases where you have specific resource management needs, although seems an odd choice for general purpose scientific computing.
- neolog 5y ago
  > had 0 problems with Revise Try changing a struct.
  - dm3 5y ago
    That's definitely a problem. I work around by naming all my structs with a `_1` suffix and `%s/_1/_2/g` (VIM find-replacing) every time a struct changes. Otherwise I find Revise works great.
  - fishmaster 5y ago
    Wrap it in a module, then you can change it without any problems. It's not ideal, but it works very well in practice.
    - jonniedie 5y ago
      Revise can’t change structs in modules either. The only sane way I’ve found to handle this is using a Pluto notebook. But that’s not for everybody.
      - fishmaster 5y ago
xvilka 5y ago
> after some consideration of OCaml, but unfortunately the multi-core story still isn't there yet It is supposed to land in the release after 4.13, which is the next one. Regarding the scientific computations library there is Owl[1][2] which now has an almost finished book[3]. [1] https://ocaml.xyz/ https://ocaml.xyz/ [2] https://github.com/owlbarn/owl https://github.com/owlbarn/owl [3] https://ocaml.xyz/book/ https://ocaml.xyz/book/
snicker7 5y ago
Your concerns are absolutely valid. Julia tooling is lacking, and tooling quality can be more important than language quality. There is a reason why Java is so popular. I feel that most of your points can be addressed if the compiler's "abstract interpreter" (static analysis) procedures were exposed and reliable/stable. Some packages (e.g. Mjolnir.jl [0]) attempt to re-implement it. Others (e.g. JET.jl [1]) try to hook into Julia's undocumented/private compiler internals (CoreCompiler). Rightfully so, only the most intrepid are willing to do this. [0]: https://juliapackages.com/p/mjolnir https://juliapackages.com/p/mjolnir [1]: https://juliapackages.com/p/JET https://juliapackages.com/p/JET
diragon 5y ago
How did you cope with the lack of REPL on Rust's side?
- smabie 5y ago
  Rust REPL'S do exist, though I don't need it very often because the static typing allows me to know exactly what's going on with each line of code.
xianwen 5y ago
I'm just curious. Do you do symbolic math in Rust? I found a crate [1] that is a wrapper for SymEngine. However, it is no longer maintained. [1] https://github.com/podo-os/symengine.rs https://github.com/podo-os/symengine.rs

by smabie 5y ago

Tainnor 5y ago

I would also add: 5. The module system is very primitive. 6. The testing framework is extremely barebones. I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.

kruxigt 5y ago
I agree with you guys. I have been coding in Julia for 2 years and very little has happened in tooling. For example, the graphical profiler is buggy. I love the language though. Hoping things will change!
adgjlsfhk1 5y ago
Anything in specific you feel like is missing from the module system and testing framework? Knowing what features people want helps a lot with setting development priorities.
- smabie 5y ago
  It seemed to me that no one actually made projects that used the module system at all? Like no name spacing what so ever, just a bunch of include!s
  - krastanov 5y ago
    I feel like the DifferentialEquations package is a screamingly obvious counterexample to your claim. It has many sub-modules. Moreover, the whole point of multimethods is to live in the main semantic namespace, you do not need as many name spaces because there are no names to clash.
    - skybrian 5y ago
      I've only kicked the tires on Julia a bit, but it seems like while methods are less likely to clash, they still might if you happen to use the same name and argument types? Or maybe unexpected method resolution causes a bug?
      - ddragon 5y ago
        While that might happen (and probably cause a method redefinition), there is an important convention that helps preventing it: your package must either own the function or at least one of the types used for arguments, otherwise you're practicing type piracy [1]. I've seen an automated scripts that can detect type piracy, so hopefully it could be part of a linting toolset eventually since not everyone might be aware, but at the very least popular packages shouldn't have them - or at least not in a way that may cause bugs (and if any package has it unintentionally it's probably worth creating an issue). [1] https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-type-piracy https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-t...

jampekka 5y ago

It's sad to see that the Julia ecosystem does not address these issues at all. Maybe Julia people are in some kind of bubble of people who like Julia and generalize that to all potential users and contributors. The true process is probably that people with other workflows (eg. non-REPL/Notebook) and past experiences (esp. more "general purpose" languages) just give up and are never heard of again. I've ranted about very similar things for some time now, and had some fruitful discussions, and I even offered to help to try to scratch some of the itches me and others are suffering from. I've now mostly given up too. It's a bit sad for me. I think Julia has many things right and the core concepts are potentially revolutionary. But for me it seems that Julia ecosystem is a bit too jealous of their discovery to let it free. Weird.

jampekka 5y ago
Actually not probably that weird. May be a sort of impedance mismatch between academia and software scenes. It's very common in academic circles to be quite jealous of ideas, especially good ones. The academic game is often to get your name associated with some good idea, and this is what carries a researcher in their career. I find this rather counterproductive and try to avoid it myself. I'm a researcher but I have a background in software development, and especially open source. Academia is way behind software in openness, which is rather bizarre as the institutional role of academia is usually seen as providing new ideas and challenging old thinking so the community can prosper. There's some kind of a bug in the current academic culture that causes it to freeze up when it should fulfill its promise to share its findings with the world. Probably a good way to debug this thing is to follow the money and why on earth do we have these weird hats and robes?
orbots 5y ago
I'm a Julia user who has also given up as a Julia community member. The bubble is real. I found too often when I wanted to do something outside of that bubble and asked for help, I got unhelpful advice which amounted to "why do you want do something outside of our bubble?"
- dklend122 5y ago

east2west 5y ago

I agree with most of what you said and share your frustration with the tooling of Julia. However, I am not sure how well I would expect a static checker to work for Julia. Julia after all is a dynamical language, and while you may disagree with that choice, the dynamical typing permeates the language. There is no pattern matching and no language features to manipulate types, for example. Julia's AST and IR share a lot in basic data structure thanks in large part to Julia's dynamical nature. Since adding static typing to Julia at the current stage of its development would be almost an upheaval, I am not counting on it. This means there is an upper bound to how good the editing and refactoring tooling will be. I suspect the best will be a little below Pythong's tooling, because Python's class helps in disambiguating methods. One feature of Julia I think could be improved upon is the `include` statement to import code, similar to C's `include` macro directive. This makes finding functions within a package an absolute nightmare. I think this also restricts LSP's ability to find definition and usage since this tends to make Julia packages one big source file as far as the compiler is concerned. I saw that in Julia's compiler code, the core developers include C source files, not header files mind you, in other C source files, so perhaps the feature stems from their personal preference. Python's file-module may be too restricting, but Julia's including is too loose.

xiaodai 5y ago

What you've pointed out might all be valid. But they seem to be issues with maturity. When Python was at a similar age, did it have all these issues worked out? Not sure if you can generalize it to "Julia community isn't interested". If we have more ppl liking Julia and using it for general purpose computing (which it is capable of), then more of these tools will become mature overtime. Also, Julia is not in the same niche as Rust though, it's more like a Python, so not sure if the comparison is apt.

pythrowaway 5y ago
Problem for Julia is, the Python ecosystem gets better every year. Python might be getting better faster than Julia can catch up.
- m_mueller 5y ago
  I highly doubt it for one core feature: performance. For a little while it looked like Python 4 might fix this (by using type hints to JIT) , but it was quickly given up. IMO a big shame as it is the one thing holding python back.
  - oscardssmith 5y ago
    I think Julia actually does a pretty good job of showing that the problem isn't types. The problem is semantics. Julia's restriction is eval to the global scope is a perfect example of this. It has a pretty minor on code, but a massive effect on performance. Python has a ton of things like this where a slightly different (and totally breaking) semantic change prevents optimization.
    - m_mueller 5y ago
      My poinr wasn’t about type system per se but the ability to compile code down to natively execute without going through an interpreter. Whether you solve that through type inference or type hints I honestly don’t care, but afaik Julia has an easier job by allowing you to make types explicit on the data structure side while being flexible for the algorithms. Semantics are certainly also a big part, but it would be nice to have first party support for what Numba does, JITing a reduced set of semantics but keep everything else compatible.

tbenst 5y ago

I use Julia as my main driver these days and have shared some of this experience but not all 1) I use VScode and have had 0 problems with Revise. It Just Works when using the Julia extension + built in REPL. I actually prefer the Julia environment to Python in VScode, I have way fewer problems when doing a Notebook-like workflow where I’m writing library code at the same time 2) Agreed, I also wish there was a better story here. I’m constantly frustrated by how little static support there is. It’s getting better though, eg precompilation in 1.6. 3) I haven’t had any issues here outside of the occasional update to VScode Julia extension that botches things 4) I’ve had quite a lot of luck on discourse and GitHub issues, as well as slack for the occasional small question Rust is great for use cases where you have specific resource management needs, although seems an odd choice for general purpose scientific computing.

neolog 5y ago
> had 0 problems with Revise Try changing a struct.
- dm3 5y ago
  That's definitely a problem. I work around by naming all my structs with a `_1` suffix and `%s/_1/_2/g` (VIM find-replacing) every time a struct changes. Otherwise I find Revise works great.
- fishmaster 5y ago
  Wrap it in a module, then you can change it without any problems. It's not ideal, but it works very well in practice.
  - jonniedie 5y ago
    Revise can’t change structs in modules either. The only sane way I’ve found to handle this is using a Pluto notebook. But that’s not for everybody.
    - fishmaster 5y ago

xvilka 5y ago

> after some consideration of OCaml, but unfortunately the multi-core story still isn't there yet It is supposed to land in the release after 4.13, which is the next one. Regarding the scientific computations library there is Owl[1][2] which now has an almost finished book[3]. [1] https://ocaml.xyz/ https://ocaml.xyz/ [2] https://github.com/owlbarn/owl https://github.com/owlbarn/owl [3] https://ocaml.xyz/book/ https://ocaml.xyz/book/

snicker7 5y ago

Your concerns are absolutely valid. Julia tooling is lacking, and tooling quality can be more important than language quality. There is a reason why Java is so popular. I feel that most of your points can be addressed if the compiler's "abstract interpreter" (static analysis) procedures were exposed and reliable/stable. Some packages (e.g. Mjolnir.jl [0]) attempt to re-implement it. Others (e.g. JET.jl [1]) try to hook into Julia's undocumented/private compiler internals (CoreCompiler). Rightfully so, only the most intrepid are willing to do this. [0]: https://juliapackages.com/p/mjolnir https://juliapackages.com/p/mjolnir [1]: https://juliapackages.com/p/JET https://juliapackages.com/p/JET

diragon 5y ago

How did you cope with the lack of REPL on Rust's side?

smabie 5y ago
Rust REPL'S do exist, though I don't need it very often because the static typing allows me to know exactly what's going on with each line of code.

xianwen 5y ago

I'm just curious. Do you do symbolic math in Rust? I found a crate [1] that is a wrapper for SymEngine. However, it is no longer maintained. [1] https://github.com/podo-os/symengine.rs https://github.com/podo-os/symengine.rs