9 ms·

I use and love Julia but I really wanted to see the general purpose language that is claimed. On one hand, you see amazing scientific libs like DifferentialEqua

by up6w6 5y ago

I use and love Julia but I really wanted to see the general purpose language that is claimed. On one hand, you see amazing scientific libs like DifferentialEquations.jl, on the other side, things like the PackageCompiler.jl mentioned just sucks at generating binaries for daily basis.

krastanov 5y ago
Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? If you generate a "python binary", you need to package python with your binary. Same for perl/ruby. It just seems weird that people expect julia to be able to do that. It is cute that PackageCompiler.jl exists and it is cute that more AOT compilation work is being currently done, but it seems crazy to expect Julia to be good at making binaries (and I would say that about python and perl too). And by extension, it seems weird to me to complain that Julia is not a general purpose language because it can not generate binaries. What stops me from making the same statement about python, which is definitely general purpose?
- reikonomusha 5y ago
  It’s not at all bad for Common Lisp, which is a superlatively interactive language.
  - krastanov 5y ago
    Could you elaborate or give examples? I guess all the complaints about binaries come from people used to something like Common Lisp, but while I have a general understanding of what a lisp is, this type of "provide a binary for your interpreted-ish language" is an incredibly foreign idea to me.
    - reikonomusha 5y ago
      Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive and incremental development”. (Of course, you always have the option to just re-compile everything from scratch if you so please.) Common Lisp was also designed to be compiled. Most implementations these days compile to machine code. Compilation is incremental, but ahead-of-time. That means you can start running your program without having yet compiled all the features or libraries you want. You can—while you’re in the REPL or even while your program is running—compile and load extra libraries later. Compilation is cached across sessions, so you won’t ever have to recompile something that doesn’t change. Despite Lisp being mega-interactive, incremental, and dynamic, just about every implementation of Lisp allows you to just write out a compiled binary. In the implementation called “Steel Bank Common Lisp” (SBCL), from the REPL, you just write: (sb-ext:save-lisp-and-die "mycoolprog" :executable t :entry-point 'main) which will produce a statically linked executable binary called “mycoolprog” using the function called “main” as the entry point. Unless you’ve specifically programmed it in, there will be no JIT lag, no runtime compilation, etc. It will all just be compiled machine code running at the speed of your processor. (It’s possible and even easy to invoke the compiler at run-time, even in your static binary, which people rarely do, and when they do, they know exactly what they’re doing and why.) All of this is a complete non-issue in Lisp, and hasn’t been for about 35 years (or more).
      - superdimwit 5y ago
        I am hopeful that Julia should be able to get this cross-session caching of compiled code. Would make restarting the REPL (to e.g. add a field to a struct) much less frustrating.
        reikonomusha 5y ago
        Yeah, restarting a Lisp REPL after you’ve compiled your code is transparently essentially instantaneous, because everything is cached and checked for changes, and 99% of the time most of your code and nearly all of your dependencies aren’t changing hour to hour.
        adgjlsfhk1 5y ago
        Caching is easy. The hard part here is correctly invalidating the cache. Specifically, if a user is using different libraries between sessions, figuring out which methods have been overridden (or inline code that was overridden) becomes complicated.
      - nightfly 5y ago
        The way that common lisp does this though is pretty much creating a core dump that you can execute, which isn't what most people are expecting from an executable. It's not a _bad_ way, it's just pretty unique to common lisp.
        reikonomusha 5y ago
        What exactly are people “expecting” from an executable? It is a piece of binary code on disk, full of machine code, that runs without a VM or external runtime libraries. ./mycoolprog just works. From a user perspective, there’s no difference. The binary itself isn’t structured like a typical one with C debugging symbols, etc. But it’s also not some “faux binary” like a bunch of .pyc bundled as data and unzipped when the program runs. It truly is machine code, just arranged differently than a bunch of C ABI functions. I claim most people running binaries don’t care about the memory layout of the binary. I certainly am never thinking about that every time I run `grep`. You don’t debug Lisp programs with C’s tooling. You use Lisp’s tooling. (Unless, of course, you use an implementation like Embeddable Common Lisp, which does compile your Lisp program as a C program, and does produce a non-image-based executable. That’s the beauty of Lisp being a standardized language with multiple conforming implementations.)
- adgjlsfhk1 5y ago
  The reason Julia should be able to do this is that it uses LLVM to generate machine code "just ahead of time". As such, (at least for type stable code), it should be possible to save the code we generate. The main place where static AOT matters for Julia isn't full applications, but libraries. Being able to generate static libraries would allow Julia to replace C++ and Fortran much more fully in places like python libraries. Furthermore, this capability is likely crucial in getting major further improvement in time to first plot. Currently `@time DifferentialEquations` takes about 11 seconds on my computer, but if more of the code could be statically compiled at precompile time, that could be reduced dramatically.
  - krastanov 5y ago
    This is the first time I see my confusion so clearly addressed! Thanks, this makes total sense now!
  - neolog 5y ago
    > The main place where static AOT matters for Julia isn't full applications, but libraries. That depends on the use case. With improvements in static compilation, julia could probably be a good application language. Game development would be an interesting market.
  - galenlynch 5y ago
    This is true for many functions, but afaik the llvm code is only generated for a function paired with the types of the arguments that it was called with. Since Julia functions are for the most part 'generic' and work with a wide range of argument types, you would have to restrict the compiled binary or library to a specific set of argument types. Some functions also have type instability and can't be made into pure llvm.
- up6w6 5y ago
  > And by extension, it seems weird to me to complain that Julia is not a general purpose language because it can not generate binaries. What stops me from making the same statement about python, which is definitely general purpose? I agree that generating binaries don't make a language general purpose, I just tried to give an exemple of an ad hoc non scientific thing that is considered "important" to the community (its an official project) that is stuck. The common sense would be just list the web frameworks but I dont think its fair simply because there is no interest on it (yet).
  - hpcjoe 5y ago
    A non-scientific thing I've been doing for the last few months at the day job, with Julia. 1) querying a time series database of systems metrics at scale for (large) fleets. This is being done via a JSON API. Directly in Julia. 2) Creating data frames from these queries, and performing fleet wide analytics. Quickly. Millions to hundreds of millions of rows in the data frames, typically 4-20 columns. Directly in Julia, no appeal to a 2nd language. 3) leveraging the power of the language to post process these data sets before analysis, to remove an "optimization" that reduced data quality. 4) operate quickly on gigabytes of queried data, threading and sharding my requests, as the server can't handle large requests, but it can handle parallel ones. Poor design, but I can work around it ... trivially ... with Julia 5) creating jupyter lab notebooks for simple consumption of these more complex data sets by wider audiences, complete with plots, and other things. No science done here ... well ... data science maybe ... and this is specifically in support of business analytics, process optimization, etc. Julia is an excellent language for this, 10 out of 10, would recommend.
    - neolog 5y ago
      What's a fleet in this case?
