7 ms·

I really want to love Julia language but the overhead of package loading annoys me. Perhaps this may be just me being lazy or spoiled after using R packages or

I really want to love Julia language but the overhead of package loading annoys me. Perhaps this may be just me being lazy or spoiled after using R packages or Python libraries.

chrisjharris 6y ago
You mean, the time it takes at run-time? I'm not quite sure what you mean - I think Julia's package management is generally better than Python (which is a mess) - it doesn't play well with Nix but I can't really blame it for that.
- kyllo 6y ago
  I think they're referring to the JIT compilation time. There are some ways to mitigate it, such as creating an image using PackageCompiler.jl, but it's definitely a noticeable issue IME. https://julialang.github.io/PackageCompiler.jl/dev/ https://julialang.github.io/PackageCompiler.jl/dev/
alpaca128 6y ago
One of the things I took away from trying Julia was that unicode is incredibly dumb in some aspects. Unicode lacks support for parts of the latin alphabet in subscript and superscript formatting(similar for the greek alphabet)[0]. As Julia relies on Unicode for its neatly formatted variable names this is an annoying limitation that the developers can't even do much about. Unicode has over 100k symbols, including about 3500 emoji. But a continuous set of 26 small letters, either in lowercase or uppercase(or both) is too much bloat apparently. [0]: https://stackoverflow.com/questions/17908593/how-to-find-the-unicode-of-the-subscript-alphabet/17909597#17909597 https://stackoverflow.com/questions/17908593/how-to-find-the...
- jonniedie 6y ago
  Julia doesn’t rely on any Unicode. It just gives you the option to use it. If it’s not useful to you, feel free to not use it.
  - Buttons840 6y ago
    How would one not use Unicode? Every character on my keyboard and screen are Unicode characters.
    - elcomet 6y ago
      Most of them are ascii as well.
- adgjlsfhk1 6y ago
  What's the alternative? If you want julia files to be editable by regular programs, I can't think what else you would use.
  - alpaca128 6y ago
    Which is why I am so disappointed about those gaps in Unicode. Apparently the Unicode consortium doesn't care because in their eyes such things have to be handled by higher level formatting software, but that's not a very convincing excuse imho. It's just so bewildering when on one hand lowercase superscript is missing exactly one letter for the full coverage, and at the same time Unicode has characters like "Grinning cat face with smiling eyes"(U+1F638). Just what I needed. It's a bit disappointing because together with the integration in the REPL this feature in Julia works well enough to give a glimpse of the potential but when trying to experiment more it shows gaps that make it a bit of a trial-and-error situation. Better direct support in standardized encodings could make this much more usable and maybe not just in one specific language.
    - adgjlsfhk1 6y ago
      IMO, the solution here from unicode's end seems really clear. Just add superscript and subscript modifiers (the same way emoji have skin-tone and gender modifiers). That way, you don't need to add special ones for every character people want different versions of.
    - xiaodai 6y ago
      How about super and sub scripts for thr 35000 or some Chinese character? I think thr unicode committee made the right call
      - alpaca128 6y ago
        How about a single "superscript" and "subscript" modifier that handles any of the other Unicode symbols? The standard already has enough formatting options to make smartphones crash by sending them a text message(as could be seen multiple times on both Android and iOS). If you think the unicode committee made the right call, please explain why the decision to add smiling cat pictures and over 10 heart symbols was correct but not supporting everyday maths notation.
- cbkeller 6y ago
  I don't mind Julia's Unicode support, but definitely share the gripe about how the Unicode standard doesn't yet support a complete a-z set of sub/superscripts!
- montalbano 6y ago
  Julia core developers are at the forefront of trying to push for a better unicode standard: https://github.com/stevengj/subsuper-proposal https://github.com/stevengj/subsuper-proposal
hntrader 6y ago
From a data science perspective do you see any obvious advantages to Julia compared to R/Python?
- cbkeller 6y ago
  I think it really depends on what subset of data science you have in mind. For me it solved my personal version of the "two-language" problem, but YMMV. Longer-term I think the most interesting thing about the Julia ecosystem is the composability that comes from dispatch-oriented programming [1] [1] https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY
