10 ms·

New features coming in Julia 1.7

97 points by leephillips 5y ago

jstx1 5y ago
I tried really hard to like Julia and it just isn't happening for me. Slow startup, bad documentation, fragmented ecosystem, poor error messages and stack traces, encouraging the use of unicode glyphs and operators... it's been a horrible beginner experience all while the Julia community keeps telling everyone (and each other) how amazing the language is. I'm not seeing it.
- ChrisRackauckas 5y ago
  Agreed on the stacktraces. I think a few small tweaks can make them a thousand times easier to read https://github.com/JuliaLang/julia/issues/36517 https://github.com/JuliaLang/julia/issues/36517 (and an ongoing PR https://github.com/JuliaLang/julia/pull/40537 https://github.com/JuliaLang/julia/pull/40537)
- blindseer 5y ago
  I agree about the slow startup, poor error messages and stacktraces, and that itself makes Julia a very rocky beginner experience. The number is times junior engineers have asked me to help resolve method errors is comically large. Unfortunately, when you know what is going on with dispatch you can see through the stacktrace quite easily, and this makes it difficult for experienced Julia devs to see why the status quo is a problem. I don’t imagine this will be easy to get the ayes for a change here, let alone what the change should be. It is particularly frustrating when Julia advocates don’t see how much friction this causes and when they claim multiple dispatch and performance make this friction worth it. Surely core devs have seen beginners struggle as part of tutorials. Maybe they are just hoping these people will learn and figure it out? I’ve seen way too many people give up and just use python instead because they are not thinking about performance and just want things to work. I agree that I’m not seeing how Julia will take more of the general programming pie, especially given the work on getting JIT to Python in the next couple of years + ease of writing rust/go/zig, unless there’s significant more work put into reducing latency or PackageCompiler.jl. But I don’t find the ecosystem fragmented or documentation poor. In fact one of the examples I give for great documentation is the Julia Manual. Can you provide examples where you find documentation lacking? As for Unicode glyphs, I find it hard to read too but domain scientists find it really easy and since that is the target audience I think the encouragement is warranted.
  - kristofferc 5y ago
    > unless there’s significant more work put into reducing latency or PackageCompiler.jl. What features do you want out of PackageCompiler.jl? Any specific workflows you have in mind?
  - tpoacher 5y ago
    The manual is fine. It's the in-repl documentation that tends to be poor. That's gotten a bit better lately too though. For core julia at least.
- sega_sai 5y ago
  Yes, I share similar thoughts. It was exciting when Julia came in, and it looked like it's going to replace a lot of python software in science. The symbolic differentiation is still quite nice. But every time I tried to code simple projects in julia, I've encountered packages that are not supported anymore, incompatibilities between versions and difficulties in reaching good enough performance among other things. I don't think I'll use Julia myself anymore and stick to python with occasional c/c++ for really performance-critical bits.
  - ChrisRackauckas 5y ago
    I think having v1.0 as the LTS hurt quite a bit since some packages (DifferentialEquations.jl) never worked on the LTS, so we just kind of YOLO'd for a bit from version to version only testing the latest. The next LTS is v1.6 once v1.7 comes out. I think a lot more package ecosystems will start adopting tests on the LTS, which will make versioning issues a lot less prevalent.
    - kristofferc 5y ago
      I think very few people use the LTS (especially not people that would write here) so I don't think that matters very much.
- dunefox 5y ago
  > it's been a horrible beginner experience For me and others, this has not been a problem.
