6 ms·

I've tried Julia and really liked it, but the user experience was pretty bad. The language really needs faster interactivity or a strong type checker. I found m

by saiojd 6y ago

I've tried Julia and really liked it, but the user experience was pretty bad. The language really needs faster interactivity or a strong type checker. I found myself waiting after than compiler a lot more than in some AOT compiled language like Rust... I fear the language suffers from being overused by people who are familiar with Matlab and Python and draws too much inspiration from them, much like how Rust draws too much inspiration from C++.

cambalache 6y ago
What boggles my mind is that a language oriented to scientific programming has such a lousy time to first plot. I know it has been improving, it is still not acceptable. Not for me as a user, not acceptable for a language who wants to become mainstream.
- oscardssmith 6y ago
  It's a better time to first plot than matlab, which is one of the other major contenders. On my computer it is about 3 seconds, which is noticable, but far from disqualifing.
  - systemvoltage 6y ago
    Julia oversells itself as a general purpose language which I find absolutely out of line. Their marketing needs to be a lot more humble until they figure out the kinks. Also, my guess would be Python and not Matlab as it’s main competitors.
    - eigenspace 6y ago
      In what way is marketing julia as a general purpose programming language 'way out of line'? People use julia to make webservers, write programming languages, create plotting libraries, do scientific analysis, do compiler research, make video games, do HPC, etc. Julia has a design that's indeed strongly informed by scientific computing, but in order to actually meet the needs of the various people using it for scientific and technical purposes, it ended up needing to become a flexible enough language to be useful for anything.
      - systemvoltage 6y ago
        Do you think R or Matlab is a general purpopse language? Sure you could do all these things but should you? Julia is clearly positioned as a scientific computing language. Let's be clear.
        eigenspace 6y ago
        Doing these things in julia is very different from doing these things in R or Matlab. The tooling and ecosystem for non-scientific applications in Julia is growing rapidly and is quite competent. Julia is absolutely a general purpose language. It’s user base skews heavily towards scientific computing, but the demographics and ecosystem are broadening daily.
        systemvoltage 6y ago
        Having used Julia for 2+ years, I couldn't disagree more. Productionizing Julia code has been a total nightmare. The community library support has been growing but hasn't gone through the wringer. Just because things are improving doesn't provide a meaningful understanding against its competitors. I don't see any reason to use Julia over Go for backend webservers. Rust or C++ for systems programming. And frankly, I prefer Python for scientific computing. Julia also has a tiny standard library and lots of flaky external libs which make productionization of code a risky adventure which I have personally been bitten by. Most people are allured by Julia's overhyped marketing which is a shame because the original paper by Stefan is pretty impressive. We're seeing some criticisms of Julia in this thread, rightfully so. My advise to people who are subscribed to Julia's marketing is to listen to people that are complaining. No one wants to just complain, they're saying that because of many reasons. Be humble and try to listen, accept Julia's many shortcomings (error messages and stack traces, library support, startup time, IDE, debugging, etc.). Julia has many shortcomings that are only apparently after using it outside of the Jupyter Notebooks. Not accepting those makes you an annoying fanboy.
        eigenspace 6y ago
        > I don't see any reason to use Julia over Go for backend webservers. Rust or C++ for systems programming. And frankly, I prefer Python for scientific computing. Sure, I would never claim Julia is being the best language for webservers or systems programming. If someone came to me saying they wanted to do this in Julia, I'd probably tell them "if this is important, I'd probably look at a more established language for this purpose unless you have a good reason to want to use julia for this" That doesn't make julia not a general purpose programming language. It just means it's not the best language for every imaginable purpose (no language is). I personally prefer Julia very strongly for scientific computing to it's competitors, and because of the amount of time I've invested in it for that, I also do many other things in it and I find it quite nice for this. It's totally fair that you prefer Python for scientific computing. Python has a great ecosystem and huge community with tonnes of investment! It's an incredibly stiff competitor. I prefer Julia, and think I have strong reasons to do so, but everyone's needs and desires and different. > No one wants to just complain This is an empirical claim about human psychology and it's false. But regardless, yes there are a lot of totally valid criticisms of julia in this thread! Just because these criticisms exist and some of them have good points doesn't make julia a bad language though. Please consider the fact that not everybody has the same needs, desires and temperament as you. Every language has major probelms with it, but different people feel these problems differently. For many people (for example, me), Julia is a gigantic breath of fresh air! For others, it's painful and clunky. I think there's a lot of good here that people should see and check out and think about, even if they decide it's not for them. Especially because these things improve every day. ___________________________________________________ Just a disclaimer in case anyone is suspicious about my affiliations: I have absolutely zero financial stake in Julia's success. I am not employed by anyone who would benefit from more people switching to julia. I'm a physics PhD student. I simply find julia very useful and pleasant to use and want to share that with others.
    - adgjlsfhk1 6y ago
      Julia has a lot of main competitors. I would consider Julia a competitor to Fortran, C, Matlab, R, and python. If you look at DifferentialEquations.jl or the clima.jl package, these are packages that are competing with low level libraries that would traditionally be written in C or Fortran. It competes with these by offering comparable performance, while having much better quality of life features (like automatic PGO, a package system, metaprogramming, and not having to deal with make files). It competes with matlab by having an incredibly rich linear algebra library, while being free and not making you do dumb stuff like 1 function per file.