systemvoltage 6y ago
Yes. And the warts in the language are pretty off putting. Original paper was awesome. Execution of the language IMO hasn’t been good despite of great marketing.
lasagnaphil 6y ago
Yeah, it's still dissapointing how much system resources it takes to get a plot running (even with all the improvements in 1.6, benchmark taken from https://www.oxinabox.net/2021/02/13/Julia-1.6-what-has-changed-since-1.0.html https://www.oxinabox.net/2021/02/13/Julia-1.6-what-has-chang...). julia> @time (using Plots; display(plot(1:0.1:10, sin.(1:0.1:10)))) 9.694037 seconds (18.29 M allocations: 1.164 GiB, 4.17% gc time, 0.40% compilation time) To be honest, this isn't really something the devs should be proud about. 10 seconds, 18.29 M allocations and 1.164 GiB of memory just to render a simple static image is just unacceptable. In order for Julia to be a good-enough language for general scientific usage the current slow LLVM-based JIT compiler sadly isn't enough. I really want Julia to succeed, but this one problem is triumphing over every good language feature. In an ideal world Julia would have two backends: - A fast, hand-made JIT backend (something like LuaJIT) which is mostly interpreted and only JIT-compiled in frequently run code paths. - The current slow, almost-AOT-like LLVM backend which is only used for precompilation of packages It's just like Debug/Release bulids in C++, except that the Debug builds are lightning fast to compile (but slower at runtime) and Release builds are slower to compile (but hyper-optimized for runtime speed). I guess there's going to be an immense engineering effort if something like this happens, given that Julia today is immensely coupled with the LLVM compiler/runtime. But that's just my pipe dream.
- newswasboring 6y ago
  Here we go again. Those allocations and run time can be avoided entirely using sysimages. Latest vscode extension gives a convenient build task for this. It seems like every time julia is mentioned, someone has to clarify this.
  - andi999 6y ago
    Wow, the Julia cult seems to be really welcoming to new prospects.
  - lasagnaphil 6y ago
    The problem I seem with sysimages, is that the whole process is incredibly unergonomic for exploratory coding, which Julia always claims it is a primary use-case for. When you want to just glue some packages and quickly test out some results, the last thing you want to do is to think about what kinds of functions from libraries you are going to use beforehand, carefully write it in a precompilation file, and wait for the compiler to precompile and cache those code paths! And once those dependencies change even a bit you need to wait for precompilation again, which happens a lot when you're prototyping things fast or upgrading versions (for example, this X numerical computation library doesn't have a particular feature I want to use, so I want to switch to another library Y, but then you need to wait for everything to be precompiled again) The reality is that most people just want to fire up a virtualenv and do the occasional "pip install <my libraries>" and don't want to get involved in any of this stuff. (As someone who uses C++ I have a lot more patience than other people, but you shouldn't really expect much from others) I think Julia needs to throw away some of the unnecessary obsession for just-ahead-of-time (JAOT) compilation. Compiling everything beforehand to LLVM machine code seems good for raw runtime speed, but it doesn't matter when it takes so much setup time to even just glue some simple libraries. Julia should seriously consider running most of the less-computationally intensive codepaths in a custom-made interpreter without LLVM, while precompiling the numerically intensive parts of library code in raw machine code with the current LLVM backend. Maybe there should be a flag you can use to mark certain functions to be unconditionally compiled AOT-style, and leave the rest to the interpreter. Interpreters can be made surprisingly fast with some effort - stuff like the interpreter in LuaJIT (https://luajit.org/ https://luajit.org/) and HashLink (https://hashlink.haxe.org/ https://hashlink.haxe.org/) is what comes into my mind.
tasubotadas 6y ago
Or the fact that once you define a struct, it cannot be redefined again and you need to reload the repl
- dunefox 6y ago
  You can put it in a module, then you can change and reload in the repl without restarting.