adgjlsfhk1 5y ago
as someone who generally runs dev versions of Julia, I can very confidently say that 1.7 has a ton of really nice goodies. It's not a ground-breaking release in the way 1.5 and 1.6 were, but it does have a ton of small changes that just make the language smoother.
deleted 5y ago
[deleted]
skybrian 5y ago
I haven’t used it much, but it seems like Julia is turning into a big language with lots of shortcuts?
- leephillips 5y ago
  Well, although it is sometimes described as a lisp, it’s not Lisp. It has a lot of syntax. Personally, I like the syntax, but some people prefer more minimalist languages.
  - pjmlp 5y ago
    It is a lisp in the same linage as Dylan. No matter how long we try, people are scared when they see parentheses on the wrong place (according to their beliefs).
    - dgb23 5y ago
      For me it is less about being scared, more about s-expressions being more friction-less in enough circumstances for it to matter. One thing that - to me - seems like a missed opportunity is to use Lisp notation in mathematics. There are many fields such as algebra, logic and so on that lend itself to being expressed in terms of a Lisp. It isn't just about avoiding ambiguity, but also about having a uniform way to mechanically transform expressions.
      - pjmlp 5y ago
        Yeah, but in mathematics we end up in the classical Lisp vs ML discussion, there is a known paper about both styles actually, arguing for ML, as it was written from someone on the ML side of the fence. In any case, maybe "Computer Algebra with LISP and REDUCE: An Introduction to Computer-aided Pure Mathematics" is something to dive into, https://www.amazon.com/Computer-Algebra-LISP-REDUCE-Computer-aided/dp/0792314417/ref=sr_1_2?dchild=1&keywords=Computer+Algebra+with+LISP+and+REDUCE&qid=1633424049&sr=8-2 https://www.amazon.com/Computer-Algebra-LISP-REDUCE-Computer...
sundarurfriend 5y ago
> (; x, y) = newS > Now x has the value 4 and y has the value 5. I believe this is supposed to be a and b here (matching the names of the fields of the struct). That's what the NEWS.md [1] implies, and that's what intuitively makes sense given the ; syntax. > Install package? │ (@v1.7) pkg> add Example └ (y/n) [y]: Surprised it defaults to [y] option, especially since packages can be pretty heavy with artifacts and lots of dependencies to precompile. One accidental extra Return and you might be sitting there for five minutes. > keepat!(v, i) Not a fan of the name. The ! indicates the mutation as the article points out, but keeponlyat! would have been much clearer and immediately obvious, enough to more than justify its length IMO. Lots of nice quality of life improvements in this version. One that the article doesn't mention is `julia --project=@myenv` [1] - being able to specify a shared environment as the starting environment for the REPL. [1] https://github.com/JuliaLang/julia/blob/v1.7.0-rc1/NEWS.md https://github.com/JuliaLang/julia/blob/v1.7.0-rc1/NEWS.md
- leephillips 5y ago
  > I believe this is supposed to be a and b here You’re right! It’s a typo. I changed the struct to use a and b instead of x and y, but didn't replace the following paragraph. Thanks for noticing that. It’ll get fixed.
- adgjlsfhk1 5y ago
  Having used the automatic package install feature for a few months already, I'm pretty sure we made the right decision. If you type `using x`, chances are you actually want to use it. Also, since 1.6 has added parallel precompilation, there aren't many packages that take that long. For reference DifferentialEquations currently adds in about 2 minutes.
  - sundarurfriend 5y ago
    > If you type `using x`, chances are you actually want to use it. In my case, at least half of the time, the issue is that I forgot to switch to the right environment. (So it's nice that the output also shows the current environment that we'll be adding to.) I'm also just used to the convention of 'n' being the the default, for eg. with Linux package managers.
