[HN Gopher] My Experiences with Julia
___________________________________________________________________
My Experiences with Julia
Author : Volker_W
Score : 31 points
Date : 2022-05-16 20:50 UTC (2 hours ago)
(HTM) web link (weissmann.pm)
(TXT) w3m dump (weissmann.pm)
| spekcular wrote:
| This article is representative of my experiences as well. I'm
| thankful to the author for writing it. My favorite parts:
|
| > This slowness affects other software written in Julia as well.
| For example, my editor formats on save. For most languages, the
| formatting time-delay is not noticable, but for Julia it
| sometimes took more than 10 seconds.
|
| > The idea of "You only need to start the interpreter once a day"
| failed for me.
|
| For me, this is the biggest obstacle to using Julia. It's not
| designed to support the traditional C/Python/whatever workflow of
| editing a text file and then interpreting/compiling it; it wants
| you to be in the REPL all the time. If you don't use the REPL,
| you have horrible problems with package loading times. So if
| you're someone who doesn't like developing in a REPL, you're out
| of luck.
|
| Some comments by Julia users on the post are available here:
| https://discourse.julialang.org/t/blog-post-about-my-experie...
| markkitti wrote:
| If you really wanted to, you could run PackageCompiler.jl as
| part of an edit-compile loop:
| https://julialang.github.io/PackageCompiler.jl/stable/exampl...
| zmmmmm wrote:
| It's interesting how hard this nut is to crack. I have hit all
| the same types of problems (R is obscene as a programming
| language, Python too slow and lacks multicore, C is too low level
| etc etc). I've ended up using Groovy (JVM) for a lot of my
| scientific work because it is the "least worst" language -
| dynamic when you want it to be, static when you want it to be,
| decent if not stellar set of scientific libraries and performant
| enough (mostly as fast as Java). I have hopes for Nim but it's
| still not quite there.
|
| But why _isn 't_ there something else? Can we really never have
| our cake and eat it too in this domain?
| gleenn wrote:
| If you're okay with JVM, I'm a big fan of Clojure. There are
| some great scientific libraries in the SciCloj community and
| you get the untyped but performant characteristics you're
| looking for.
| zwieback wrote:
| I'm assuming "this domain" refers to scientific computing. My
| theory is that the typical scientist crunching data is just
| proficient enough to write specialized code for themselves but
| doesn't have time to develop a scalable, "professional"
| solution. Very large organizations tend to have capable
| internal systems but they may not make it into public view or
| they are too specific to their niche.
|
| On the other hand you have premade, proprietary packages that
| can become quite popular (Matlab, JMP, etc.) for non-
| programmers, which dilutes the user base.
|
| That leaves us with things like "R" (horrible, like you say) or
| Julia (eternally promising) or Python (stitch together low-
| level Fortran and C code). The latter solution is winning, it
| seems.
| transfire wrote:
| Personally I feel JITs have gotten too much hype. While they have
| some advantages in optimization, it seems far outweighed by the
| downsides. I'd rather have an interpreter for development and a
| static compiler for production.
| markkitti wrote:
| You could use Julia in an interpreted mode (or a compiler with
| low optimization) and then statically compile it for
| production.
|
| The JIT involved is really a static compiler that has been
| adapted for use as a JIT compiler:
| https://llvm.org/docs/ORCv2.html
|
| https://juliadebug.github.io/JuliaInterpreter.jl/stable/
| https://julialang.github.io/PackageCompiler.jl/stable/apps.h...
| https://github.com/tshort/StaticCompiler.jl
| mrtweetyhack wrote:
| sterlind wrote:
| these are all very valid pain points with Julia, except I
| disagree with calling Julia "way more dynamically typed than
| Python."
|
| I think of Julia as _statically duck-typed_ , which sounds cursed
| but is incredibly useful IMO. like if you have `foo(x,y,z)=x+y
| _cow(z)`, foo() will work for any x and y with compatible `+`
| operators, if there 's a `cow()` that will accept whatever type
| `z` is. But it's still static - your code will throw a _compile
| error* if x and y can't be added, or if cow() won't take your z.
| And unlike Python, Julia can dispatch on types, so you can
| implement cow() for whatever you want. the type system is, in
| fact, absurdly powerful. the downside seems to be that it's
| formally undecidable sometimes, and that you fundamentally can't
| enforce output types for functions passed as arguments.
|
| the speed is a drag, but it feels like getting a train up to
| speed - it's slow getting ready to do absurdly heavy lifting.
| Volker_W wrote:
| > I disagree with calling Julia "way more dynamically typed
| than Python."
|
| What I meant was the following: Take an example Python
| codebase. Pick a random function. Put a `print(type(arg))` in
| there. Run it in many different use-cases. Chances are, it will
| only print a single type. If you do the same in Julia, chances
| are, it will print multiple very different types.
| zwieback wrote:
| > Rust is essentially C/C++, but without their ugliness
|
| I'd rephrase that, folks coming primarily from a coding
| background would probably find this off-putting since Rust's
| contribution is something quite different from what C/C++ does.
| It's fairly clear what author means, though.
| Volker_W wrote:
| What exactly do you mean? If you ask C/C++ programmers, what
| they don't like about C/C++ and fix that, you got Rust. C++
| wants to stay backwards compatible, which is holding the
| language back. Rust was a fresh start.
| iamed2 wrote:
| I still prefer to use Julia, but this is a good summary of the
| problems that affect me personally as an experienced user
| (although I do like dynamic typing for most of the work I do).
___________________________________________________________________
(page generated 2022-05-16 23:02 UTC)