deleted 6y ago
[deleted]

I really want to love Julia language but the overhead of package loading annoys me. Perhaps this may be just me being lazy or spoiled after using R packages or Python libraries.

chrisjharris 6y ago

You mean, the time it takes at run-time? I'm not quite sure what you mean - I think Julia's package management is generally better than Python (which is a mess) - it doesn't play well with Nix but I can't really blame it for that.

kyllo 6y ago
I think they're referring to the JIT compilation time. There are some ways to mitigate it, such as creating an image using PackageCompiler.jl, but it's definitely a noticeable issue IME. https://julialang.github.io/PackageCompiler.jl/dev/ https://julialang.github.io/PackageCompiler.jl/dev/

alpaca128 6y ago

One of the things I took away from trying Julia was that unicode is incredibly dumb in some aspects. Unicode lacks support for parts of the latin alphabet in subscript and superscript formatting(similar for the greek alphabet)[0]. As Julia relies on Unicode for its neatly formatted variable names this is an annoying limitation that the developers can't even do much about. Unicode has over 100k symbols, including about 3500 emoji. But a continuous set of 26 small letters, either in lowercase or uppercase(or both) is too much bloat apparently. [0]: https://stackoverflow.com/questions/17908593/how-to-find-the-unicode-of-the-subscript-alphabet/17909597#17909597 https://stackoverflow.com/questions/17908593/how-to-find-the...

jonniedie 6y ago
Julia doesn’t rely on any Unicode. It just gives you the option to use it. If it’s not useful to you, feel free to not use it.
- Buttons840 6y ago
  How would one not use Unicode? Every character on my keyboard and screen are Unicode characters.
  - elcomet 6y ago
    Most of them are ascii as well.
adgjlsfhk1 6y ago
What's the alternative? If you want julia files to be editable by regular programs, I can't think what else you would use.
- alpaca128 6y ago
  Which is why I am so disappointed about those gaps in Unicode. Apparently the Unicode consortium doesn't care because in their eyes such things have to be handled by higher level formatting software, but that's not a very convincing excuse imho. It's just so bewildering when on one hand lowercase superscript is missing exactly one letter for the full coverage, and at the same time Unicode has characters like "Grinning cat face with smiling eyes"(U+1F638). Just what I needed. It's a bit disappointing because together with the integration in the REPL this feature in Julia works well enough to give a glimpse of the potential but when trying to experiment more it shows gaps that make it a bit of a trial-and-error situation. Better direct support in standardized encodings could make this much more usable and maybe not just in one specific language.
  - adgjlsfhk1 6y ago
    IMO, the solution here from unicode's end seems really clear. Just add superscript and subscript modifiers (the same way emoji have skin-tone and gender modifiers). That way, you don't need to add special ones for every character people want different versions of.
  - xiaodai 6y ago
    How about super and sub scripts for thr 35000 or some Chinese character? I think thr unicode committee made the right call
    - alpaca128 6y ago
      How about a single "superscript" and "subscript" modifier that handles any of the other Unicode symbols? The standard already has enough formatting options to make smartphones crash by sending them a text message(as could be seen multiple times on both Android and iOS). If you think the unicode committee made the right call, please explain why the decision to add smiling cat pictures and over 10 heart symbols was correct but not supporting everyday maths notation.
cbkeller 6y ago
I don't mind Julia's Unicode support, but definitely share the gripe about how the Unicode standard doesn't yet support a complete a-z set of sub/superscripts!
montalbano 6y ago
Julia core developers are at the forefront of trying to push for a better unicode standard: https://github.com/stevengj/subsuper-proposal https://github.com/stevengj/subsuper-proposal

hntrader 6y ago

From a data science perspective do you see any obvious advantages to Julia compared to R/Python?

cbkeller 6y ago
I think it really depends on what subset of data science you have in mind. For me it solved my personal version of the "two-language" problem, but YMMV. Longer-term I think the most interesting thing about the Julia ecosystem is the composability that comes from dispatch-oriented programming [1] [1] https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY

