Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

To me, Julia feels clunky as all hell. The other thing is that Julia doesn't help for deep learning, where something like 99.99% of the computation time is actually CUDA kernels.

I don't know; I actually really like the optional typing of Julia in theory, I don't know why I find the language so unpleasant.



sort by: page size:

why? i like Julia but it's not a great general purpose language IMO.

Julia is too quirky. Its one-indexing thing, general time-to-first-plot problems, and its multiple dispatch by default makes it hard to advocate to a general audience (or a community as big as "Deep Learning community").

The ecosystem also feels weird. For example for CLI parsing in Python I do argparse/click, in Rust I do clap. Both work well (Rust especially so). Julia seems to have ArgParse.jl which I found unpleasant. My guess is that this sentiment spills to other areas as well in the ecosystem. I am sure that Julia has very well designed libraries, but most of the rest are not so honed for practical use, and most importantly, probably lacks some features that Python-equivalent ones have.

Also personally (I am far from a DL researcher but I do research), I find Julia's design headachy as well quite some times. I like Python yield statements for iterators but the equivalent in Julia is always more complicated. Making Julia code performant requires another layer of intuition of how the JIT works. Julia has type annotations but "type annotations as lightweight formal methods" often cannot be fulfilled due to design (for example one cannot annotate the equivalent of `map :: (a -> b) -> [a] -> [b]`). Of course I stand corrected as only a casual Julia user.

I also want to say that I only stated my criticism towards the language. There are many many good things about Julia that I will just omit due to time.


One thing I found about Julia which turned me off was the library used for distributions used 64bit floats while that used for neural Nets used less precision, so it's hard to connect the dots there. Also there wasn't a lot of great tooling for RL

I've tried Julia and really liked it, but the user experience was pretty bad. The language really needs faster interactivity or a strong type checker. I found myself waiting after than compiler a lot more than in some AOT compiled language like Rust... I fear the language suffers from being overused by people who are familiar with Matlab and Python and draws too much inspiration from them, much like how Rust draws too much inspiration from C++.

What's wrong with Julia, a language purpose built for scientific computing?