adgjlsfhk1 5y ago
A quick list of other nice things in the release. Performance: * faster hashing for a variety of types (Array, Symbol, and a few others) * faster ldiv! for QR factorizations * faster findall for AbstractArray * faster expm, log2, and log10 * faster isless for floats * faster @fastmath versions of exp, exp2, exp10 * faster cbrt, sinh, exp for Float16 * Improved array resizing on push! Features * Exact determinants for BigInt matrices * lpad/rpad now use text-width instead of bytes * Make it significantly easier to use MKL (or other BLAS libraries) * opaque closures (complicated mostly internal feature) I'm sure I've missed a bunch in this list (I compiled it by scanning through the commit list)
- vletal 5y ago
  Are these really the pain points of the language needed to be addressed? What kills me specifically is the fact how sloooow are the initial warm-ups. I am forced to write a webserver in Julia. The startup time is ~5min and each initial request takes like 45s. The lengths I needed to go and the hacks I needed to do to reduce that are mesmerising. Faster log10 is all nice but I would love to see a more aggressive compilation cache and improved tooling rather than these minor improvements.
  - blindseer 5y ago
    I agree. More work on latency, pre compilation and PackageCompiler is sorely needed. Julia is also behind on the version of LLVM that is being used, and apparently they are regressions in performance with newer versions. The fact that performance is an implementation detail is concerning, and it would be nice to standardize some of the language. However, I think it is unfair to compare the inclusion of log10 to the work required to get solutions to these harder problems. I guess why not both? ;)
    - vchuravy 5y ago
      > Julia is also behind on the version of LLVM that is being used, Julia 1.6 (LLVM 11) and Julia 1.7 (LLVM 12) use the LLVM versions that were current, when the release branch was cut. LLVM 13 was finalized a fes days ago and will be released this week. So I am not sure where the notion comes from that Julia is lagging behind.
blindseer 5y ago
Mini rant incoming. I have a love/hate relationship with Julia. I’ve been using Julia professionally since 2018, and in my spare time since before that. And after writing a lot of code and reading and reviewing even more, my biggest complaint is that tooling suuuccckkssssss. LanguageServer takes up to 10 minutes to start (5000-7000 line Julia project with lots of Julia dependencies). I usually open vim, go get coffee and then come back to start working on the project. And if the LanguageServer crashes or I have to restart vim for some reason, oh boy. Even after 10 minutes, updates are SO slow. You can type something incorrectly and the LSP diagnostics won’t pick it up for at least 30-40 seconds. By then you may have moved to a different point in the codebase. Forget about switching branches when you are doing all this. I’ve tried PackageCompiler and weirdly it doesn’t really help here for some reason. The worst part is there’s no way to run a subset of tests. You HAVE to run ALL the tests every time. This makes IDE driven development and test driven development absolutely non starters. REPL driven development is the ONLY way to go, and even the REPL has its readline quirks. And god bless Revise.jl. I shudder to think of life, it weren’t for Revise, the giant hack that it is. There’s no officially blessed language formatter. LanguageServer.jl uses a formatter and JuliaFormatter.jl kind of exists on its own. And even these formatters don’t do enough, by the way (imo). Two examples that come to mind is converting explicit returns to implicit returns and changing using Foo -> import Foo: x,y. Not to mention the vim plugins for LSP and formatting are not great. Even the most popular Julia-vim plugin has some super odd opinionated un-vim like choices like high jacking TAB and the choice of commentstring syntax etc. All this in daily development is painful as it is, and even more so when I have to review someone’s code. I’m a software engineer by training, and when I have to read domain specific code written by a scientist or a domain specific engineer, or worse when I have to refactor and clean it up, I cringe all the time. Try figuring out which method gets dispatched without using a repl, fun times. Maybe few people port a Pluto notebook script into a production application as much as I do but yikes is it painful. There is SO much down time. Wait for tests, wait for LSP, wait for formatter, wait for static analyzer with JET, make a change, rinse and repeat. Contrast this to using Python, Rust, Zig, or Go and feedback is immediate! And unlike Julia, vscode isn’t the only golden editor. You can use pretty much any editor and you get first class support. All in all, Julia as a language is super interesting. I would probably only use it for small personal projects though. Professionally, I would still stick with python / pypy, or even writing python and rust or go. Multiple dispatch alone isn’t worth the other pain points when working with a large team (>50 people).
deleted 5y ago
[deleted]
sharikous 5y ago
The gap between how fantastic the language is according to Julia fanboys and how annoying my experience has been is very hard on me. Everything needs to install a package, even simple debugging. Graphics is very broken, especially for headless environments. You get incomprehensible, unfixable, error messages since everything is statically linked. But you don't get speed since everything has to compile first. Unicode symbols are encouraged (at minimum it takes an order of magnitude more to type/paste/convert some Greek symbol than to type an English letter). All the experience you feel a smug attitude coming from the environment "we make everything perfect, thoughtful, beautiful for you, if something breaks is your fault" but then something actually breaks... The most beautiful thing about the language is the computational physics community' enthusiasm about it (probably in the hope of finally abandoning Fortran). So JuliaCon's conferences are actually good and you find a lot of interesting computational problems solved in the language. Only that the basic unfriendliness and unsmooth experience, coupled with a lot of immature features, really ruins it for me.
- jstx1 5y ago
  Absolutely agree about the disconnect between my own experience and the views coming from the community. It has made an already frustrating experience even more off putting.
  - blindseer 5y ago
    I agree that the experience is extremely off putting. But having been in the community for almost 5 years now, I have to say there are super awesome lovely people that are mostly silently working in the background and very hard at that. The loud minority unfortunately is grating, and I do wish the stewards of the language established more strict guidelines on conduct or philosophy of the language. I don’t want to name names here, but when prominent members of the Julia community bash other programming languages while ignoring the painful friction in Julia, it comes across as very tone deaf and in poor taste, and does set a bad precedent. I think having a weekly what’s great about Python/Rust/Go/Zig and how can we port this to Julia would be awesome, instead of the weekly gripes about Python/MATLAB/R.