- Zababa 5y ago
  > Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? I think this is the case for at least the most popular JIT'd languages: Java, C#, JS, and PHP. Also for the most popular interpreted languages: Python, Ruby and also PHP. I don't know about Visual Basic and R though. I know that an exception is Dart, that combines a JIT and an AOT. I think EmacsLisp can now be also compiled, but I don't know if it works with all the code and is just free performance, or something more limited. Edit: as pointed at by pjmlp, Java and C# already combine an AOT and a JIT. What I meant by the comment on Dart is that it can either be run with a VM or compiled to produce binaries.
  - pjmlp 5y ago
    Java and C# also have combined JIT and AOT since they exist, .NET moreso. Other examples are Lisp and Scheme variants, Eiffel, OCaml, Haskell, Prolog.
    - oblio 5y ago
      The main SDKs and programming paradigms for Java and C# both don't mesh well with AOT, though. Reflection, heavy reflection based frameworks. Not that many places use Java/C# AOT compilation, except for games/iOS apps. Almost every place I've seen using Java/C# was using JIT.
      - pjmlp 5y ago
        Android uses a mix of JIT/AOT, just as most Java embedded development. As for not everything being supported, well that is no different from having C++ code with RTTI and exceptions disabled, or being forced into a specific linking model due to possible problems with a third party dependency.
        Shadonototro 5y ago
        and that is why they failed to provide proper toolkits for android smartwatch and were forced to call samsung for help
