3 ms·

This is a good, well-thought out critique. While much of it rings true, I can't say I completely agree: Wrt. static type checking, JET.jl does the job for me.

This is a good, well-thought out critique. While much of it rings true, I can't say I completely agree: Wrt. static type checking, JET.jl does the job for me. I agree it still feels too immature with slowness and important edge cases it fails to consider. More importantly, the ecosystem itself needs to fully embrace type stability for it to be optimally useful, since otherwise you will get a shitton of false positives from functioning, yet unstable dependencies. The good news is that all of these things are improving quickly for JET.jl - it's getting faster and more robust. It still feeds immature since it's actively being developed. There is also the linter, which is available in VSCode. It's pretty good. Nowhere near the level of rust-analyzer, but still decent. You can easily have error types in Julia - see the package ErrorTypes.jl. It's not standard to use it, but I use it in my work code, and it works quite well. You can absolutely write tests next to code and just run one test - see InlineTests.jl and ReTest.jl HOWEVER: * The latency is still terrible, and it really, _really_ hinders development. I don't see that being significantly solved in the next many years, only marginally improved. This can reasonably be a showstopper for some people. You learn tribal knowledge to lessen its blow (wrap things in modules, use Revise etc), but there is no sugarcoating it: It blows. * The lack of statically enforceable interfaces is a real problem, and I think this will NEVER be solved in Julia. There just doesn't seem to be any real motivation from the core team, and no agreement in the community on what such a solution even should look like. * The lack of separation of tests is very annoying as well. That might literally be impossible in Julia since part of its promise is that you can dynamically change definitions that affect other modules. It's what contributes to its great composability. But it also means you need to test ALL of Base if you change one thing.

blindseer 5y ago
Thanks for the reply Jakob. I agree with what you are saying. When JET.jl works it is great. But for large projects it didn't even return when I tried it. I must have waited at least half an hour once. VSCode seems like it is offically blessed and maybe I should just cave and use it for Julia. I use vim/neovim for EVERYTHING else though. Taking me out of my extremely custom tmux + terminal + vim workflow just for Julia development annoys me unnecessarily much. Do you know if there's work on getting this to work in vim/neovim? ErrorTypes.jl, InlineTests.jl, ReTest.jl, SetField.jl all are awesome and I've used them in personal projects. I want to see them in the core language. Maybe ErrorTypes.jl is asking for too much, but tests sorely needs improvement. A SetField like feature literally had a PR open for years and then was just closed https://github.com/JuliaLang/julia/pull/21912 https://github.com/JuliaLang/julia/pull/21912 Without these features in the base language, adoption is going to be so slow. Convincing my team to add a dependency is a lot of work, including updating internal documents, best practices, internal training for how and when to use a certain feature, etc.
- sharikous 5y ago
  Good luck with hoping for adopting those features into Base. Even debugging requires its own package in Julia. But to be fair also Rust is guilty of keeping the base small and leaving important stuff in external crates (serde, tokio,...).
  - adgjlsfhk1 5y ago
    There is interest in improving testing in Base. Retest seems really nice, but has a few caveats. If you have ideas, bring them up in Discourse/Slack.
  - ModernMech 5y ago
    I think it's fine to architect a language in this way as long as there is a good 1st party effort at a comprehensive standard library. The failure mode I see most often of a small core is that there ends up being 100 libraries of varying quality and completeness to do common tasks e.g. parsing JSON.
- jakobnissen 5y ago
  I don't know how well Julia works with other IDEs to be honest. Much of the hard work of VSCode's extension is editor-agnostic, e.g. the LSP, the type checker and the linter - but whether someone has actually implemented a Vim plugin using these, I don't know.
- dklend122 5y ago
  Can you please open up an issue on Jet.jl? Even if you can't provide a MWE, it would be helpful to share these experiences

blindseer 5y ago

Thanks for the reply Jakob. I agree with what you are saying. When JET.jl works it is great. But for large projects it didn't even return when I tried it. I must have waited at least half an hour once. VSCode seems like it is offically blessed and maybe I should just cave and use it for Julia. I use vim/neovim for EVERYTHING else though. Taking me out of my extremely custom tmux + terminal + vim workflow just for Julia development annoys me unnecessarily much. Do you know if there's work on getting this to work in vim/neovim? ErrorTypes.jl, InlineTests.jl, ReTest.jl, SetField.jl all are awesome and I've used them in personal projects. I want to see them in the core language. Maybe ErrorTypes.jl is asking for too much, but tests sorely needs improvement. A SetField like feature literally had a PR open for years and then was just closed https://github.com/JuliaLang/julia/pull/21912 https://github.com/JuliaLang/julia/pull/21912 Without these features in the base language, adoption is going to be so slow. Convincing my team to add a dependency is a lot of work, including updating internal documents, best practices, internal training for how and when to use a certain feature, etc.

sharikous 5y ago
Good luck with hoping for adopting those features into Base. Even debugging requires its own package in Julia. But to be fair also Rust is guilty of keeping the base small and leaving important stuff in external crates (serde, tokio,...).
- adgjlsfhk1 5y ago
  There is interest in improving testing in Base. Retest seems really nice, but has a few caveats. If you have ideas, bring them up in Discourse/Slack.
- ModernMech 5y ago
  I think it's fine to architect a language in this way as long as there is a good 1st party effort at a comprehensive standard library. The failure mode I see most often of a small core is that there ends up being 100 libraries of varying quality and completeness to do common tasks e.g. parsing JSON.
jakobnissen 5y ago
I don't know how well Julia works with other IDEs to be honest. Much of the hard work of VSCode's extension is editor-agnostic, e.g. the LSP, the type checker and the linter - but whether someone has actually implemented a Vim plugin using these, I don't know.
dklend122 5y ago
Can you please open up an issue on Jet.jl? Even if you can't provide a MWE, it would be helpful to share these experiences