eatonphil 5y ago
Contrary to some folks here I've had a pretty good experience learning Julia while adding support for it as an scripting language in an open-source data IDE I'm building [0]. It makes a lot more sense as a language to me than R (which is also a supported scripting language), but I'm slowly coming around to R too. I do agree that it is pretty slow to start, most other scripting languages I support finish much quicker on simple scripts. But I imagine the reason you use Julia over Ruby/Node.js is the libraries not just the startup time. But I really like that it has a builtin package manager unlike almost any other language (except R) which makes it very easy to install missing dependencies in a try-catch block. (Useful in my situation since its an IDE that runs on your computer using your existing python/ruby/julia install and only depends on a single JSON library.) It's also neat that all hosted Github Actions images come with Julia built in so it's pretty easy to be working with it in automated environments as well. [0] https://github.com/multiprocessio/datastation https://github.com/multiprocessio/datastation
stewbrew 5y ago
Is there a way to statically type check a Julia program? It would be really nice if the compiler threw an error on obviously wrong code.
- jakobnissen 5y ago
  Yes - the package JET.jl. It's still in its early phases so it's pretty rough, but I use it daily at my job. There are a lot of caveats, though. Julia is fundamentally a dynamic language, so you can easily write code that works perfectly well but where the compiler has no idea what is going on before you run it. That code will not be statically analyzable.
- deleted 5y ago
  [deleted]
outlace 5y ago
I recently started a relatively complex machine learning project in Julia 1.6 and it’s been great so far. Occasionally the youthful nature of the language creates minor issues (eg fewer answers on stackoverflow) but overall it really has delivered on the promise of being very usable and productive for scientific computing and being fast and highly optimizable.
- dunefox 5y ago
  What's your project about?
  - outlace 5y ago
    Implementing this paper < https://arxiv.org/abs/1903.03129 https://arxiv.org/abs/1903.03129 > for a computer vision application.
amkkma 5y ago
I want to validate the complaints about startup and error messages as a Julia user / fanboy ;) They don't really bother me anymore personally as I've gotten used to them and make frequent use of packagcompiler.jl However, I'd just like to say that the core team is aware of these problems and there's active work being done to address them. The general path seems relatively clear, and it's currently just engineer time limited (not like we've hit a wall or ran out of ideas). But I'm confident that with the recent series a and Sciml picking up steam, these things will get ironed out in the next year or two.
tpoacher 5y ago
It's good to see the package suggestions feature happen. I believe I was the first to raise it as an issue/request on github, oh, 3-4 years ago? (based on how octave does it, which is truly excellent) I remember it caused quite a vivid discussion, which very quickly (and frustratingly) veered off in a completely different tangent in the thread. Good to see someone took it to heart after all :)