- orbots 5y ago
  Julia claims to "solve the two language problem". i.e. prototype in python, rewrite in c++. The two language problem is not solved with Julia if you can't effectively generate binaries.
  - krastanov 5y ago
    I have never really heard the name "two language problem" to refer to what you are describing. Whenever I have heard these words it has referred to "I want a high-productivity newbie-friendly introspective language like python, but I do not want to write C modules when I need fast inner loops". Julia seems to solve this already, without providing compact binaries. A sibling comment made a point about "compiling down to shared libraries" which seems similar to what you are describing, but that seems like it has little to do with "the two language problem".
    - orbots 5y ago
      Right. It used to be referenced on the front page of julialang.org Seems they don't really use that in the sale pitch anymore. Maybe that proves my point. It's easy to find references to julia claiming to solve the two-language problem though. I am someone who this two-language problem they speak of addresses. I love Julia. Which is why it's so painful that I have to rewrite all my elegant Julia prototype code in C++, so I can compile into a shared lib for the users. Every. Single. Time. Two languages. Now that it isn't the main front and centre claim, I feel a bit less bitter about using it as a prototyping language. Waiting another 5 years and maybe it really will solve the two-language problem.
      - tarlinian 5y ago
        It could only solve the two language problem if the "users" were writing their program in Julia themselves. Otherwise your ideal solution is still using two languages. And if they are writing their program in Julia, there's no reason to compile your code into a shared library; you'd just share a Julia package with them.
      - cbkeller 5y ago
- neolog 5y ago
  > Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? Python is famously bad at this. I hope Julia's proponents don't stop at "look we're only as bad as Python".
- vindarel 5y ago
  > Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? I might have a counter example: Common Lisp (a compiled language) can be run from sources as a script (like interpreted-ish languages) and we can build self-contained binaries. With SBCL they weight ±20MB minimum (proprietary implementations do tree shaking) and they start instantly.

by up6w6 5y ago

krastanov 5y ago

Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? If you generate a "python binary", you need to package python with your binary. Same for perl/ruby. It just seems weird that people expect julia to be able to do that. It is cute that PackageCompiler.jl exists and it is cute that more AOT compilation work is being currently done, but it seems crazy to expect Julia to be good at making binaries (and I would say that about python and perl too). And by extension, it seems weird to me to complain that Julia is not a general purpose language because it can not generate binaries. What stops me from making the same statement about python, which is definitely general purpose?

