34 ms·

Your 1st, 2nd and 4th points seem to be fundamentally the same, which is compile time latency making interactive use slow. That's definitely a problem for a lan

Your 1st, 2nd and 4th points seem to be fundamentally the same, which is compile time latency making interactive use slow. That's definitely a problem for a language trying to solve the two language problem of having high interactivity and high performance at the same time, and the compiler team [1] are now focusing on that issue on versions 1.4 and beyond hopefully it will get to the point where it isn't a problem anymore. Documentation is always a problem (especially for smaller packages), but I don't feel I had more issue with Julia than other languages (with a few exceptions, some languages managed to have an exceptional culture in terms of great documentation). Most of the issues were due to the fact that Julia just got to 1.0 a year ago, and the breaking changes made so most documentation became outdated, but this will only become less of a problem since the language became stable. Julia has one of the best REPL of any language I used, and thankfully I didn't meet with any problems with it. Might be a good idea to create an issue on the github. [1] https://discourse.julialang.org/t/compiler-work-priorities/17623 https://discourse.julialang.org/t/compiler-work-priorities/1...

siproprio 7y ago
Nope, they are not the same points! 1. It's about compiler latency. Compiling happens when you call the function. That indeed can and should be improved. But there are other things that contribute to the experience being shitty. 2. Is about adding a package, when adding a package it downloads all the dependencies (which includes cairo, and WinRPM on windows which all have problems of their own). 4. Is about the poor atom experience - I'm not a fan of electron apps myself - and about the slowness of the LSP on vscode, which just does not provide a good experience on vs code and things are often broken, especially on the latest versions. If you think all these things are "compiler latency" then perhaps you're part of the problem.
- ddragon 7y ago
  Fair enough, you mentioned the speed of adding a package and I assume it was the build time after the download (which is mostly git). I have to confess that I don't consider the speed of the initial build essential since it's a one time thing (correctly and efficiently building and handling dependencies is, which it does very well in my opinion). Also, I think they are testing now a way to deliver binary libraries within the deps which can improve the situation with the external dependencies. Visual Studio Code is definitely fast enough in my machine (especially with a Revise.jl workflow), which is why I also assumed it was stuff like running part of the code or using the Language Server Protocol, which will hit the same compilation lag. I agree that Atom is slow, and it's one of the reason I don't use it. Though I'm clearly biased since my experience is entirely in Linux, it's possible that the Windows experience is just worse.
  - siproprio 7y ago
    The VS Code extension took a long time to support newer versions of the language. What happens in between figuring out how to make basic tooling work and actually getting something done is frustration. Building is so clearly not a one-time thing if you use the language to explore solutions, and play with things.

siproprio 7y ago

Nope, they are not the same points! 1. It's about compiler latency. Compiling happens when you call the function. That indeed can and should be improved. But there are other things that contribute to the experience being shitty. 2. Is about adding a package, when adding a package it downloads all the dependencies (which includes cairo, and WinRPM on windows which all have problems of their own). 4. Is about the poor atom experience - I'm not a fan of electron apps myself - and about the slowness of the LSP on vscode, which just does not provide a good experience on vs code and things are often broken, especially on the latest versions. If you think all these things are "compiler latency" then perhaps you're part of the problem.

ddragon 7y ago
Fair enough, you mentioned the speed of adding a package and I assume it was the build time after the download (which is mostly git). I have to confess that I don't consider the speed of the initial build essential since it's a one time thing (correctly and efficiently building and handling dependencies is, which it does very well in my opinion). Also, I think they are testing now a way to deliver binary libraries within the deps which can improve the situation with the external dependencies. Visual Studio Code is definitely fast enough in my machine (especially with a Revise.jl workflow), which is why I also assumed it was stuff like running part of the code or using the Language Server Protocol, which will hit the same compilation lag. I agree that Atom is slow, and it's one of the reason I don't use it. Though I'm clearly biased since my experience is entirely in Linux, it's possible that the Windows experience is just worse.
- siproprio 7y ago
  The VS Code extension took a long time to support newer versions of the language. What happens in between figuring out how to make basic tooling work and actually getting something done is frustration. Building is so clearly not a one-time thing if you use the language to explore solutions, and play with things.