97 points by leephillips 5y ago

I tried really hard to like Julia and it just isn't happening for me. Slow startup, bad documentation, fragmented ecosystem, poor error messages and stack traces, encouraging the use of unicode glyphs and operators... it's been a horrible beginner experience all while the Julia community keeps telling everyone (and each other) how amazing the language is. I'm not seeing it.

ChrisRackauckas 5y ago
Agreed on the stacktraces. I think a few small tweaks can make them a thousand times easier to read https://github.com/JuliaLang/julia/issues/36517 https://github.com/JuliaLang/julia/issues/36517 (and an ongoing PR https://github.com/JuliaLang/julia/pull/40537 https://github.com/JuliaLang/julia/pull/40537)
blindseer 5y ago
I agree about the slow startup, poor error messages and stacktraces, and that itself makes Julia a very rocky beginner experience. The number is times junior engineers have asked me to help resolve method errors is comically large. Unfortunately, when you know what is going on with dispatch you can see through the stacktrace quite easily, and this makes it difficult for experienced Julia devs to see why the status quo is a problem. I don’t imagine this will be easy to get the ayes for a change here, let alone what the change should be. It is particularly frustrating when Julia advocates don’t see how much friction this causes and when they claim multiple dispatch and performance make this friction worth it. Surely core devs have seen beginners struggle as part of tutorials. Maybe they are just hoping these people will learn and figure it out? I’ve seen way too many people give up and just use python instead because they are not thinking about performance and just want things to work. I agree that I’m not seeing how Julia will take more of the general programming pie, especially given the work on getting JIT to Python in the next couple of years + ease of writing rust/go/zig, unless there’s significant more work put into reducing latency or PackageCompiler.jl. But I don’t find the ecosystem fragmented or documentation poor. In fact one of the examples I give for great documentation is the Julia Manual. Can you provide examples where you find documentation lacking? As for Unicode glyphs, I find it hard to read too but domain scientists find it really easy and since that is the target audience I think the encouragement is warranted.
- kristofferc 5y ago
  > unless there’s significant more work put into reducing latency or PackageCompiler.jl. What features do you want out of PackageCompiler.jl? Any specific workflows you have in mind?
- tpoacher 5y ago
  The manual is fine. It's the in-repl documentation that tends to be poor. That's gotten a bit better lately too though. For core julia at least.
sega_sai 5y ago
Yes, I share similar thoughts. It was exciting when Julia came in, and it looked like it's going to replace a lot of python software in science. The symbolic differentiation is still quite nice. But every time I tried to code simple projects in julia, I've encountered packages that are not supported anymore, incompatibilities between versions and difficulties in reaching good enough performance among other things. I don't think I'll use Julia myself anymore and stick to python with occasional c/c++ for really performance-critical bits.
- ChrisRackauckas 5y ago
  I think having v1.0 as the LTS hurt quite a bit since some packages (DifferentialEquations.jl) never worked on the LTS, so we just kind of YOLO'd for a bit from version to version only testing the latest. The next LTS is v1.6 once v1.7 comes out. I think a lot more package ecosystems will start adopting tests on the LTS, which will make versioning issues a lot less prevalent.
  - kristofferc 5y ago
    I think very few people use the LTS (especially not people that would write here) so I don't think that matters very much.
dunefox 5y ago
> it's been a horrible beginner experience For me and others, this has not been a problem.

adgjlsfhk1 5y ago

as someone who generally runs dev versions of Julia, I can very confidently say that 1.7 has a ton of really nice goodies. It's not a ground-breaking release in the way 1.5 and 1.6 were, but it does have a ton of small changes that just make the language smoother.

deleted 5y ago

[deleted]

skybrian 5y ago

I haven’t used it much, but it seems like Julia is turning into a big language with lots of shortcuts?