reikonomusha 5y ago
It’s not at all bad for Common Lisp, which is a superlatively interactive language.
- krastanov 5y ago
  Could you elaborate or give examples? I guess all the complaints about binaries come from people used to something like Common Lisp, but while I have a general understanding of what a lisp is, this type of "provide a binary for your interpreted-ish language" is an incredibly foreign idea to me.
  - reikonomusha 5y ago
    Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive and incremental development”. (Of course, you always have the option to just re-compile everything from scratch if you so please.) Common Lisp was also designed to be compiled. Most implementations these days compile to machine code. Compilation is incremental, but ahead-of-time. That means you can start running your program without having yet compiled all the features or libraries you want. You can—while you’re in the REPL or even while your program is running—compile and load extra libraries later. Compilation is cached across sessions, so you won’t ever have to recompile something that doesn’t change. Despite Lisp being mega-interactive, incremental, and dynamic, just about every implementation of Lisp allows you to just write out a compiled binary. In the implementation called “Steel Bank Common Lisp” (SBCL), from the REPL, you just write: (sb-ext:save-lisp-and-die "mycoolprog" :executable t :entry-point 'main) which will produce a statically linked executable binary called “mycoolprog” using the function called “main” as the entry point. Unless you’ve specifically programmed it in, there will be no JIT lag, no runtime compilation, etc. It will all just be compiled machine code running at the speed of your processor. (It’s possible and even easy to invoke the compiler at run-time, even in your static binary, which people rarely do, and when they do, they know exactly what they’re doing and why.) All of this is a complete non-issue in Lisp, and hasn’t been for about 35 years (or more).
    - superdimwit 5y ago
      I am hopeful that Julia should be able to get this cross-session caching of compiled code. Would make restarting the REPL (to e.g. add a field to a struct) much less frustrating.
      - reikonomusha 5y ago
        Yeah, restarting a Lisp REPL after you’ve compiled your code is transparently essentially instantaneous, because everything is cached and checked for changes, and 99% of the time most of your code and nearly all of your dependencies aren’t changing hour to hour.
      - adgjlsfhk1 5y ago
        Caching is easy. The hard part here is correctly invalidating the cache. Specifically, if a user is using different libraries between sessions, figuring out which methods have been overridden (or inline code that was overridden) becomes complicated.
    - nightfly 5y ago
      The way that common lisp does this though is pretty much creating a core dump that you can execute, which isn't what most people are expecting from an executable. It's not a _bad_ way, it's just pretty unique to common lisp.
      - reikonomusha 5y ago
        What exactly are people “expecting” from an executable? It is a piece of binary code on disk, full of machine code, that runs without a VM or external runtime libraries. ./mycoolprog just works. From a user perspective, there’s no difference. The binary itself isn’t structured like a typical one with C debugging symbols, etc. But it’s also not some “faux binary” like a bunch of .pyc bundled as data and unzipped when the program runs. It truly is machine code, just arranged differently than a bunch of C ABI functions. I claim most people running binaries don’t care about the memory layout of the binary. I certainly am never thinking about that every time I run `grep`. You don’t debug Lisp programs with C’s tooling. You use Lisp’s tooling. (Unless, of course, you use an implementation like Embeddable Common Lisp, which does compile your Lisp program as a C program, and does produce a non-image-based executable. That’s the beauty of Lisp being a standardized language with multiple conforming implementations.)
adgjlsfhk1 5y ago
The reason Julia should be able to do this is that it uses LLVM to generate machine code "just ahead of time". As such, (at least for type stable code), it should be possible to save the code we generate. The main place where static AOT matters for Julia isn't full applications, but libraries. Being able to generate static libraries would allow Julia to replace C++ and Fortran much more fully in places like python libraries. Furthermore, this capability is likely crucial in getting major further improvement in time to first plot. Currently `@time DifferentialEquations` takes about 11 seconds on my computer, but if more of the code could be statically compiled at precompile time, that could be reduced dramatically.
- krastanov 5y ago
  This is the first time I see my confusion so clearly addressed! Thanks, this makes total sense now!
- neolog 5y ago
  > The main place where static AOT matters for Julia isn't full applications, but libraries. That depends on the use case. With improvements in static compilation, julia could probably be a good application language. Game development would be an interesting market.
- galenlynch 5y ago
  This is true for many functions, but afaik the llvm code is only generated for a function paired with the types of the arguments that it was called with. Since Julia functions are for the most part 'generic' and work with a wide range of argument types, you would have to restrict the compiled binary or library to a specific set of argument types. Some functions also have type instability and can't be made into pure llvm.
up6w6 5y ago
> And by extension, it seems weird to me to complain that Julia is not a general purpose language because it can not generate binaries. What stops me from making the same statement about python, which is definitely general purpose? I agree that generating binaries don't make a language general purpose, I just tried to give an exemple of an ad hoc non scientific thing that is considered "important" to the community (its an official project) that is stuck. The common sense would be just list the web frameworks but I dont think its fair simply because there is no interest on it (yet).
- hpcjoe 5y ago
  A non-scientific thing I've been doing for the last few months at the day job, with Julia. 1) querying a time series database of systems metrics at scale for (large) fleets. This is being done via a JSON API. Directly in Julia. 2) Creating data frames from these queries, and performing fleet wide analytics. Quickly. Millions to hundreds of millions of rows in the data frames, typically 4-20 columns. Directly in Julia, no appeal to a 2nd language. 3) leveraging the power of the language to post process these data sets before analysis, to remove an "optimization" that reduced data quality. 4) operate quickly on gigabytes of queried data, threading and sharding my requests, as the server can't handle large requests, but it can handle parallel ones. Poor design, but I can work around it ... trivially ... with Julia 5) creating jupyter lab notebooks for simple consumption of these more complex data sets by wider audiences, complete with plots, and other things. No science done here ... well ... data science maybe ... and this is specifically in support of business analytics, process optimization, etc. Julia is an excellent language for this, 10 out of 10, would recommend.
  - neolog 5y ago
    What's a fleet in this case?