I like julia a lot (use it everyday, it's my primary language right now), but this isn't really a reasonable recommendation, imho. Julia seems like it could be really great for ML, but I'm not sure if the current libraries are mature enough to wholeheartedly recommend.

I'd love to be proven wrong about that, though.


If you want to do number crunching, julia, otherwise avoid it. There are just too many oddities that, imo, will limit it's acceptance as a general purpose programming language.

Whatever happened to Julia? Wasn't it supposed to incorporate all these incredible abstractions at the language level and run quickly on GPUs and everything in-between? Is it just lack of adoption or is has it something else?

This is my favourite comment about julia for like last few years +1 on that.

Ecosystem is extremly poor outside very few niches and most of the Deep Learning stuff isn't even faster than python api (+C ofc.) so swaping is just usless if u dont have time to write your own GPU kernals for every new opertaion.


I keep on messing around with Julia, but I never stick with it. I have nothing in particular against the language, but I don't do a lot of scientific computing, so my motivations to use it are not that great.

I had never considered Julia as a general purpose language. I assumed it was targetted mainly at data science etc.

I feel the biggest misleading statements around Julia is that for true speed you can somehow ignore the lower abstractions, or that there is some kind of free lunch, but always what you gain in performance you'll spend in development time. Julia has some neat tricks, but they are not generally and universally applicable at least not like other languages. I dunno. These arguments against Julia are many, but I'm still appalled they have so many handy wavy misleading statements in just their introductory text, I don't think it be less than a decade before they recover.

I tried really hard to like Julia and it just isn't happening for me. Slow startup, bad documentation, fragmented ecosystem, poor error messages and stack traces, encouraging the use of unicode glyphs and operators... it's been a horrible beginner experience all while the Julia community keeps telling everyone (and each other) how amazing the language is. I'm not seeing it.

Since everybody is so hyped about Julia, I took on learning it and using it in one of my pet projects. The use case seemed to be perfect for Julia: financial portfolio optimization.

But honestly, it is a royal pain in the ass to use. Mostly because tooling is so crappy (no decent IDE).

For example, I've made these notes on my journey with Julia:

- Juno and VSCode julia is a pain

- Debugging is pain - no watch expressions (but debug> works)

- Works like with matlab (workspaces, designed for the single script use-cases)

- Long registry lookup times (2-5mins) when starting a new session

- No hints from IDE (Juno) on what methods are available for which types

- Ctrl-click navigation does not work to lookup definitations in libraries

- Debugger does not show the full list of elements - there are triple dots in the middle

- Filters and maps are not lazy

- Arrays start at one

- Precompilation times can take 1-2min

- Package management is done as a part of script execution

- Delay (0.5-1s) when processing commands (compilation?)

- Editors (Juno) do not check types at runtime when the information is readily available

- Include() includes (is this PHP all over again?) a file into the script!

- Reuses same REPL between different files

- DataFrames.jl: Transform does nonsense (use map instead)

- DataFrames.jl: No transpose

Obviously, there is a bunch of good things like freakin insane speed and vectorized method calls are awesome, but I struggle seeing myself becoming more producting than Python + Pandas.

It's really a shame that language is strongly and semi-statically typed yet no tooling is making a use of that.


JuliaComputing is not Julia the language

Julia is what happens if you let amateurs develop a compiler. The few times I’ve tried it produced gigabytes worth of stuff super slowly. The majority of packages are half backed, the only way to discover any type error is to let the program run, which coupled with multi method dispatch and hellishly slow compile times for trivial amounts of code makes the whole experience super unpleasant. Modern C++ plus some python feels more pleasant to work with (lightning fast compiles).

This. I was hoping Julia would be a quicker and more pleasant R. Instead it's turning into a super ambitious language that wants to be as fast as C++ but that makes it slightly less pleasant and useful than R. And if I need C++ speed I can just write C++...

Thank you for saying this. As an outsider I (I only tried Julia a few times) this is exactly the impression I get every time I read a post (and comments) about Julia on hn. Don't get me wrong, I believe there are lots of interesting things happening in Julia, but it is not a magic wand. Often it is characterised as python with the speed of c, based on some highly optimised benchmarks, while the reality is much more complex. I find this uncritical evangelism quite off-putting tbh.

The biggest problem with Julia is its marketing[1]:

- Julia lures newcomers by the way of attractive marketing (At one point in my career, I was such a huge fan of Julia that I dismissed many people and their concerns. It was like I was following a cult). This is pre v0.4 days.

- Too much focus on optimization. As a seasoned engineer, speed has been less and less of a concern where primary packages that need to be fast in Python are already quite fast. Majority of the tasks most engineers (not academicians) do is plumbing and connecting various pieces together. Julia just isn't good at this and perhaps it will get better.

- Julia markets itself boldly as a general purpose language but doesn't have a good systems library, no real competitive webframework and many things that are necessary for a true general purpose language - for e.g. GUI. At best, it is a scientific computing language such as MATLAB but free (that is a huge thing for Academicians but not for engineers working in Top 500 companies). At worse, it is lacking features and documentation that MATLAB has.

- Julia isn't humble in its approach towards marketing. It over-extends and over-reaches. This leads to people like myself lured into it and then completely burned by the experience. For e.g., it flaunts about being able to see the inline assembly instructions - in my entire 15 year career as a software engineer, I've never had the need to do this. It is almost a meaningless feature for vast majority of the users, but marketing wise it is pretty attractive.

- Julia recruits inexperienced software engineers and non-software "script junkies". It has lost its vision and original premise since 0.4v I feel like. Syntax has gotten worse. Bad decisions have been made. I think the founders of Julia are very very smart folks, it's just the community that is full of people who haven't built anything remotely large and of medium complexity. Are there exceptions? Yes, Julia has been adopted in a few large scale projects but I dispute whether that was a good decision.

Note: My experience is based on engineering mindset, not academics and research. Julia would probably be pretty good on a professor's macintosh and can gain wide adoption in those areas.

[1] https://julialang.org/benchmarks/

next

Legal | privacy