leephillips 5y ago
Well, although it is sometimes described as a lisp, it’s not Lisp. It has a lot of syntax. Personally, I like the syntax, but some people prefer more minimalist languages.
- pjmlp 5y ago
  It is a lisp in the same linage as Dylan. No matter how long we try, people are scared when they see parentheses on the wrong place (according to their beliefs).
  - dgb23 5y ago
    For me it is less about being scared, more about s-expressions being more friction-less in enough circumstances for it to matter. One thing that - to me - seems like a missed opportunity is to use Lisp notation in mathematics. There are many fields such as algebra, logic and so on that lend itself to being expressed in terms of a Lisp. It isn't just about avoiding ambiguity, but also about having a uniform way to mechanically transform expressions.
    - pjmlp 5y ago
      Yeah, but in mathematics we end up in the classical Lisp vs ML discussion, there is a known paper about both styles actually, arguing for ML, as it was written from someone on the ML side of the fence. In any case, maybe "Computer Algebra with LISP and REDUCE: An Introduction to Computer-aided Pure Mathematics" is something to dive into, https://www.amazon.com/Computer-Algebra-LISP-REDUCE-Computer-aided/dp/0792314417/ref=sr_1_2?dchild=1&keywords=Computer+Algebra+with+LISP+and+REDUCE&qid=1633424049&sr=8-2 https://www.amazon.com/Computer-Algebra-LISP-REDUCE-Computer...

sundarurfriend 5y ago

> (; x, y) = newS > Now x has the value 4 and y has the value 5. I believe this is supposed to be a and b here (matching the names of the fields of the struct). That's what the NEWS.md [1] implies, and that's what intuitively makes sense given the ; syntax. > Install package? │ (@v1.7) pkg> add Example └ (y/n) [y]: Surprised it defaults to [y] option, especially since packages can be pretty heavy with artifacts and lots of dependencies to precompile. One accidental extra Return and you might be sitting there for five minutes. > keepat!(v, i) Not a fan of the name. The ! indicates the mutation as the article points out, but keeponlyat! would have been much clearer and immediately obvious, enough to more than justify its length IMO. Lots of nice quality of life improvements in this version. One that the article doesn't mention is `julia --project=@myenv` [1] - being able to specify a shared environment as the starting environment for the REPL. [1] https://github.com/JuliaLang/julia/blob/v1.7.0-rc1/NEWS.md https://github.com/JuliaLang/julia/blob/v1.7.0-rc1/NEWS.md

leephillips 5y ago
> I believe this is supposed to be a and b here You’re right! It’s a typo. I changed the struct to use a and b instead of x and y, but didn't replace the following paragraph. Thanks for noticing that. It’ll get fixed.
adgjlsfhk1 5y ago
Having used the automatic package install feature for a few months already, I'm pretty sure we made the right decision. If you type `using x`, chances are you actually want to use it. Also, since 1.6 has added parallel precompilation, there aren't many packages that take that long. For reference DifferentialEquations currently adds in about 2 minutes.
- sundarurfriend 5y ago
  > If you type `using x`, chances are you actually want to use it. In my case, at least half of the time, the issue is that I forgot to switch to the right environment. (So it's nice that the output also shows the current environment that we'll be adding to.) I'm also just used to the convention of 'n' being the the default, for eg. with Linux package managers.

adgjlsfhk1 5y ago

A quick list of other nice things in the release. Performance: * faster hashing for a variety of types (Array, Symbol, and a few others) * faster ldiv! for QR factorizations * faster findall for AbstractArray * faster expm, log2, and log10 * faster isless for floats * faster @fastmath versions of exp, exp2, exp10 * faster cbrt, sinh, exp for Float16 * Improved array resizing on push! Features * Exact determinants for BigInt matrices * lpad/rpad now use text-width instead of bytes * Make it significantly easier to use MKL (or other BLAS libraries) * opaque closures (complicated mostly internal feature) I'm sure I've missed a bunch in this list (I compiled it by scanning through the commit list)