systemvoltage 6y ago

Yes. And the warts in the language are pretty off putting. Original paper was awesome. Execution of the language IMO hasn’t been good despite of great marketing.

lasagnaphil 6y ago

Yeah, it's still dissapointing how much system resources it takes to get a plot running (even with all the improvements in 1.6, benchmark taken from https://www.oxinabox.net/2021/02/13/Julia-1.6-what-has-changed-since-1.0.html https://www.oxinabox.net/2021/02/13/Julia-1.6-what-has-chang...). julia> @time (using Plots; display(plot(1:0.1:10, sin.(1:0.1:10)))) 9.694037 seconds (18.29 M allocations: 1.164 GiB, 4.17% gc time, 0.40% compilation time) To be honest, this isn't really something the devs should be proud about. 10 seconds, 18.29 M allocations and 1.164 GiB of memory just to render a simple static image is just unacceptable. In order for Julia to be a good-enough language for general scientific usage the current slow LLVM-based JIT compiler sadly isn't enough. I really want Julia to succeed, but this one problem is triumphing over every good language feature. In an ideal world Julia would have two backends: - A fast, hand-made JIT backend (something like LuaJIT) which is mostly interpreted and only JIT-compiled in frequently run code paths. - The current slow, almost-AOT-like LLVM backend which is only used for precompilation of packages It's just like Debug/Release bulids in C++, except that the Debug builds are lightning fast to compile (but slower at runtime) and Release builds are slower to compile (but hyper-optimized for runtime speed). I guess there's going to be an immense engineering effort if something like this happens, given that Julia today is immensely coupled with the LLVM compiler/runtime. But that's just my pipe dream.

newswasboring 6y ago
Here we go again. Those allocations and run time can be avoided entirely using sysimages. Latest vscode extension gives a convenient build task for this. It seems like every time julia is mentioned, someone has to clarify this.
- andi999 6y ago
  Wow, the Julia cult seems to be really welcoming to new prospects.
- lasagnaphil 6y ago
  The problem I seem with sysimages, is that the whole process is incredibly unergonomic for exploratory coding, which Julia always claims it is a primary use-case for. When you want to just glue some packages and quickly test out some results, the last thing you want to do is to think about what kinds of functions from libraries you are going to use beforehand, carefully write it in a precompilation file, and wait for the compiler to precompile and cache those code paths! And once those dependencies change even a bit you need to wait for precompilation again, which happens a lot when you're prototyping things fast or upgrading versions (for example, this X numerical computation library doesn't have a particular feature I want to use, so I want to switch to another library Y, but then you need to wait for everything to be precompiled again) The reality is that most people just want to fire up a virtualenv and do the occasional "pip install <my libraries>" and don't want to get involved in any of this stuff. (As someone who uses C++ I have a lot more patience than other people, but you shouldn't really expect much from others) I think Julia needs to throw away some of the unnecessary obsession for just-ahead-of-time (JAOT) compilation. Compiling everything beforehand to LLVM machine code seems good for raw runtime speed, but it doesn't matter when it takes so much setup time to even just glue some simple libraries. Julia should seriously consider running most of the less-computationally intensive codepaths in a custom-made interpreter without LLVM, while precompiling the numerically intensive parts of library code in raw machine code with the current LLVM backend. Maybe there should be a flag you can use to mark certain functions to be unconditionally compiled AOT-style, and leave the rest to the interpreter. Interpreters can be made surprisingly fast with some effort - stuff like the interpreter in LuaJIT (https://luajit.org/ https://luajit.org/) and HashLink (https://hashlink.haxe.org/ https://hashlink.haxe.org/) is what comes into my mind.

tasubotadas 6y ago

Or the fact that once you define a struct, it cannot be redefined again and you need to reload the repl

dunefox 6y ago
You can put it in a module, then you can change and reload in the repl without restarting.

deleted 6y ago

[deleted]