- rightbyte 6y ago
  The plot is also very simple. No zoom, brush, save to file, label, title, regression etc that you need to process it in a GUI and save for a report. I would really like to use Julia as a "Matlab or Octave but with nice string concatenation" but the UI is just lacking for one off calculations and data processing.
  - thebooktocome 6y ago
    There are absolutely labels, titles, and the ability to save figures to files. I used to deliver project reports to customers using a combination of Julia and LaTeX. It was perfectly suitable for that application.
    - oxinabox 6y ago
      I think they mean no GUI for that. To manually (rather than programatically) do this.
      - ForHackernews 6y ago
        ...it's a programming language, not an Excel competitor. You could use Julia to build some kind of GUI plot-making tool.
  - Sukera 6y ago
    I'm afraid I don't understand your comment - both Plots.jl as well as Makie.jl (the two most commonly used plotting packages, as far as I know) support all of those things. Makie.jl does so natively, Plots.jl does so if the backend (e.g. Plotly, PyPlot) supports interactivity (the rest is available by default). Do you mind giving an example, such that this could be improved further?
    - rightbyte 6y ago
      Ye sorry I meant in the plot window (GUI), not the scripting. For data processing of lab measurements zooming and panning, brushing, "drag to select" etc in an easy way is really convenient since you don't know where in the plot interesting stuff will be in advance. Adding titles and labels, text arrows etc is a nice extra. Matlab have quite good such capabilities, Octave is more limited (you can't add titles, labels, regression lines or brush away data points, get simple data statistics like sums or std devs like in Matlab, but you can zoom and pan, save to file etc). Julia seems to launch a Qt-window with plot, so adding some menu bar with zoom and pan shouldn't add too much bloat. E.g. exploring roots benefits from zooming a lot. EDIT: You seem to be able to switch "backend" of Plots to eg. PyPlot for some functionality I didn't know that.