vletal 5y ago
Are these really the pain points of the language needed to be addressed? What kills me specifically is the fact how sloooow are the initial warm-ups. I am forced to write a webserver in Julia. The startup time is ~5min and each initial request takes like 45s. The lengths I needed to go and the hacks I needed to do to reduce that are mesmerising. Faster log10 is all nice but I would love to see a more aggressive compilation cache and improved tooling rather than these minor improvements.
- blindseer 5y ago
  I agree. More work on latency, pre compilation and PackageCompiler is sorely needed. Julia is also behind on the version of LLVM that is being used, and apparently they are regressions in performance with newer versions. The fact that performance is an implementation detail is concerning, and it would be nice to standardize some of the language. However, I think it is unfair to compare the inclusion of log10 to the work required to get solutions to these harder problems. I guess why not both? ;)
  - vchuravy 5y ago
    > Julia is also behind on the version of LLVM that is being used, Julia 1.6 (LLVM 11) and Julia 1.7 (LLVM 12) use the LLVM versions that were current, when the release branch was cut. LLVM 13 was finalized a fes days ago and will be released this week. So I am not sure where the notion comes from that Julia is lagging behind.

blindseer 5y ago

Mini rant incoming. I have a love/hate relationship with Julia. I’ve been using Julia professionally since 2018, and in my spare time since before that. And after writing a lot of code and reading and reviewing even more, my biggest complaint is that tooling suuuccckkssssss. LanguageServer takes up to 10 minutes to start (5000-7000 line Julia project with lots of Julia dependencies). I usually open vim, go get coffee and then come back to start working on the project. And if the LanguageServer crashes or I have to restart vim for some reason, oh boy. Even after 10 minutes, updates are SO slow. You can type something incorrectly and the LSP diagnostics won’t pick it up for at least 30-40 seconds. By then you may have moved to a different point in the codebase. Forget about switching branches when you are doing all this. I’ve tried PackageCompiler and weirdly it doesn’t really help here for some reason. The worst part is there’s no way to run a subset of tests. You HAVE to run ALL the tests every time. This makes IDE driven development and test driven development absolutely non starters. REPL driven development is the ONLY way to go, and even the REPL has its readline quirks. And god bless Revise.jl. I shudder to think of life, it weren’t for Revise, the giant hack that it is. There’s no officially blessed language formatter. LanguageServer.jl uses a formatter and JuliaFormatter.jl kind of exists on its own. And even these formatters don’t do enough, by the way (imo). Two examples that come to mind is converting explicit returns to implicit returns and changing using Foo -> import Foo: x,y. Not to mention the vim plugins for LSP and formatting are not great. Even the most popular Julia-vim plugin has some super odd opinionated un-vim like choices like high jacking TAB and the choice of commentstring syntax etc. All this in daily development is painful as it is, and even more so when I have to review someone’s code. I’m a software engineer by training, and when I have to read domain specific code written by a scientist or a domain specific engineer, or worse when I have to refactor and clean it up, I cringe all the time. Try figuring out which method gets dispatched without using a repl, fun times. Maybe few people port a Pluto notebook script into a production application as much as I do but yikes is it painful. There is SO much down time. Wait for tests, wait for LSP, wait for formatter, wait for static analyzer with JET, make a change, rinse and repeat. Contrast this to using Python, Rust, Zig, or Go and feedback is immediate! And unlike Julia, vscode isn’t the only golden editor. You can use pretty much any editor and you get first class support. All in all, Julia as a language is super interesting. I would probably only use it for small personal projects though. Professionally, I would still stick with python / pypy, or even writing python and rust or go. Multiple dispatch alone isn’t worth the other pain points when working with a large team (>50 people).

deleted 5y ago

[deleted]

sharikous 5y ago

