7 ms·

Great article, thanks for writing this, I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. I really want to

Great article, thanks for writing this, I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. I really want to like Julia and I think I’m theory it has a lot to offer but due to much of what you listed I find it hard to develop in. One thing I would add is that package management is also odd to me. It seems to have a lot of overhead and behave in unexpected ways. In general I think Julia could learn a lot from Go. When I develop in Go most everything is simple. The type system is easy and just works, packaging is simple and usable, it compiles quickly. I fend writing the language seamless and productive. Unfortunately Go also isn’t good for data science due to the memory model so Julia has a lot of room to step in there.

arkitaip 5y ago
> I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. How about just moving on? It's not like there is a lack of languages and tools out there.
- jakobnissen 5y ago
  All languages have problems. Don't take my post to mean "don't use Julia" - the very first words of the post is that it's my favorite language. Also do note that the webpage is built with Julia. Not a coincidence. But even good systems need critique, otherwise there can be no improvement or growth.
  - dochtman 5y ago
    Your praise for Rust combined with the list of Julia problems left me curious what you find redeems Julia even though it has all these problems.
    - mountainriver 5y ago
      Rust is too low level for most data scientists, the borrow checker interrupts the flow of thought and it doesn’t work well in notebooks.
    - jakobnissen 5y ago
      Yeah, I guess only seeing one side of the argument can be a bit misleading... It would probably take another 1,000 word blogpost to go through why Julia is amazing, despite all these problems. I'm sure I will make that post someday. While I do like Rust, the basic design of Julia and Rust are just very different. They're intended to solve different problems, and the problems I have are the problems Julia is designed to solve. The love comes from just how well it solves those problems compared to every other programming language out there. Compared to Rust specifically, Rust is a complete nonstarter for interactive coding, since there isn't a REPL. Even if there was, it's way too complicated to use interactively - a garbage collector would be a must, and a lot of these compile time checks that I praise would be a major pain in the ass when coding casually. It's also way too slow to write: Even after having written Rust for a few months, I estimate I can solve a problem using Julia 4 times faster than using Rust, using maybe 2/3 the number of lines, or less.
- sitkack 5y ago
  > How about just moving on? Things can have faults and be worth investing in, it doesn't need to be an all or nothing false dilemma. Nothing would get fixed if we all just self selected in this way.
- mountainriver 5y ago
  To do data science there kinda is; it’s python, Julia, R, c++ or a bunch of not well supported languages Nowadays I’m doing my ML in rust which has been pretty nice, but the borrow checker does bite you a bit and there’s not much of a community. Julia seems really promising, the community just gets their head in the sand a bit
- jefft255 5y ago
  I think you just made OP's point.
  - eigenspace 5y ago
    That was explicitly not the OPs point. His point was that there are warts on every tool and he wanted to clearly bring them up in a way that is productive and helpful. He says julia is his favourite language in the very first sentence.
    - neolog 5y ago
      jefft meant GP, not OP. When people complain about julia, they often get "maybe julia isn't for your use case" instead of "good point, we should fix that".
      - deleted 5y ago
        [deleted]
      - jefft255 5y ago
        Exactly; sorry for the confusion
systemvoltage 5y ago
As someone who has used Julia for production use, I basically agree with everything you've said. IMO: 1) Julia rushed to v1.0, but its understandable - it is sort of a catch-22 issue. More developers won't join unless it is stable (v1.0). But it won't get stable unless a lot of developers use it and feedback is heard. 2) I personally found that Julia community is slightly hostile to feedback and negativity. May be it is just me but it has way too much hype-driven-positivity that leads to delusion. 3) A lot happened between v0.2 to v1.0 which IMO should have been carefully and slowly done. 4) Developer experience should have been one of the major focuses. Stack traces should be beautiful and absolutely transparent. Debuggers are clunky - I used the Atom (Juno) debugger and wanted to toss the laptop off the window - just shows how frustrating it was. Compile times and smoothness of dev experience pays dividends and it was largely ignored. 5) I really like official libraries, not SomeBasicFunctionality.jl dependency. I am spoiled by Python. 6) Marketing around speed is misplaced IMO. It lures people like me into fanboys of Julia. There is so much more to a programming language than speed. I don't want to be overly negative. The language and the original paper is beautiful - and this is all hard stuff. Kudos for the progress made so far.
- oscardssmith 5y ago
  Note that stack traces are a bunch better in 1.7 (not yet perfect though).
  - ChrisRackauckas 5y ago
    I like that they are colored now, but really what needs to be added is type parameter collapasing. In most cases, you want to see `::Dual{...}`, i.e. "it's a dual number", not `::Dual{typeof(ODESolution{sfjeoisjfsfsjslikj},sfsef,sefs}` (these can literally get to 3000 characters long). As an example of this, see the stacktraces in something like https://github.com/SciML/DiffEqOperators.jl/issues/419 https://github.com/SciML/DiffEqOperators.jl/issues/419 . The thing is that it gives back more type information than the strictest dispatch: no function is dispatching off of that first 3000 character type parameter, so you know that printing that chunk of information is actually not informative to any method decisions. Automated type abbreviations could take that heuristic and chop out a lot of the cruft.