Sukera 6y ago
The most important part about the releases since 1.0 is that compile time has been significantly reduced, the article touches on basically all ways how this has been done - may I ask when you've last tried it?
- saiojd 6y ago
  A few months ago. First time to plot is noticeably better than it was a few versions ago, but still extremely slow compared to Python. The article gives a benchmark of 9 seconds. I mean, come on. The main problem I had was simply that what any time I needed to modify a struct field, or anytime my program crashed, or any time the buggy IDE extension crashed, I needed to recompile everything. I also haven't found anyone particularly interested in basic things like interfaces, despite the language supporting type hierarchies (why can't we enforce contracts for types? The whole language is built around overloading...) Overall this is very frustrating as the language is excellent is many regards, in particular multiple dispatch and the compilation model are just great. The "just ahed of time" compilation is one of those obvious-in-hindsight ideas IMO, better than full interpretation or full compilation for nearly all use cases, if only it could be cached between interpreter sessions or if you didn't need to restart all the time...
  - Sukera 6y ago
    I know that there are plans to cache even more, but other than that I can basically only recommend to put distinct projects into proper projects (with a module and Project.toml). That will already cache precompiled code for that module, even between sessions. Having things in a script won't have that benefit. For experimenting with struct layouts, I've found that NamedTuples (https://docs.julialang.org/en/v1/base/base/#Core.NamedTuple https://docs.julialang.org/en/v1/base/base/#Core.NamedTuple) are amazing for prototyping, since they can be accessed via A.b just like structs but don't have the limitation of being const global. The dynamism and flexibility combined with the compilation model is basically what leads down this path of recompilation, unfortunately. Since importing packages may change behaviour/invalidate some compiled method (that's what the SnoopCompile stuff in the article was about), it's nontrivial to just begin caching things left and right. You'd end up with an exponential explosion in the number of methods to cache, wasting huge amounts of disk space. That's not to say that there aren't more things that could be done, just that it's hard to do so.
superbcarrot 6y ago
I'm trying really hard to like Julia but constantly chasing "ERROR: MethodError: no method matching" messages gets frustrating very quickly.
- DNF2 6y ago
  When do you run into this kind of problem? Is it possible that you are over-typing your function signatures? The generally recommended style is to write generic code with loose type restrictions, or even none at all.
sgt101 6y ago
>"strong type checker"???? I like julia because of the super powerful and super strong type checking. Have I misunderstood what is meant by strong type checker?
- aliceryhl 6y ago
  What do you even mean? It doesn't even catch that an argument's type doesn't match on a function call with types specified. It also can't catch trivial stuff like misspelling a struct field on a variable of known type. If you want to be called a "super strong" type checker, you really have to catch that kind of simple issue at compile-time, _not_ when I run the code.
  - adgjlsfhk1 6y ago
    Technically it is catching the type error at compile time (but compile time is Just Ahead Of Time). If you want something that feels more like type checking in a statically compiled language, you should definitely check out https://github.com/aviatesk/JET.jl https://github.com/aviatesk/JET.jl
  - sgt101 6y ago
    Ahhhh - you want a statically typed language. That's definitely not Julia, you're probably best off with Java there.
    - aliceryhl 6y ago
      I'm well aware which languages are statically typed and which are not. I was answering your question: > Have I misunderstood what is meant by strong type checker?
  - gugagore 6y ago
    > It also can't catch trivial stuff like misspelling a struct field on a variable of known type. The default definition is `getproperty(x, f::Symbol) = getfield(x, f)` and `getproperty` can be overridden for a type, so `foo.a` can succeed even if `getfield(foo, :a)` fails. (`getfield` cannot be overridden). So it's not trivial to determine, given the the of `foo`, from the syntax `foo.a` whether that code errors.

by saiojd 6y ago

cambalache 6y ago

What boggles my mind is that a language oriented to scientific programming has such a lousy time to first plot. I know it has been improving, it is still not acceptable. Not for me as a user, not acceptable for a language who wants to become mainstream.

oscardssmith 6y ago
It's a better time to first plot than matlab, which is one of the other major contenders. On my computer it is about 3 seconds, which is noticable, but far from disqualifing.
- systemvoltage 6y ago
  Julia oversells itself as a general purpose language which I find absolutely out of line. Their marketing needs to be a lot more humble until they figure out the kinks. Also, my guess would be Python and not Matlab as it’s main competitors.
  - eigenspace 6y ago
    In what way is marketing julia as a general purpose programming language 'way out of line'? People use julia to make webservers, write programming languages, create plotting libraries, do scientific analysis, do compiler research, make video games, do HPC, etc. Julia has a design that's indeed strongly informed by scientific computing, but in order to actually meet the needs of the various people using it for scientific and technical purposes, it ended up needing to become a flexible enough language to be useful for anything.
    - systemvoltage 6y ago
      Do you think R or Matlab is a general purpopse language? Sure you could do all these things but should you? Julia is clearly positioned as a scientific computing language. Let's be clear.
      - eigenspace 6y ago
        Doing these things in julia is very different from doing these things in R or Matlab. The tooling and ecosystem for non-scientific applications in Julia is growing rapidly and is quite competent. Julia is absolutely a general purpose language. It’s user base skews heavily towards scientific computing, but the demographics and ecosystem are broadening daily.
        systemvoltage 6y ago
        Having used Julia for 2+ years, I couldn't disagree more. Productionizing Julia code has been a total nightmare. The community library support has been growing but hasn't gone through the wringer. Just because things are improving doesn't provide a meaningful understanding against its competitors. I don't see any reason to use Julia over Go for backend webservers. Rust or C++ for systems programming. And frankly, I prefer Python for scientific computing. Julia also has a tiny standard library and lots of flaky external libs which make productionization of code a risky adventure which I have personally been bitten by. Most people are allured by Julia's overhyped marketing which is a shame because the original paper by Stefan is pretty impressive. We're seeing some criticisms of Julia in this thread, rightfully so. My advise to people who are subscribed to Julia's marketing is to listen to people that are complaining. No one wants to just complain, they're saying that because of many reasons. Be humble and try to listen, accept Julia's many shortcomings (error messages and stack traces, library support, startup time, IDE, debugging, etc.). Julia has many shortcomings that are only apparently after using it outside of the Jupyter Notebooks. Not accepting those makes you an annoying fanboy.
        eigenspace 6y ago
        > I don't see any reason to use Julia over Go for backend webservers. Rust or C++ for systems programming. And frankly, I prefer Python for scientific computing. Sure, I would never claim Julia is being the best language for webservers or systems programming. If someone came to me saying they wanted to do this in Julia, I'd probably tell them "if this is important, I'd probably look at a more established language for this purpose unless you have a good reason to want to use julia for this" That doesn't make julia not a general purpose programming language. It just means it's not the best language for every imaginable purpose (no language is). I personally prefer Julia very strongly for scientific computing to it's competitors, and because of the amount of time I've invested in it for that, I also do many other things in it and I find it quite nice for this. It's totally fair that you prefer Python for scientific computing. Python has a great ecosystem and huge community with tonnes of investment! It's an incredibly stiff competitor. I prefer Julia, and think I have strong reasons to do so, but everyone's needs and desires and different. > No one wants to just complain This is an empirical claim about human psychology and it's false. But regardless, yes there are a lot of totally valid criticisms of julia in this thread! Just because these criticisms exist and some of them have good points doesn't make julia a bad language though. Please consider the fact that not everybody has the same needs, desires and temperament as you. Every language has major probelms with it, but different people feel these problems differently. For many people (for example, me), Julia is a gigantic breath of fresh air! For others, it's painful and clunky. I think there's a lot of good here that people should see and check out and think about, even if they decide it's not for them. Especially because these things improve every day. ___________________________________________________ Just a disclaimer in case anyone is suspicious about my affiliations: I have absolutely zero financial stake in Julia's success. I am not employed by anyone who would benefit from more people switching to julia. I'm a physics PhD student. I simply find julia very useful and pleasant to use and want to share that with others.
  - adgjlsfhk1 6y ago
    Julia has a lot of main competitors. I would consider Julia a competitor to Fortran, C, Matlab, R, and python. If you look at DifferentialEquations.jl or the clima.jl package, these are packages that are competing with low level libraries that would traditionally be written in C or Fortran. It competes with these by offering comparable performance, while having much better quality of life features (like automatic PGO, a package system, metaprogramming, and not having to deal with make files). It competes with matlab by having an incredibly rich linear algebra library, while being free and not making you do dumb stuff like 1 function per file.
rightbyte 6y ago
The plot is also very simple. No zoom, brush, save to file, label, title, regression etc that you need to process it in a GUI and save for a report. I would really like to use Julia as a "Matlab or Octave but with nice string concatenation" but the UI is just lacking for one off calculations and data processing.
- thebooktocome 6y ago
  There are absolutely labels, titles, and the ability to save figures to files. I used to deliver project reports to customers using a combination of Julia and LaTeX. It was perfectly suitable for that application.
  - oxinabox 6y ago
    I think they mean no GUI for that. To manually (rather than programatically) do this.
    - ForHackernews 6y ago
      ...it's a programming language, not an Excel competitor. You could use Julia to build some kind of GUI plot-making tool.
- Sukera 6y ago
  I'm afraid I don't understand your comment - both Plots.jl as well as Makie.jl (the two most commonly used plotting packages, as far as I know) support all of those things. Makie.jl does so natively, Plots.jl does so if the backend (e.g. Plotly, PyPlot) supports interactivity (the rest is available by default). Do you mind giving an example, such that this could be improved further?
  - rightbyte 6y ago
    Ye sorry I meant in the plot window (GUI), not the scripting. For data processing of lab measurements zooming and panning, brushing, "drag to select" etc in an easy way is really convenient since you don't know where in the plot interesting stuff will be in advance. Adding titles and labels, text arrows etc is a nice extra. Matlab have quite good such capabilities, Octave is more limited (you can't add titles, labels, regression lines or brush away data points, get simple data statistics like sums or std devs like in Matlab, but you can zoom and pan, save to file etc). Julia seems to launch a Qt-window with plot, so adding some menu bar with zoom and pan shouldn't add too much bloat. E.g. exploring roots benefits from zooming a lot. EDIT: You seem to be able to switch "backend" of Plots to eg. PyPlot for some functionality I didn't know that.