The gap between how fantastic the language is according to Julia fanboys and how annoying my experience has been is very hard on me. Everything needs to install a package, even simple debugging. Graphics is very broken, especially for headless environments. You get incomprehensible, unfixable, error messages since everything is statically linked. But you don't get speed since everything has to compile first. Unicode symbols are encouraged (at minimum it takes an order of magnitude more to type/paste/convert some Greek symbol than to type an English letter). All the experience you feel a smug attitude coming from the environment "we make everything perfect, thoughtful, beautiful for you, if something breaks is your fault" but then something actually breaks... The most beautiful thing about the language is the computational physics community' enthusiasm about it (probably in the hope of finally abandoning Fortran). So JuliaCon's conferences are actually good and you find a lot of interesting computational problems solved in the language. Only that the basic unfriendliness and unsmooth experience, coupled with a lot of immature features, really ruins it for me.

jstx1 5y ago
Absolutely agree about the disconnect between my own experience and the views coming from the community. It has made an already frustrating experience even more off putting.
- blindseer 5y ago
  I agree that the experience is extremely off putting. But having been in the community for almost 5 years now, I have to say there are super awesome lovely people that are mostly silently working in the background and very hard at that. The loud minority unfortunately is grating, and I do wish the stewards of the language established more strict guidelines on conduct or philosophy of the language. I don’t want to name names here, but when prominent members of the Julia community bash other programming languages while ignoring the painful friction in Julia, it comes across as very tone deaf and in poor taste, and does set a bad precedent. I think having a weekly what’s great about Python/Rust/Go/Zig and how can we port this to Julia would be awesome, instead of the weekly gripes about Python/MATLAB/R.

eatonphil 5y ago

Contrary to some folks here I've had a pretty good experience learning Julia while adding support for it as an scripting language in an open-source data IDE I'm building [0]. It makes a lot more sense as a language to me than R (which is also a supported scripting language), but I'm slowly coming around to R too. I do agree that it is pretty slow to start, most other scripting languages I support finish much quicker on simple scripts. But I imagine the reason you use Julia over Ruby/Node.js is the libraries not just the startup time. But I really like that it has a builtin package manager unlike almost any other language (except R) which makes it very easy to install missing dependencies in a try-catch block. (Useful in my situation since its an IDE that runs on your computer using your existing python/ruby/julia install and only depends on a single JSON library.) It's also neat that all hosted Github Actions images come with Julia built in so it's pretty easy to be working with it in automated environments as well. [0] https://github.com/multiprocessio/datastation https://github.com/multiprocessio/datastation

stewbrew 5y ago

Is there a way to statically type check a Julia program? It would be really nice if the compiler threw an error on obviously wrong code.

jakobnissen 5y ago
Yes - the package JET.jl. It's still in its early phases so it's pretty rough, but I use it daily at my job. There are a lot of caveats, though. Julia is fundamentally a dynamic language, so you can easily write code that works perfectly well but where the compiler has no idea what is going on before you run it. That code will not be statically analyzable.
deleted 5y ago
[deleted]

outlace 5y ago

I recently started a relatively complex machine learning project in Julia 1.6 and it’s been great so far. Occasionally the youthful nature of the language creates minor issues (eg fewer answers on stackoverflow) but overall it really has delivered on the promise of being very usable and productive for scientific computing and being fast and highly optimizable.

dunefox 5y ago
What's your project about?
- outlace 5y ago
  Implementing this paper < https://arxiv.org/abs/1903.03129 https://arxiv.org/abs/1903.03129 > for a computer vision application.

amkkma 5y ago

I want to validate the complaints about startup and error messages as a Julia user / fanboy ;) They don't really bother me anymore personally as I've gotten used to them and make frequent use of packagcompiler.jl However, I'd just like to say that the core team is aware of these problems and there's active work being done to address them. The general path seems relatively clear, and it's currently just engineer time limited (not like we've hit a wall or ran out of ideas). But I'm confident that with the recent series a and Sciml picking up steam, these things will get ironed out in the next year or two.

tpoacher 5y ago

It's good to see the package suggestions feature happen. I believe I was the first to raise it as an issue/request on github, oh, 3-4 years ago? (based on how octave does it, which is truly excellent) I remember it caused quite a vivid discussion, which very quickly (and frustratingly) veered off in a completely different tangent in the thread. Good to see someone took it to heart after all :)