ChrisRackauckas 5y ago
>I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. What? It's basically a meme at this point for major contributors to write a list of what they think is bad. The language's creator did a nice Youtube video "What's bad about Julia?" at JuliaCon 2019 (https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U), one of my most popular blog posts of all time is "7 Julia Gotchas and How To Handle Them" (https://www.stochasticlifestyle.com/7-julia-gotchas-handle/ https://www.stochasticlifestyle.com/7-julia-gotchas-handle/), etc. What the community pushes back about is things that are factually incorrect or just silly and repetitive, like the n+1th discussion about 1-based indexing. It's stuff below like, "I want to do an interactive workflow but not use the REPL, so it's not working well"... well the REPL is literally the interactive piece that caches the compilation so just use it if that's what you're trying to do? Yes, nobody has time for that nonsense, but everyone chimes in for real substantive discussions like changing the Base iterator API, programming patterns that would reduce recompilation, etc.
- jakobnissen 5y ago
  I don't think that's fair. Your blog post is not about what you think is bad - at least, it doesn't read like it. It reads like a list of stumbling blocks and how to get around them. This is not the same as listing the major problems with the language. Jeff's talk is indeed great, but... it's not mostly about what he thinks is bad, either. That part is quickly swept aside with "just so you know we know". The talk is really about some very specific problems in the type system that are so obscure that I don't even consider them worth mentioning in a blogpost about Julia's weaknesses.
  - neolog 5y ago
    Yeah. Mike's "Iterate on it" [1] is a real "what's bad" post, as is OP's. [1] https://mikeinnes.github.io/2020/06/04/iterate.html https://mikeinnes.github.io/2020/06/04/iterate.html
  - ChrisRackauckas 5y ago
    >It reads like a list of stumbling blocks and how to get around them. This is not the same as listing the major problems with the language. I mean, if by stumbling blocks you mean all of the things I thought was bad and all of the work arounds you have to know to get work done? I think the difference is that normally when I gripe I like to then elucidate why the bad things exist. To me that's more productive because digging into "why is it like that" starts to point towards "how do you fix it". But yes, giving the full detailed backstory behind what leads to the gripe naturally softens the blow because the reader then understands its purpose, but that's just reality. Very few things are truly and purely awful when you really see the full reason for them. Usually it's just an engineering trade-off.
bachmeier 5y ago
> I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. A related thing that really turned me off in the early days was one of the main developers constantly criticizing other languages. That wouldn't be so bad by itself, but much of it was uninformed, and it told me at least one of the core devs was not going to learn from other languages. There was always an attitude that "I know what to do, unlike everyone else". The reason I never moved heavily into Julia was that it was too easy to write slow code (back then, things may have changed) relative to compiled languages like Fortran. Maybe I'd have stuck with it longer if I found the community to be pleasant, but an unstable and often slow language plus an unpleasant core developer was more than I was willing to put up with.
- mirekrusin 5y ago
  Opposite experience here, it was crazy to me how fast I could prototype my number crunching on price series, how trivial it was to distribute it across multiple machines in my house and finally how easy it was to flip to gpu computation. On every step I was surprised how fast it was. Community is great, met only kind people, exceptionally knowledgable bunch.
- neolog 5y ago
  A couple of very vocal individuals have an attitude, which reflects badly. But the community is getting bigger, so it's becoming less of an issue as most interactions don't include those people. It's still easy to write slow code. But writing fast code is often easier than it would be in C++ or whatever. Come try again if you like.
- StefanKarpinski 5y ago
  The announcement post for Julia was literally about all the things we love in other languages: https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/
  - neolog 5y ago
    There is a certain set of languages that the Julia team is experts in. But the world of languages is very diverse and big parts of it are lacking representation, so we miss out on their insights. Eg I think most core devs are experts in C, C++, Matlab, Python, but not as many experts in Haskell, OCaml, Rust, Racket, Common Lisp, Clojure. I'd like to find ways of attracting those other experts into our community, and making sure we use their insights whenever we can.
ummonk 5y ago
I don't think Julia is trying to be anything like Go and it shouldn't be. Probably Julia's best feature is the powerful metaprogramming support that allows you to, e.g., create array packages that automatically run code on GPU. You can't have such features with a simple language.
- d110af5ccf 5y ago
  > powerful metaprogramming support ... can't have such features with a simple language Various Scheme implementations are among the simplest languages I've ever used yet possesses some of the most powerful metaprogramming I know of. Perhaps I misunderstood you somehow?
  - ummonk 5y ago
    Have you used Go? It exhibits a very different kind of simplicity than e.g. Scheme implementations.
- mountainriver 5y ago
  That doesn’t mean it can’t learn from it. Yeah they are solving somewhat different problems but in sheer usability of a language Julia could take a lot from Go.

arkitaip 5y ago

> I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. How about just moving on? It's not like there is a lack of languages and tools out there.

jakobnissen 5y ago
All languages have problems. Don't take my post to mean "don't use Julia" - the very first words of the post is that it's my favorite language. Also do note that the webpage is built with Julia. Not a coincidence. But even good systems need critique, otherwise there can be no improvement or growth.
- dochtman 5y ago
  Your praise for Rust combined with the list of Julia problems left me curious what you find redeems Julia even though it has all these problems.
  - mountainriver 5y ago
    Rust is too low level for most data scientists, the borrow checker interrupts the flow of thought and it doesn’t work well in notebooks.
  - jakobnissen 5y ago
    Yeah, I guess only seeing one side of the argument can be a bit misleading... It would probably take another 1,000 word blogpost to go through why Julia is amazing, despite all these problems. I'm sure I will make that post someday. While I do like Rust, the basic design of Julia and Rust are just very different. They're intended to solve different problems, and the problems I have are the problems Julia is designed to solve. The love comes from just how well it solves those problems compared to every other programming language out there. Compared to Rust specifically, Rust is a complete nonstarter for interactive coding, since there isn't a REPL. Even if there was, it's way too complicated to use interactively - a garbage collector would be a must, and a lot of these compile time checks that I praise would be a major pain in the ass when coding casually. It's also way too slow to write: Even after having written Rust for a few months, I estimate I can solve a problem using Julia 4 times faster than using Rust, using maybe 2/3 the number of lines, or less.
sitkack 5y ago
> How about just moving on? Things can have faults and be worth investing in, it doesn't need to be an all or nothing false dilemma. Nothing would get fixed if we all just self selected in this way.
mountainriver 5y ago
To do data science there kinda is; it’s python, Julia, R, c++ or a bunch of not well supported languages Nowadays I’m doing my ML in rust which has been pretty nice, but the borrow checker does bite you a bit and there’s not much of a community. Julia seems really promising, the community just gets their head in the sand a bit
jefft255 5y ago
I think you just made OP's point.
- eigenspace 5y ago
  That was explicitly not the OPs point. His point was that there are warts on every tool and he wanted to clearly bring them up in a way that is productive and helpful. He says julia is his favourite language in the very first sentence.
  - neolog 5y ago
    jefft meant GP, not OP. When people complain about julia, they often get "maybe julia isn't for your use case" instead of "good point, we should fix that".
    - deleted 5y ago
      [deleted]
    - jefft255 5y ago
      Exactly; sorry for the confusion

systemvoltage 5y ago

As someone who has used Julia for production use, I basically agree with everything you've said. IMO: 1) Julia rushed to v1.0, but its understandable - it is sort of a catch-22 issue. More developers won't join unless it is stable (v1.0). But it won't get stable unless a lot of developers use it and feedback is heard. 2) I personally found that Julia community is slightly hostile to feedback and negativity. May be it is just me but it has way too much hype-driven-positivity that leads to delusion. 3) A lot happened between v0.2 to v1.0 which IMO should have been carefully and slowly done. 4) Developer experience should have been one of the major focuses. Stack traces should be beautiful and absolutely transparent. Debuggers are clunky - I used the Atom (Juno) debugger and wanted to toss the laptop off the window - just shows how frustrating it was. Compile times and smoothness of dev experience pays dividends and it was largely ignored. 5) I really like official libraries, not SomeBasicFunctionality.jl dependency. I am spoiled by Python. 6) Marketing around speed is misplaced IMO. It lures people like me into fanboys of Julia. There is so much more to a programming language than speed. I don't want to be overly negative. The language and the original paper is beautiful - and this is all hard stuff. Kudos for the progress made so far.

oscardssmith 5y ago
Note that stack traces are a bunch better in 1.7 (not yet perfect though).
- ChrisRackauckas 5y ago
  I like that they are colored now, but really what needs to be added is type parameter collapasing. In most cases, you want to see `::Dual{...}`, i.e. "it's a dual number", not `::Dual{typeof(ODESolution{sfjeoisjfsfsjslikj},sfsef,sefs}` (these can literally get to 3000 characters long). As an example of this, see the stacktraces in something like https://github.com/SciML/DiffEqOperators.jl/issues/419 https://github.com/SciML/DiffEqOperators.jl/issues/419 . The thing is that it gives back more type information than the strictest dispatch: no function is dispatching off of that first 3000 character type parameter, so you know that printing that chunk of information is actually not informative to any method decisions. Automated type abbreviations could take that heuristic and chop out a lot of the cruft.

ChrisRackauckas 5y ago

>I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. What? It's basically a meme at this point for major contributors to write a list of what they think is bad. The language's creator did a nice Youtube video "What's bad about Julia?" at JuliaCon 2019 (https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U), one of my most popular blog posts of all time is "7 Julia Gotchas and How To Handle Them" (https://www.stochasticlifestyle.com/7-julia-gotchas-handle/ https://www.stochasticlifestyle.com/7-julia-gotchas-handle/), etc. What the community pushes back about is things that are factually incorrect or just silly and repetitive, like the n+1th discussion about 1-based indexing. It's stuff below like, "I want to do an interactive workflow but not use the REPL, so it's not working well"... well the REPL is literally the interactive piece that caches the compilation so just use it if that's what you're trying to do? Yes, nobody has time for that nonsense, but everyone chimes in for real substantive discussions like changing the Base iterator API, programming patterns that would reduce recompilation, etc.

jakobnissen 5y ago
I don't think that's fair. Your blog post is not about what you think is bad - at least, it doesn't read like it. It reads like a list of stumbling blocks and how to get around them. This is not the same as listing the major problems with the language. Jeff's talk is indeed great, but... it's not mostly about what he thinks is bad, either. That part is quickly swept aside with "just so you know we know". The talk is really about some very specific problems in the type system that are so obscure that I don't even consider them worth mentioning in a blogpost about Julia's weaknesses.
- neolog 5y ago
  Yeah. Mike's "Iterate on it" [1] is a real "what's bad" post, as is OP's. [1] https://mikeinnes.github.io/2020/06/04/iterate.html https://mikeinnes.github.io/2020/06/04/iterate.html
- ChrisRackauckas 5y ago
  >It reads like a list of stumbling blocks and how to get around them. This is not the same as listing the major problems with the language. I mean, if by stumbling blocks you mean all of the things I thought was bad and all of the work arounds you have to know to get work done? I think the difference is that normally when I gripe I like to then elucidate why the bad things exist. To me that's more productive because digging into "why is it like that" starts to point towards "how do you fix it". But yes, giving the full detailed backstory behind what leads to the gripe naturally softens the blow because the reader then understands its purpose, but that's just reality. Very few things are truly and purely awful when you really see the full reason for them. Usually it's just an engineering trade-off.

bachmeier 5y ago

> I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. A related thing that really turned me off in the early days was one of the main developers constantly criticizing other languages. That wouldn't be so bad by itself, but much of it was uninformed, and it told me at least one of the core devs was not going to learn from other languages. There was always an attitude that "I know what to do, unlike everyone else". The reason I never moved heavily into Julia was that it was too easy to write slow code (back then, things may have changed) relative to compiled languages like Fortran. Maybe I'd have stuck with it longer if I found the community to be pleasant, but an unstable and often slow language plus an unpleasant core developer was more than I was willing to put up with.

mirekrusin 5y ago
Opposite experience here, it was crazy to me how fast I could prototype my number crunching on price series, how trivial it was to distribute it across multiple machines in my house and finally how easy it was to flip to gpu computation. On every step I was surprised how fast it was. Community is great, met only kind people, exceptionally knowledgable bunch.
neolog 5y ago
A couple of very vocal individuals have an attitude, which reflects badly. But the community is getting bigger, so it's becoming less of an issue as most interactions don't include those people. It's still easy to write slow code. But writing fast code is often easier than it would be in C++ or whatever. Come try again if you like.
StefanKarpinski 5y ago
The announcement post for Julia was literally about all the things we love in other languages: https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/
- neolog 5y ago
  There is a certain set of languages that the Julia team is experts in. But the world of languages is very diverse and big parts of it are lacking representation, so we miss out on their insights. Eg I think most core devs are experts in C, C++, Matlab, Python, but not as many experts in Haskell, OCaml, Rust, Racket, Common Lisp, Clojure. I'd like to find ways of attracting those other experts into our community, and making sure we use their insights whenever we can.

ummonk 5y ago

I don't think Julia is trying to be anything like Go and it shouldn't be. Probably Julia's best feature is the powerful metaprogramming support that allows you to, e.g., create array packages that automatically run code on GPU. You can't have such features with a simple language.

d110af5ccf 5y ago
> powerful metaprogramming support ... can't have such features with a simple language Various Scheme implementations are among the simplest languages I've ever used yet possesses some of the most powerful metaprogramming I know of. Perhaps I misunderstood you somehow?
- ummonk 5y ago
  Have you used Go? It exhibits a very different kind of simplicity than e.g. Scheme implementations.
mountainriver 5y ago
That doesn’t mean it can’t learn from it. Yeah they are solving somewhat different problems but in sheer usability of a language Julia could take a lot from Go.