Zababa 5y ago
> Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? I think this is the case for at least the most popular JIT'd languages: Java, C#, JS, and PHP. Also for the most popular interpreted languages: Python, Ruby and also PHP. I don't know about Visual Basic and R though. I know that an exception is Dart, that combines a JIT and an AOT. I think EmacsLisp can now be also compiled, but I don't know if it works with all the code and is just free performance, or something more limited. Edit: as pointed at by pjmlp, Java and C# already combine an AOT and a JIT. What I meant by the comment on Dart is that it can either be run with a VM or compiled to produce binaries.
- pjmlp 5y ago
  Java and C# also have combined JIT and AOT since they exist, .NET moreso. Other examples are Lisp and Scheme variants, Eiffel, OCaml, Haskell, Prolog.
  - oblio 5y ago
    The main SDKs and programming paradigms for Java and C# both don't mesh well with AOT, though. Reflection, heavy reflection based frameworks. Not that many places use Java/C# AOT compilation, except for games/iOS apps. Almost every place I've seen using Java/C# was using JIT.
    - pjmlp 5y ago
      Android uses a mix of JIT/AOT, just as most Java embedded development. As for not everything being supported, well that is no different from having C++ code with RTTI and exceptions disabled, or being forced into a specific linking model due to possible problems with a third party dependency.
      - Shadonototro 5y ago
        and that is why they failed to provide proper toolkits for android smartwatch and were forced to call samsung for help
orbots 5y ago
Julia claims to "solve the two language problem". i.e. prototype in python, rewrite in c++. The two language problem is not solved with Julia if you can't effectively generate binaries.
- krastanov 5y ago
  I have never really heard the name "two language problem" to refer to what you are describing. Whenever I have heard these words it has referred to "I want a high-productivity newbie-friendly introspective language like python, but I do not want to write C modules when I need fast inner loops". Julia seems to solve this already, without providing compact binaries. A sibling comment made a point about "compiling down to shared libraries" which seems similar to what you are describing, but that seems like it has little to do with "the two language problem".
  - orbots 5y ago
    Right. It used to be referenced on the front page of julialang.org Seems they don't really use that in the sale pitch anymore. Maybe that proves my point. It's easy to find references to julia claiming to solve the two-language problem though. I am someone who this two-language problem they speak of addresses. I love Julia. Which is why it's so painful that I have to rewrite all my elegant Julia prototype code in C++, so I can compile into a shared lib for the users. Every. Single. Time. Two languages. Now that it isn't the main front and centre claim, I feel a bit less bitter about using it as a prototyping language. Waiting another 5 years and maybe it really will solve the two-language problem.
    - tarlinian 5y ago
      It could only solve the two language problem if the "users" were writing their program in Julia themselves. Otherwise your ideal solution is still using two languages. And if they are writing their program in Julia, there's no reason to compile your code into a shared library; you'd just share a Julia package with them.
    - cbkeller 5y ago
neolog 5y ago
> Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? Python is famously bad at this. I hope Julia's proponents don't stop at "look we're only as bad as Python".
vindarel 5y ago
> Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? I might have a counter example: Common Lisp (a compiled language) can be run from sources as a script (like interpreted-ish languages) and we can build self-contained binaries. With SBCL they weight ±20MB minimum (proprietary implementations do tree shaking) and they start instantly.