Sukera 6y ago

The most important part about the releases since 1.0 is that compile time has been significantly reduced, the article touches on basically all ways how this has been done - may I ask when you've last tried it?

saiojd 6y ago
A few months ago. First time to plot is noticeably better than it was a few versions ago, but still extremely slow compared to Python. The article gives a benchmark of 9 seconds. I mean, come on. The main problem I had was simply that what any time I needed to modify a struct field, or anytime my program crashed, or any time the buggy IDE extension crashed, I needed to recompile everything. I also haven't found anyone particularly interested in basic things like interfaces, despite the language supporting type hierarchies (why can't we enforce contracts for types? The whole language is built around overloading...) Overall this is very frustrating as the language is excellent is many regards, in particular multiple dispatch and the compilation model are just great. The "just ahed of time" compilation is one of those obvious-in-hindsight ideas IMO, better than full interpretation or full compilation for nearly all use cases, if only it could be cached between interpreter sessions or if you didn't need to restart all the time...
- Sukera 6y ago
  I know that there are plans to cache even more, but other than that I can basically only recommend to put distinct projects into proper projects (with a module and Project.toml). That will already cache precompiled code for that module, even between sessions. Having things in a script won't have that benefit. For experimenting with struct layouts, I've found that NamedTuples (https://docs.julialang.org/en/v1/base/base/#Core.NamedTuple https://docs.julialang.org/en/v1/base/base/#Core.NamedTuple) are amazing for prototyping, since they can be accessed via A.b just like structs but don't have the limitation of being const global. The dynamism and flexibility combined with the compilation model is basically what leads down this path of recompilation, unfortunately. Since importing packages may change behaviour/invalidate some compiled method (that's what the SnoopCompile stuff in the article was about), it's nontrivial to just begin caching things left and right. You'd end up with an exponential explosion in the number of methods to cache, wasting huge amounts of disk space. That's not to say that there aren't more things that could be done, just that it's hard to do so.

superbcarrot 6y ago

I'm trying really hard to like Julia but constantly chasing "ERROR: MethodError: no method matching" messages gets frustrating very quickly.

DNF2 6y ago
When do you run into this kind of problem? Is it possible that you are over-typing your function signatures? The generally recommended style is to write generic code with loose type restrictions, or even none at all.

sgt101 6y ago

>"strong type checker"???? I like julia because of the super powerful and super strong type checking. Have I misunderstood what is meant by strong type checker?

aliceryhl 6y ago
What do you even mean? It doesn't even catch that an argument's type doesn't match on a function call with types specified. It also can't catch trivial stuff like misspelling a struct field on a variable of known type. If you want to be called a "super strong" type checker, you really have to catch that kind of simple issue at compile-time, _not_ when I run the code.
- adgjlsfhk1 6y ago
  Technically it is catching the type error at compile time (but compile time is Just Ahead Of Time). If you want something that feels more like type checking in a statically compiled language, you should definitely check out https://github.com/aviatesk/JET.jl https://github.com/aviatesk/JET.jl
- sgt101 6y ago
  Ahhhh - you want a statically typed language. That's definitely not Julia, you're probably best off with Java there.
  - aliceryhl 6y ago
    I'm well aware which languages are statically typed and which are not. I was answering your question: > Have I misunderstood what is meant by strong type checker?
- gugagore 6y ago
  > It also can't catch trivial stuff like misspelling a struct field on a variable of known type. The default definition is `getproperty(x, f::Symbol) = getfield(x, f)` and `getproperty` can be overridden for a type, so `foo.a` can succeed even if `getfield(foo, :a)` fails. (`getfield` cannot be overridden). So it's not trivial to determine, given the the of `foo`, from the syntax `foo.a` whether that code errors.