37 ms·

Julia: A Post-Mortem

107 points by LittlePeter 6y ago

Tarq0n 6y ago
Archive link as the article seems to be down: https://web.archive.org/web/20210308114008/https://chrisvoncsefalvay.com/2021/03/07/julia-a-post-mortem/ https://web.archive.org/web/20210308114008/https://chrisvonc...
make3 6y ago
cached because the blog was hugged to death: http://webcache.googleusercontent.com/search?q=cache:Awfh5p84MFYJ:https://chrisvoncsefalvay.com/2021/03/07/julia-a-post-mortem/&client=ms-unknown&hl=en&gl=ca&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:Awfh5p8...
mech422 6y ago
Interesting.. I thought Julia was on the rise ?
- dagw 6y ago
  It probably still is, but by all accounts it is rising a lot slower than many people had hoped for.
  - dunefox 6y ago
    Hopes are free. If you want it to rise quicker you have to use it and contribute. "Why would I use it if few people do?" is quite paradoxical.
    - michaericalribo 6y ago
      Definitely not paradoxical. Network effects of out-of-the-box tooling/features—I mean a robust, extensive set of libraries to accomplish basic and moderately complex statistical / ML tasks—is the table stakes here, and depends strongly on whether more than a “few people do” already.
- bsdubernerd 6y ago
  It is. But if your aim is to displace (never mind replace!) an old, established niche, it's a very steep uphill. Like the OP, I still use a ton of python. And I consider python to be a newcomer in the sci community, still gaining momentum with perhaps a bigger uptick in the recent years.
  - phkahler 6y ago
    >> But if your aim is to displace (never mind replace!) an old, established niche, it's a very steep uphill. If your goal is to beat someone else then you're playing the wrong game.
    - coldtea 6y ago
      This doesn't say much. First, as an analogy, since in most games, the goal is precisly to beat someone else, and there's nothing wrong with that (it's the very meaning of sports competition). Second, because for a programming language community and adoption and ecosystems matters, and you don't get all those without beating "someone else" or at least comming close to doing it. Either you magically double the number of devs/people doing data science, or you atract data scientists from Python and R (either attract existing users of Python, or get more new users into you rather than in Python).
  - snicker7 6y ago
    The goal is to create a great programming language to solve real problems.
    - michaericalribo 6y ago
      I already solve real problems in Python—why bother learning yet another language, and one our data engineers/backend folks don’t know? That larger context of implementation / development / deployment is a huge deciding factor for real-world problem solving, not how “great” a language is from a design perspective.
      - 6y ago
- coldtea 6y ago
  Yes. For 10 years and probably 10 more before it gets anywhere near significant adoption...
unwind 6y ago
Meta: in Chrome on Android, I just get a very tall dark blue box. Fail.
superbcarrot 6y ago
Is the post only based on TIOBE? The same index that currently ranks JavaScript below Visual Basic and SQL below Assembly? That ranking is off by so much that anyone who takes it seriously loses at lot of credibility from the start. I'm not entirely on board with the Julia hype train but they certainly got some things right and both the ecosystem and the community are healthy and growing. Julia doesn't need to replace a bunch of other languages immediately to be successful. Implying that the language is dead by using the word post-mortem is just demonstrably false.
- st3fan 6y ago
  Maybe you should read to the end instead.
  - superbcarrot 6y ago
    I did. I still don't get how the author's decision to not use the language is enough to declare it dead.
    - parsimo2010 6y ago
      That’s not the only factor. Their publisher also decided there wasn’t a market for a book and declined to publish. The author also didn’t say Julia was a dead language, it just failed to realize the dream of becoming the language, and is instead just a language in a sea of many.
      - dunefox 6y ago
        "Post-mortem" doesn't imply that it's dead? And also, of course there isn't a mass market for a book on a programming language that's not python and due to most learning material being available online. This is a stupid metric.
        mbeex 6y ago
        I got the impression, that he refers more to the fate of his own hopes.
ramboldio 6y ago
I agree that Julia can't stack up to Python in terms of a data science / statistics domain. But in everything people use MATLAB for, Julia actually has the upside in many of the qualities discussed in the article: Community, Package Ecosystem, annoying licensing bureaucracy etc etc.
- socialdemocrat 6y ago
  The best bet for Julia might be to be a Trojan horse in the Python ecosystem. By making the best of breed packages in specific domains it can become the first pick in the Python community rather than C/C++ based packages. If Julia is the engine that drives all the critical parts in Python rather than C/C++, then it has a way to get the foot in the door. People will stop and ask: Why am I using Python if I could just use Julia directly?
  - andi999 6y ago
    Because you want a snappy repl?
    - FridgeSeal 6y ago
      Every major release has improved performance in the language and its use, and it doesn’t really take that much before most of the stuff you do is already compiled and you get a repl experience far superior to pythons.
      - michaericalribo 6y ago
        That may be true for elaborate analyses, but doesn’t really address exploratory analysis that changes dramatically from command to command. The use case for REPL-driven data science is experimentation, not performance
  - phillc73 6y ago
    The same with R. There's already the excellent JuliaCall[1] package, for embedding Julia code in R. Listed in the README are some R packages, using Julia code through JuliaCall. [1] https://github.com/Non-Contradiction/JuliaCall https://github.com/Non-Contradiction/JuliaCall
deleted 6y ago
[deleted]
nudpiedo 6y ago
my takeaway: basically python ate the toast and there is fierce competition for OS devs. Ecosystem gravity becomes stronger the more mass it gets. I also think that feature creep is a proven strategy for mainstream language (see Java, C++, Python) but a killing feature for rising languages.
socialdemocrat 6y ago
Lots of truths there but also colored by someone who evidently has not been a fan of technologies before and seen how it works. I am not as pessimistic as a Julia fan. Why? Because I have been where this guy is now ever since I was an Amiga user. I was like that with Python, Ruby, Go and a whole other languages. And what I learned from that is that it takes time. Neither Python, Ruby or Go had success over night. Yet almost all these languages I homed in on in the past have seen what I would call success later. I was certain Perl would go downhill when it was at its top. I kept argue with Perl fans that Python was a cleaner language that would see more success. Ditto with Ruby. That turned out to be quite accurate. I said while D looked like a nice replacement for C++, it simply wasn't big enough improvement to go anywhere. That also seems to have been an accurate prediction. Go on the other hand had a very obvious appeal from the get go. It did something important different and sufficiently better than before while keeping things simple. I am confident about Julia, because I have not in 20 years since a language with so much potential and so many advantages. You just got to give it time. This reminds me of myself following solar and wind energy in the early 90s and deciding it was not going anywhere. Ironically I see people like Michael Shellenberger having become a cynic about wind and solar now that it has actually achieved some measure of success. Why? Because it didn't happen fast enough. He poured all his enthusiasm and hope into this industry long before there was reasons to do so. People have to be aware of the same about Julia. It is not taking over the world any time soon. There is a long road ahead. And I would not define success as getting to Python scale. But if Julia can get to a similar position as Go is today, then I would call that success.
- zhdc1 6y ago
  Julia's already making (fairly substantial) in roads. It's just not as visible as Python, since the niche it's occupying is much smaller and out of the way.
- hatmatrix 6y ago
  When Julia finally comes of age, there will be a new, emerging language claiming it will eat Julia for lunch.
  - 6y ago
dash2 6y ago
Unconvincing. 1. There's plenty of niches. I don't think anyone is pushing Julia as the new general purpose programming language. 2. Ecosystems and network effects are real, but if you conquer a niche, you can still win. R's doing fine. 3. Specialists seem to like Julia and are writing good stuff in it. I don't see why that attraction shouldn't bring more users in. Indeed, it's still rising in PYPL, as linked by another comment.
xiphias2 6y ago
Julia is a language that looks very simple, but the more you use it, the more you realize how complex and unpredictable it is. I think that Union types do more harm than good (why would you want a function to return Union of int and float instead of compile error? It totally slows down the program) Array{Number} is totally different from Array{:<Number}, and shouldn’t be allowed, as it is inefficient. 1-based indexing was a mistake, and I have seen it emitting inefficient code in the PTX compiler. But the worst and hardest part is the rule/heuristic for multiple dispatch: it’s so complex, that it isn’t even documented. It should probably throw more errors and be predictable instead of trying to be so smart.
- FridgeSeal 6y ago
  > 1-based indexing was a mistake The most software I write, the more I am convinced that 1-based indexing is what most languages should be using, either the exception being the very specific use-case of needing to track offsets by hand for some reason. 1-based indexing is so much easier to reason about, but zero based indexing is seen as “the one true way” due its ubiquity, and not because it’s actually better. > and I have seen it emitting inefficient code in the PTX compiler. Have you raised this with the devs? This seems like something worth raising as an issue.
  - tgv 6y ago
    Both approaches have their advantages, IMO. Inclusive ranges are usually easier to understand, but e.g. when picking a (uniformly distributed) random element from an array, nothing beats a[floor(rnd() * len(a)].
    - dunefox 6y ago
      > nothing beats a[floor(rnd() * len(a)] What's wrong with rand(a)?
    - socialdemocrat 6y ago
      How is that very readable? In Julia, this will pick a random value from an array: rand([3, 4, 5, 1]) While this picks a value from a range: rand(1:10) Much more straightforward to read IMHO. Where I prefer 0-based index is when dealing with coordinate systems and memory locations.
da39a3ee 6y ago
I think this post is a bit immature. These things take time. Julia should just keep on striving for excellence and I'm sure it doesn't need me saying so. I've spent the last decade writing python professionally for web backend software engineering: it is a fantastic language for getting out of your way and allowing you to think and build what you want. And things like pattern matching show that it's still taking significant steps forward. But, languages should be statically typed: modern compilers offer too much benefit to development workflows to turn this down. So you can try to patch typing on to a dynamic language but my impression is that mypy is a hack compared to what was delivered to javascript in the form of typescript. I suspect that people will eventually swing back towards statically typed languages for the development tooling. Especially as the future needs more programmers and more help for programmers to build things correctly vs the early 21st century era of hackers writing untyped python in vim. Above comments are mainly aimed at web backend. I'm aware of Python's dominance in data science and machine learning but perhaps ultimately the same will hold true there -- that humanity will ultimately go for solutions that keep developers on the rails more. (Jupyter notebooks are a disaster when it comes to building correct solutions: no encouragement to use version control; out of control invisible global state etc.)
- leephillips 6y ago
  Julia has its own notebook that solves the issues you mention with Jupyter: https://lwn.net/Articles/835930/ https://lwn.net/Articles/835930/. With Pluto there is no hidden global state, everything is deterministic, and the notebooks are Julia files, so version control is as natural as when writing straight jl programs.
neilwilson 6y ago
Python is terrible for Agent Based Modelling because of the Python Tax when dealing with so many entities. The question is would Julia be any better?
- FranzFerdiNaN 6y ago
  There is https://juliadynamics.github.io/Agents.jl/stable/ https://juliadynamics.github.io/Agents.jl/stable/
- ChrisRackauckas 6y ago
  Agents.jl benchmarks really well. See https://arxiv.org/abs/2101.10072 https://arxiv.org/abs/2101.10072 . Or if you use the libraries you will immediately feel the difference.
FridgeSeal 6y ago
This feels like a very strongly worded title for a fairly lacklustre article. There’s Python the language and “Python the dsl for tensor frameworks”, the former has arguably lost some ground/mindshare to newer, less “hobbled” languages, and the latter exists not by virtue of its own strengths but as the convenient vehicle for frameworks written by 2 enormous corporations. Julia hasn’t overtaken Pythons ecosystem yet, but how far its come in relatively little time is the real testament to its community-that which the author decries as lacking. Using weird outdated rankings and citing “that one package that kind of works in very specific circumstances” (Numba) as proof that all Pythons issues are solved and Julia is over is a weak argument at best, and deceptive at worst. What Julia could really, really benefit from though is some vocal commercial backing-had google chosen to rewrite Tensorflow in Julia I think 2 things would have happened: 1. the project would have actually succeeded and been finished (in a “this is the tensorflow engine now” sense) 2. It would have done absolute wonders for the Julia ecosystem and mindshare and we wouldn’t be having this taudry discussion. That didn’t happen (unless some tensorflow product managers want a promotion by re-launching a tensorflow rewrite? ;) ) so they need another source of major support IMO.
- apples2apples 6y ago
  I'm sorry but deep learning is only a very small part of why Python is preferred by data scientists. The fact that Python was the the preferred language is why the enormous corporations wrote bindings to them. Both of these frameworks exist in the Julia ecosystem.
  - FridgeSeal 6y ago
    As someone who does data science, I roll my eyes every time I have to touch Python. It’s ubiquitous, but it actually sucks once you get used to better languages. It is somewhat circular: it was preferred because your earlier alternatives were Java or C(++) both of which had their shortcomings. SKLearn is still one of the most feature-complete and powerful libraries and it was Python only and thus drew a crowd. A lot of people who write data science code, I would be confident to bet that if you taught them Julia first, they’d prefer that.
vsskanth 6y ago
Julia has an advantage python does not - high quality packages written in pure Julia that compose well with each other. They aren't just C wrappers. Some of their AD and differential equation libs are state of the art. Being the best at a certain niche will attract users who will eventually stay and contribute. I use python a lot but it can't beat Julia for simulating an ODE. So I use it too
- agumonkey 6y ago
  > They aren't just C wrappers. I'd be warried about that. To some people (battle tested libs) C wrappers are better than a fully coherent single-language ecosystem.
  - dunefox 6y ago
    You can just use the wrappers. Also, many libraries are using wrappers where available. Julia allows you to not exclusively rely on C libraries because it is efficient enough to implement them in itself.
  - vcxy 6y ago
    One problem with this is that, as mentioned, some julia packages actually are state of the art. There isn't a C equivalent for everything DifferentialEquations.jl can do. Ditto for Zygote.jl and Enzyme.jl.
- dagw 6y ago
  They aren't just C wrappers The big advantage with the C wrappers approach is that I know I'll get the same features and results as everybody else using that C library.
  - dunefox 6y ago
    Nothing is stopping you from using the C library.
enriquto 6y ago
I hope Julia succeeds and replaces the clunky R and numpy+python "ecosystems". Every few months I try to decide to do all my computing on Julia and quit fooling around with lesser environments. And every time I get stuck at the same point: the slow startup time. I want to draw 100 plots per second, by calling the same Julia script on a bash loop 100 times; but this is utterly impossible. Of course, the Julia community has a standard answer to this concern: this is not how you are supposed to use the language. But I don't listen to them, for the best tools are those that perform well doing tasks they were not designed to do. I feel the same dismay when I get stuck at slow loops in Python, and the Python people tell me that I'm not supposed to use loops. Well, this is the main reason that I want to move away from Python and into Julia. I'm not interested in the implementation details of the language interpreter. The language is already very good, and the libraries are excellent. My main point of friction against using Julia is the slow startup time that forbids its use in a wide variety of contexts. I feel like the best usage of resources for the Julia community would be to spend all available money in hiring a Mike Pall-esque figure to advise them on JIT. Even if it was a part-time or a one-shot hire.
- dunefox 6y ago
  Start up time for the interpreter is 0.13s for me: ~ time julia -E "1+1" What takes time is precompilation of packages and functions - with Julia 1.6 the precompilation is much faster now than before. Your bash script that calls Julia 100 times is indeed not something that Julia was made for. It excels in many other areas and that's quite fine. I'm okay with plotting in a bash script in Python if it means that I can use Julia for everything else.
  - michaericalribo 6y ago
    Your last sentence seems to ignore the reality that plotting is only one step in a larger pipeline. It sounds miserable to need to write analytics code twice, once in Julia “for everything else” and again in Python just for the plotting. I’ll just write the whole thing in Python and save myself the headache.
    - 6y ago
deleted 6y ago
[deleted]
snicker7 6y ago
tl;dr -- Julia is not that popular (yet!). A pretty good indictment of the language is that a "port-mortem" didn't mention any of Julia's technical limitations, but rather its popularity. With regards to popularity, Julia has had a lot of adaptation over the last year. And once it can produce small-ish static binaries (.so/.dll), I think there would be a surge in popularity.
- dagw 6y ago
  And once it can produce small-ish static binaries That would be a real killer feature. If Julia could easily create small stand alone .exe files that I could just give to colleagues to run, that would be a seriously tempting feature.
  - snicker7 6y ago
    This is a promised feature (one that Viral Shah made recently). Julia already provides user-facing compiler hooks (see JET.jl for static Julia analysis). So it theoretically should be possible for someone to create an AOT compiler today. Not sure what the current limitations are.
  - oscardssmith 6y ago
    Check out StaticCompiler.jl. it's very beta, but it works (at least for some small problems)
bachmeier 6y ago
This post overlooks that language adoption is something that happens over decades. It's much too early to conclude anything about Julia adoption. I also think there's way too much focus in the post about Julia taking share away from Python or R. The real market is Matlab programmers, for one and only one reason - Matlab is extremely expensive. A number of years ago I was talking with a vice president of one of the Federal Reserve banks that told me one of their priorities was to move away from Matlab due to the high and growing licensing costs. The New York Fed has in fact moved much of its code from Matlab to Julia: http://frbny-dsge.github.io/DSGE.jl/latest/ http://frbny-dsge.github.io/DSGE.jl/latest/ Julia has momentum in parts of economics that have traditionally been heavy users of Matlab: https://quantecon.org/ https://quantecon.org/
- higerordermap 6y ago
  This is interesting. Glad to see matlab being phased out.
- xtracto 6y ago
  > This post overlooks that language adoption is something that happens over decades. It's much too early to conclude anything about Julia adoption. Spot on, I was doing R back in 2005, when it was slowly become more famous. R fist official release was in 1995. Which means that it took R 26 years to get to the point where it is now. If Julia was launched on 2012, its tipping point may come 20 years later, around 2030.
  - bachmeier 6y ago
    R is one of the languages I was thinking about, but even 1995 understates how long it took. R is an open source implementation of the S language that dates back to 1976.
ruph123 6y ago
While I don't think this piece was well argued I must agreee with the sentiment that Julia is somewhat of a disappointment, at least for me personally. Last year I started learning Rust and wanted to use it instead of C++ in the future. I since have programmed quite a lot in it, contributed to open source software and absolutely have fallen in love with it. So this year I wanted to replace my default scripting language (Python) with Julia and potentially use it for my simulations or ML in the future. But every time I take a stab at Julia - last time around the release of version 1 - it never really stops feeling foreign. Everything is slightly unintuitive and weird. Also, learning Julia made me realize how amazing Rust's learning resources are. Besides the official book and the API docs (with an amazing template), there are a lot of great third party and actively maintained resources likes cheats.rs. I never felt Rust was unituitive or hard to learn. Even if some concepts are unique, the resources do a great job of introducing them to you. While Julia's learning website lists an exercism course, its manual and a bunch of video lectures. I think selling Julia as a Python competitor raises wrong expectations. Julia may look easy or Python-like but is far more difficult to use IMHO. They may be similar in terms of applications but at least in how they feel to use, they are very different. I still haven't given up but whereas I speak very highly and enthusiastically of Rust and recommend it everywhere (yes I am one of those people), I cannot see myself doing the same for Julia in the future. Ps.: I wish there was a book club-like way of learning programming languages and discussing progress with friends. That would make learning even more fun.
- dgellow 6y ago
  > Ps.: I wish there was a book club-like way of learning programming languages and discussing progress with friends. That would make learning even more fun. That might be an awesome idea for a Clubhouse club! A weekly programming language meetup with a theme decided in advance.
  - ruph123 6y ago
    Or an Element chat? I would not sign up with that service because of their sketchy privacy setup.
- mountainriver 6y ago
qaq 6y ago
Here's the funny thing there are more full time developers working on Julia than Python and the rate of progress in Julia ecosystem is truly amazing.
tsdlts 6y ago
Julia v1 was released in 2018. It's currently about as popular as elixir. Is the author really complaining that it hasn't over taken as the lingua franca in two years? Python is over 20 years old and it's only hit it's stride in popularity over the last 5.
- socialdemocrat 6y ago
  Exactly!! Much too early to draw conclusions. Look at Go, it having a decent measure of success today. A couple of more years in the market makes a big difference.
- js8 6y ago
  Actually, Python came into TIOBE Top 10 in around 2004. So it took more than a decade for it to became decently popular; your point still stands.
A-Train 6y ago
Julia will never become a mainstream language because it is not general enough. The syntax is inspired by matlab which is good for linear algebra. Also it is not object oriented which is probably the most popular paradigm. Python will not be overtaken soon by such an exotic language.
- stellalo 6y ago
  Object orientation is no “must have” for a general purpose language to become popular. OO is a paradigm like many others, and it is one that in my opinion is much more abused than, say, functional features. In a few years we will look back at all those class hierarchies and wonder: man, what the hell were we thinking.
- socialdemocrat 6y ago
  Of course Julia is general enough. Whether you end your for-loop with `end` or `}` doesn't make any difference in what you can use the language for. That Matlab is not great at general programming has absolutely nothing to do with the syntax and everything to do with semantics. In Matlab pretty much everything is a matrix. That is not the case in Julia. Julia work with scalar values just as well as Python. Actually it does it much better. Object-oriented programming has been on the way out from all major new languages for years now. Go, Rust, Kotlin, Clojure, Julia and many others have downplayed object-oriented programming significantly.
- krumbie 6y ago
  I'd actually say the opposite. In my experience, n-dimensional arrays for example are very useful for problems that don't have anything to do with linear algebra. And in Julia it's just so convenient that all the high level functions manipulating such arrays are fast, and therefore much simpler to write.
- Recurecur 6y ago
  'Also it is not object oriented which is probably the most popular paradigm.' Popularity isn't a suitable metric for 'good'. Look at McDonald's food. 'Python will not be overtaken soon by such an exotic language.' Python and Julia aren't competitors. Python is suitable for scripts and gluing high performance code together. Julia is a general purpose language which is suitable for writing high performance code. Object orientation was likely a mistake. The industry is slowly moving away from it. There is no abstraction you can express with object orientation that you can't express with multiple dispatch. Structs are very much like the data part of objects.
cmrdporcupine 6y ago
Honestly, I learned Python in 1995, and used it where I could for CGI script programming and scripts into the early 2000s, and tried to get jobs programming it throughout that time with no success at all. Throughout that time, Perl was still in use all over but declining, PHP was growing like an unpleasant weed, and it seemed Ruby was ascendant for the "cool" stuff... but Python wasn't cool, most hiring managers had never heard of it, and while Google used it, that was pretty much it for large company support. Then while I wasn't looking (I lost interest in dynamically typed languages and focused on modern static typed languages) it became insanely popular -- and I actually got pushed out of a lead role at a job in part because folks wanted to rewrite into Python something we did in Java/Scala. Python popularity skyrocketed over the next 10 years. Numpy had something to do with it but also many other factors, not a lot of them initiated by the Python community itself, or by Guido. All this to say, language popularity is fickle and not terribly predictable. Prognosticating like this is silly. Julia is nice. Kinda wish I had a job where I got to play with it. Which is about how I was with Python, 20 years ago.
nromiun 6y ago
> We were all going to heaven, and that right soon. The language wars would end, we would finally get a lingua franca for anywhere code performance mattered, Julia would take over the TIOBE Index, and we’d all be home for tea and medals. This type of thinking is so alien to me. A mainstream language like python has its appeals (like a large quantity of docs and many libraries), but TIOBE ranking? Language wars? Who cares about that? At the end of the day a language is a tool, nothing else (Matlab is a good example).
xaduha 6y ago
I have an irrational aversion to LLVM languages and I don't know why, because I have close to zero personal experience with them. But when I find out that some new language uses LLVM my interest in it drops.
deleted 6y ago
[deleted]
stellalo 6y ago
> What’s the unique selling point? It’s multiple dispatch, how did the almost-author-of-a-book-on-the-language not get that?
- dunefox 6y ago
  Maybe that's where the almost comes from.
systems 6y ago
I found Julia scoping rules to be weird, and a bit off putting While this clearly doesn't seem to impact its adoption, or its community from creating great things For the new comer to the language, the scoping rules just gives a bad feeling for the language, I wish they fix it in future versions check my github issue if you want to know more what I mean by off putting scoping rules https://github.com/JuliaLang/julia/issues/37187 https://github.com/JuliaLang/julia/issues/37187
stellalo 6y ago
This article starts off with the following premise: “one of Julia’s original promises was to take over other languages in terms of popularity” (paraphrased). Honestly, I cannot find such promise in the original announcement: https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/ Ex falso quodlibet
Xcelerate 6y ago
I think claims of Julia's death are premature. I used it all throughout grad school shortly after it was released, and there are things the language does so much better than any other language I know of that I find it hard to imagine it just disappearing into the ether. The only way I can think of it really dying off is if more popular languages absorb the best features of Julia, making it redundant. It's hard to make inroads into Python's domain because of the strong networks effects, but I think if one or two major companies onboard the language, then we might see a snowball effect. Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me.
- coldtea 6y ago
  >I used it all throughout grad school shortly after it was released, and there are things the language does so much better than any other language I know of that I find it hard to imagine it just disappearing into the ether That is also true of Common Lisp and Smalltalk, though, and both are as good as "into the ether".
  - ragnese 6y ago
    Yeah. There's "dead" and there's "DEAD". Many languages are "dead": COBOL, probably Perl 5, Groovy, Common Lisp, etc.
  - the_only_law 6y ago
    God there's been so many times I've been working on something and fighting with mainstream languages to produce what I want when I find a language that allows me to solve my problem expressively an simply with ease. Some of them see industrial usage but they're still not very common.
- ragnese 6y ago
  > Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me. Can you elaborate on two things: 1. What would this language have that Rust doesn't? I don't know Julia. 2. Why?? Rust's memory management is the main reason it isn't being adopted even faster than it is, IMO. The VAST majority of domains don't WANT Rust's memory management. Garbage collection is great and not even "slow" (see OCaml). Rust's memory management has to be the way it is because it needs to be useful in domains where C and C++ are used.
sradman 6y ago
Good stuff, hugged to death [1]: > In the end, code doesn’t make software – people and communities do... It’s hard to beat an incumbent, and even harder to do so without having a large target user community you can capture with a compelling use case. We need a better name for the category of Machine Learning Workbench tools that include Julia, R, and NumPy+ (the ML ecosystem that uses Python as an Internal DSL). The compelling use case for Julia is that it is a modern language built on top of the LLVM platform (like Rust and Swift). There is no shame in not winning when you were late out of the gate; see the story of ARM. The value proposition hasn't disappeared it just didn't outpace the evolving bricolage of NumPy+ and its new complementers (Jupyter, PyTorch, TensorFlow). [1] http://webcache.googleusercontent.com/search?q=cache:Awfh5p84MFYJ:https://chrisvoncsefalvay.com/2021/03/07/julia-a-post-mortem/&client=ms-unknown&hl=en&gl=ca&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:Awfh5p8...
adsharma 6y ago
There is another way to add value over python. Transpile python to Julia. One place where Julia has an opportunity is to make easily distributable small binaries, which work better than par files.
chrisvcsefalvay 6y ago
Y'all broke my server. :) Lots of great comments here. I don't do much Hacker News-based polemics, so I have extended the original post on my website with some summary responses to a bunch of really thoughtful comments here. Thanks all!
peey 6y ago
I've always viewed Julia as a language for scientific computing professionals [1]. The article pronounces Julia's death only based on popularity relative to other languages. Yet, it's not clear what the author is comparing it to. The comparisons I see are MATLAB and FORTRAN, to which Julia seems to stand third in TIOBE Index [2] that the author is using. The author doesn't seem to focus on this. The author mentions > Julia’s target user is harder to define. I have struggled with this while writing Learn Julia. I wonder if it may not be the case that the author has developed his own notion of what Julia ought to be. And I'll agree that Julia may have failed his grand vision to displace large parts of Python, but I do not think that that vision is based in reality. Python users that want to use frameworks written in other, faster languages (like C++) will forever continue to use Python and enjoy the vast libraries that it offers which aren't centred around scientific computing. [1]: There seems to be a list on https://juliacomputing.com/ https://juliacomputing.com/. Arguably their needs might be very different than the author's. But I can't say because the article's arguments are not based on technical shortcomings. [2]: In the TIOBE Index (as a proxy for popularity) MATLAB gets 1.04%, Fortran 0.83%, and Julia 0.41% (GNU's Octave, the main FOSS Matlab competitor, is nowhere to be seen). I do not know what these percentages mean though https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/

107 points by LittlePeter 6y ago

Archive link as the article seems to be down: https://web.archive.org/web/20210308114008/https://chrisvoncsefalvay.com/2021/03/07/julia-a-post-mortem/ https://web.archive.org/web/20210308114008/https://chrisvonc...

make3 6y ago

cached because the blog was hugged to death: http://webcache.googleusercontent.com/search?q=cache:Awfh5p84MFYJ:https://chrisvoncsefalvay.com/2021/03/07/julia-a-post-mortem/&client=ms-unknown&hl=en&gl=ca&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:Awfh5p8...

mech422 6y ago

Interesting.. I thought Julia was on the rise ?

dagw 6y ago
It probably still is, but by all accounts it is rising a lot slower than many people had hoped for.
- dunefox 6y ago
  Hopes are free. If you want it to rise quicker you have to use it and contribute. "Why would I use it if few people do?" is quite paradoxical.
  - michaericalribo 6y ago
    Definitely not paradoxical. Network effects of out-of-the-box tooling/features—I mean a robust, extensive set of libraries to accomplish basic and moderately complex statistical / ML tasks—is the table stakes here, and depends strongly on whether more than a “few people do” already.
bsdubernerd 6y ago
It is. But if your aim is to displace (never mind replace!) an old, established niche, it's a very steep uphill. Like the OP, I still use a ton of python. And I consider python to be a newcomer in the sci community, still gaining momentum with perhaps a bigger uptick in the recent years.
- phkahler 6y ago
  >> But if your aim is to displace (never mind replace!) an old, established niche, it's a very steep uphill. If your goal is to beat someone else then you're playing the wrong game.
  - coldtea 6y ago
    This doesn't say much. First, as an analogy, since in most games, the goal is precisly to beat someone else, and there's nothing wrong with that (it's the very meaning of sports competition). Second, because for a programming language community and adoption and ecosystems matters, and you don't get all those without beating "someone else" or at least comming close to doing it. Either you magically double the number of devs/people doing data science, or you atract data scientists from Python and R (either attract existing users of Python, or get more new users into you rather than in Python).
- snicker7 6y ago
  The goal is to create a great programming language to solve real problems.
  - michaericalribo 6y ago
    I already solve real problems in Python—why bother learning yet another language, and one our data engineers/backend folks don’t know? That larger context of implementation / development / deployment is a huge deciding factor for real-world problem solving, not how “great” a language is from a design perspective.
    - 6y ago
coldtea 6y ago
Yes. For 10 years and probably 10 more before it gets anywhere near significant adoption...

unwind 6y ago

Meta: in Chrome on Android, I just get a very tall dark blue box. Fail.

superbcarrot 6y ago

Is the post only based on TIOBE? The same index that currently ranks JavaScript below Visual Basic and SQL below Assembly? That ranking is off by so much that anyone who takes it seriously loses at lot of credibility from the start. I'm not entirely on board with the Julia hype train but they certainly got some things right and both the ecosystem and the community are healthy and growing. Julia doesn't need to replace a bunch of other languages immediately to be successful. Implying that the language is dead by using the word post-mortem is just demonstrably false.

st3fan 6y ago
Maybe you should read to the end instead.
- superbcarrot 6y ago
  I did. I still don't get how the author's decision to not use the language is enough to declare it dead.
  - parsimo2010 6y ago
    That’s not the only factor. Their publisher also decided there wasn’t a market for a book and declined to publish. The author also didn’t say Julia was a dead language, it just failed to realize the dream of becoming the language, and is instead just a language in a sea of many.
    - dunefox 6y ago
      "Post-mortem" doesn't imply that it's dead? And also, of course there isn't a mass market for a book on a programming language that's not python and due to most learning material being available online. This is a stupid metric.
      - mbeex 6y ago
        I got the impression, that he refers more to the fate of his own hopes.

ramboldio 6y ago

I agree that Julia can't stack up to Python in terms of a data science / statistics domain. But in everything people use MATLAB for, Julia actually has the upside in many of the qualities discussed in the article: Community, Package Ecosystem, annoying licensing bureaucracy etc etc.

socialdemocrat 6y ago
The best bet for Julia might be to be a Trojan horse in the Python ecosystem. By making the best of breed packages in specific domains it can become the first pick in the Python community rather than C/C++ based packages. If Julia is the engine that drives all the critical parts in Python rather than C/C++, then it has a way to get the foot in the door. People will stop and ask: Why am I using Python if I could just use Julia directly?
- andi999 6y ago
  Because you want a snappy repl?
  - FridgeSeal 6y ago
    Every major release has improved performance in the language and its use, and it doesn’t really take that much before most of the stuff you do is already compiled and you get a repl experience far superior to pythons.
    - michaericalribo 6y ago
      That may be true for elaborate analyses, but doesn’t really address exploratory analysis that changes dramatically from command to command. The use case for REPL-driven data science is experimentation, not performance
- phillc73 6y ago
  The same with R. There's already the excellent JuliaCall[1] package, for embedding Julia code in R. Listed in the README are some R packages, using Julia code through JuliaCall. [1] https://github.com/Non-Contradiction/JuliaCall https://github.com/Non-Contradiction/JuliaCall

deleted 6y ago

[deleted]

nudpiedo 6y ago

my takeaway: basically python ate the toast and there is fierce competition for OS devs. Ecosystem gravity becomes stronger the more mass it gets. I also think that feature creep is a proven strategy for mainstream language (see Java, C++, Python) but a killing feature for rising languages.

socialdemocrat 6y ago

Lots of truths there but also colored by someone who evidently has not been a fan of technologies before and seen how it works. I am not as pessimistic as a Julia fan. Why? Because I have been where this guy is now ever since I was an Amiga user. I was like that with Python, Ruby, Go and a whole other languages. And what I learned from that is that it takes time. Neither Python, Ruby or Go had success over night. Yet almost all these languages I homed in on in the past have seen what I would call success later. I was certain Perl would go downhill when it was at its top. I kept argue with Perl fans that Python was a cleaner language that would see more success. Ditto with Ruby. That turned out to be quite accurate. I said while D looked like a nice replacement for C++, it simply wasn't big enough improvement to go anywhere. That also seems to have been an accurate prediction. Go on the other hand had a very obvious appeal from the get go. It did something important different and sufficiently better than before while keeping things simple. I am confident about Julia, because I have not in 20 years since a language with so much potential and so many advantages. You just got to give it time. This reminds me of myself following solar and wind energy in the early 90s and deciding it was not going anywhere. Ironically I see people like Michael Shellenberger having become a cynic about wind and solar now that it has actually achieved some measure of success. Why? Because it didn't happen fast enough. He poured all his enthusiasm and hope into this industry long before there was reasons to do so. People have to be aware of the same about Julia. It is not taking over the world any time soon. There is a long road ahead. And I would not define success as getting to Python scale. But if Julia can get to a similar position as Go is today, then I would call that success.

zhdc1 6y ago
Julia's already making (fairly substantial) in roads. It's just not as visible as Python, since the niche it's occupying is much smaller and out of the way.
hatmatrix 6y ago
When Julia finally comes of age, there will be a new, emerging language claiming it will eat Julia for lunch.
- 6y ago

dash2 6y ago

Unconvincing. 1. There's plenty of niches. I don't think anyone is pushing Julia as the new general purpose programming language. 2. Ecosystems and network effects are real, but if you conquer a niche, you can still win. R's doing fine. 3. Specialists seem to like Julia and are writing good stuff in it. I don't see why that attraction shouldn't bring more users in. Indeed, it's still rising in PYPL, as linked by another comment.

xiphias2 6y ago

Julia is a language that looks very simple, but the more you use it, the more you realize how complex and unpredictable it is. I think that Union types do more harm than good (why would you want a function to return Union of int and float instead of compile error? It totally slows down the program) Array{Number} is totally different from Array{:<Number}, and shouldn’t be allowed, as it is inefficient. 1-based indexing was a mistake, and I have seen it emitting inefficient code in the PTX compiler. But the worst and hardest part is the rule/heuristic for multiple dispatch: it’s so complex, that it isn’t even documented. It should probably throw more errors and be predictable instead of trying to be so smart.

FridgeSeal 6y ago
> 1-based indexing was a mistake The most software I write, the more I am convinced that 1-based indexing is what most languages should be using, either the exception being the very specific use-case of needing to track offsets by hand for some reason. 1-based indexing is so much easier to reason about, but zero based indexing is seen as “the one true way” due its ubiquity, and not because it’s actually better. > and I have seen it emitting inefficient code in the PTX compiler. Have you raised this with the devs? This seems like something worth raising as an issue.
- tgv 6y ago
  Both approaches have their advantages, IMO. Inclusive ranges are usually easier to understand, but e.g. when picking a (uniformly distributed) random element from an array, nothing beats a[floor(rnd() * len(a)].
  - dunefox 6y ago
    > nothing beats a[floor(rnd() * len(a)] What's wrong with rand(a)?
  - socialdemocrat 6y ago
    How is that very readable? In Julia, this will pick a random value from an array: rand([3, 4, 5, 1]) While this picks a value from a range: rand(1:10) Much more straightforward to read IMHO. Where I prefer 0-based index is when dealing with coordinate systems and memory locations.

da39a3ee 6y ago

I think this post is a bit immature. These things take time. Julia should just keep on striving for excellence and I'm sure it doesn't need me saying so. I've spent the last decade writing python professionally for web backend software engineering: it is a fantastic language for getting out of your way and allowing you to think and build what you want. And things like pattern matching show that it's still taking significant steps forward. But, languages should be statically typed: modern compilers offer too much benefit to development workflows to turn this down. So you can try to patch typing on to a dynamic language but my impression is that mypy is a hack compared to what was delivered to javascript in the form of typescript. I suspect that people will eventually swing back towards statically typed languages for the development tooling. Especially as the future needs more programmers and more help for programmers to build things correctly vs the early 21st century era of hackers writing untyped python in vim. Above comments are mainly aimed at web backend. I'm aware of Python's dominance in data science and machine learning but perhaps ultimately the same will hold true there -- that humanity will ultimately go for solutions that keep developers on the rails more. (Jupyter notebooks are a disaster when it comes to building correct solutions: no encouragement to use version control; out of control invisible global state etc.)

leephillips 6y ago
Julia has its own notebook that solves the issues you mention with Jupyter: https://lwn.net/Articles/835930/ https://lwn.net/Articles/835930/. With Pluto there is no hidden global state, everything is deterministic, and the notebooks are Julia files, so version control is as natural as when writing straight jl programs.

neilwilson 6y ago

Python is terrible for Agent Based Modelling because of the Python Tax when dealing with so many entities. The question is would Julia be any better?

FranzFerdiNaN 6y ago
There is https://juliadynamics.github.io/Agents.jl/stable/ https://juliadynamics.github.io/Agents.jl/stable/
ChrisRackauckas 6y ago
Agents.jl benchmarks really well. See https://arxiv.org/abs/2101.10072 https://arxiv.org/abs/2101.10072 . Or if you use the libraries you will immediately feel the difference.

FridgeSeal 6y ago

This feels like a very strongly worded title for a fairly lacklustre article. There’s Python the language and “Python the dsl for tensor frameworks”, the former has arguably lost some ground/mindshare to newer, less “hobbled” languages, and the latter exists not by virtue of its own strengths but as the convenient vehicle for frameworks written by 2 enormous corporations. Julia hasn’t overtaken Pythons ecosystem yet, but how far its come in relatively little time is the real testament to its community-that which the author decries as lacking. Using weird outdated rankings and citing “that one package that kind of works in very specific circumstances” (Numba) as proof that all Pythons issues are solved and Julia is over is a weak argument at best, and deceptive at worst. What Julia could really, really benefit from though is some vocal commercial backing-had google chosen to rewrite Tensorflow in Julia I think 2 things would have happened: 1. the project would have actually succeeded and been finished (in a “this is the tensorflow engine now” sense) 2. It would have done absolute wonders for the Julia ecosystem and mindshare and we wouldn’t be having this taudry discussion. That didn’t happen (unless some tensorflow product managers want a promotion by re-launching a tensorflow rewrite? ;) ) so they need another source of major support IMO.

apples2apples 6y ago
I'm sorry but deep learning is only a very small part of why Python is preferred by data scientists. The fact that Python was the the preferred language is why the enormous corporations wrote bindings to them. Both of these frameworks exist in the Julia ecosystem.
- FridgeSeal 6y ago
  As someone who does data science, I roll my eyes every time I have to touch Python. It’s ubiquitous, but it actually sucks once you get used to better languages. It is somewhat circular: it was preferred because your earlier alternatives were Java or C(++) both of which had their shortcomings. SKLearn is still one of the most feature-complete and powerful libraries and it was Python only and thus drew a crowd. A lot of people who write data science code, I would be confident to bet that if you taught them Julia first, they’d prefer that.

vsskanth 6y ago

Julia has an advantage python does not - high quality packages written in pure Julia that compose well with each other. They aren't just C wrappers. Some of their AD and differential equation libs are state of the art. Being the best at a certain niche will attract users who will eventually stay and contribute. I use python a lot but it can't beat Julia for simulating an ODE. So I use it too

agumonkey 6y ago
> They aren't just C wrappers. I'd be warried about that. To some people (battle tested libs) C wrappers are better than a fully coherent single-language ecosystem.
- dunefox 6y ago
  You can just use the wrappers. Also, many libraries are using wrappers where available. Julia allows you to not exclusively rely on C libraries because it is efficient enough to implement them in itself.
- vcxy 6y ago
  One problem with this is that, as mentioned, some julia packages actually are state of the art. There isn't a C equivalent for everything DifferentialEquations.jl can do. Ditto for Zygote.jl and Enzyme.jl.
dagw 6y ago
They aren't just C wrappers The big advantage with the C wrappers approach is that I know I'll get the same features and results as everybody else using that C library.
- dunefox 6y ago
  Nothing is stopping you from using the C library.

enriquto 6y ago

I hope Julia succeeds and replaces the clunky R and numpy+python "ecosystems". Every few months I try to decide to do all my computing on Julia and quit fooling around with lesser environments. And every time I get stuck at the same point: the slow startup time. I want to draw 100 plots per second, by calling the same Julia script on a bash loop 100 times; but this is utterly impossible. Of course, the Julia community has a standard answer to this concern: this is not how you are supposed to use the language. But I don't listen to them, for the best tools are those that perform well doing tasks they were not designed to do. I feel the same dismay when I get stuck at slow loops in Python, and the Python people tell me that I'm not supposed to use loops. Well, this is the main reason that I want to move away from Python and into Julia. I'm not interested in the implementation details of the language interpreter. The language is already very good, and the libraries are excellent. My main point of friction against using Julia is the slow startup time that forbids its use in a wide variety of contexts. I feel like the best usage of resources for the Julia community would be to spend all available money in hiring a Mike Pall-esque figure to advise them on JIT. Even if it was a part-time or a one-shot hire.

dunefox 6y ago
Start up time for the interpreter is 0.13s for me: ~ time julia -E "1+1" What takes time is precompilation of packages and functions - with Julia 1.6 the precompilation is much faster now than before. Your bash script that calls Julia 100 times is indeed not something that Julia was made for. It excels in many other areas and that's quite fine. I'm okay with plotting in a bash script in Python if it means that I can use Julia for everything else.
- michaericalribo 6y ago
  Your last sentence seems to ignore the reality that plotting is only one step in a larger pipeline. It sounds miserable to need to write analytics code twice, once in Julia “for everything else” and again in Python just for the plotting. I’ll just write the whole thing in Python and save myself the headache.
  - 6y ago

deleted 6y ago

[deleted]

snicker7 6y ago

tl;dr -- Julia is not that popular (yet!). A pretty good indictment of the language is that a "port-mortem" didn't mention any of Julia's technical limitations, but rather its popularity. With regards to popularity, Julia has had a lot of adaptation over the last year. And once it can produce small-ish static binaries (.so/.dll), I think there would be a surge in popularity.

dagw 6y ago
And once it can produce small-ish static binaries That would be a real killer feature. If Julia could easily create small stand alone .exe files that I could just give to colleagues to run, that would be a seriously tempting feature.
- snicker7 6y ago
  This is a promised feature (one that Viral Shah made recently). Julia already provides user-facing compiler hooks (see JET.jl for static Julia analysis). So it theoretically should be possible for someone to create an AOT compiler today. Not sure what the current limitations are.
- oscardssmith 6y ago
  Check out StaticCompiler.jl. it's very beta, but it works (at least for some small problems)

bachmeier 6y ago

This post overlooks that language adoption is something that happens over decades. It's much too early to conclude anything about Julia adoption. I also think there's way too much focus in the post about Julia taking share away from Python or R. The real market is Matlab programmers, for one and only one reason - Matlab is extremely expensive. A number of years ago I was talking with a vice president of one of the Federal Reserve banks that told me one of their priorities was to move away from Matlab due to the high and growing licensing costs. The New York Fed has in fact moved much of its code from Matlab to Julia: http://frbny-dsge.github.io/DSGE.jl/latest/ http://frbny-dsge.github.io/DSGE.jl/latest/ Julia has momentum in parts of economics that have traditionally been heavy users of Matlab: https://quantecon.org/ https://quantecon.org/

higerordermap 6y ago
This is interesting. Glad to see matlab being phased out.
xtracto 6y ago
> This post overlooks that language adoption is something that happens over decades. It's much too early to conclude anything about Julia adoption. Spot on, I was doing R back in 2005, when it was slowly become more famous. R fist official release was in 1995. Which means that it took R 26 years to get to the point where it is now. If Julia was launched on 2012, its tipping point may come 20 years later, around 2030.
- bachmeier 6y ago
  R is one of the languages I was thinking about, but even 1995 understates how long it took. R is an open source implementation of the S language that dates back to 1976.

ruph123 6y ago

While I don't think this piece was well argued I must agreee with the sentiment that Julia is somewhat of a disappointment, at least for me personally. Last year I started learning Rust and wanted to use it instead of C++ in the future. I since have programmed quite a lot in it, contributed to open source software and absolutely have fallen in love with it. So this year I wanted to replace my default scripting language (Python) with Julia and potentially use it for my simulations or ML in the future. But every time I take a stab at Julia - last time around the release of version 1 - it never really stops feeling foreign. Everything is slightly unintuitive and weird. Also, learning Julia made me realize how amazing Rust's learning resources are. Besides the official book and the API docs (with an amazing template), there are a lot of great third party and actively maintained resources likes cheats.rs. I never felt Rust was unituitive or hard to learn. Even if some concepts are unique, the resources do a great job of introducing them to you. While Julia's learning website lists an exercism course, its manual and a bunch of video lectures. I think selling Julia as a Python competitor raises wrong expectations. Julia may look easy or Python-like but is far more difficult to use IMHO. They may be similar in terms of applications but at least in how they feel to use, they are very different. I still haven't given up but whereas I speak very highly and enthusiastically of Rust and recommend it everywhere (yes I am one of those people), I cannot see myself doing the same for Julia in the future. Ps.: I wish there was a book club-like way of learning programming languages and discussing progress with friends. That would make learning even more fun.

dgellow 6y ago
> Ps.: I wish there was a book club-like way of learning programming languages and discussing progress with friends. That would make learning even more fun. That might be an awesome idea for a Clubhouse club! A weekly programming language meetup with a theme decided in advance.
- ruph123 6y ago
  Or an Element chat? I would not sign up with that service because of their sketchy privacy setup.
mountainriver 6y ago

qaq 6y ago

Here's the funny thing there are more full time developers working on Julia than Python and the rate of progress in Julia ecosystem is truly amazing.

tsdlts 6y ago

Julia v1 was released in 2018. It's currently about as popular as elixir. Is the author really complaining that it hasn't over taken as the lingua franca in two years? Python is over 20 years old and it's only hit it's stride in popularity over the last 5.

socialdemocrat 6y ago
Exactly!! Much too early to draw conclusions. Look at Go, it having a decent measure of success today. A couple of more years in the market makes a big difference.
js8 6y ago
Actually, Python came into TIOBE Top 10 in around 2004. So it took more than a decade for it to became decently popular; your point still stands.

A-Train 6y ago

Julia will never become a mainstream language because it is not general enough. The syntax is inspired by matlab which is good for linear algebra. Also it is not object oriented which is probably the most popular paradigm. Python will not be overtaken soon by such an exotic language.

stellalo 6y ago
Object orientation is no “must have” for a general purpose language to become popular. OO is a paradigm like many others, and it is one that in my opinion is much more abused than, say, functional features. In a few years we will look back at all those class hierarchies and wonder: man, what the hell were we thinking.
socialdemocrat 6y ago
Of course Julia is general enough. Whether you end your for-loop with `end` or `}` doesn't make any difference in what you can use the language for. That Matlab is not great at general programming has absolutely nothing to do with the syntax and everything to do with semantics. In Matlab pretty much everything is a matrix. That is not the case in Julia. Julia work with scalar values just as well as Python. Actually it does it much better. Object-oriented programming has been on the way out from all major new languages for years now. Go, Rust, Kotlin, Clojure, Julia and many others have downplayed object-oriented programming significantly.
krumbie 6y ago
I'd actually say the opposite. In my experience, n-dimensional arrays for example are very useful for problems that don't have anything to do with linear algebra. And in Julia it's just so convenient that all the high level functions manipulating such arrays are fast, and therefore much simpler to write.
Recurecur 6y ago
'Also it is not object oriented which is probably the most popular paradigm.' Popularity isn't a suitable metric for 'good'. Look at McDonald's food. 'Python will not be overtaken soon by such an exotic language.' Python and Julia aren't competitors. Python is suitable for scripts and gluing high performance code together. Julia is a general purpose language which is suitable for writing high performance code. Object orientation was likely a mistake. The industry is slowly moving away from it. There is no abstraction you can express with object orientation that you can't express with multiple dispatch. Structs are very much like the data part of objects.

cmrdporcupine 6y ago

Honestly, I learned Python in 1995, and used it where I could for CGI script programming and scripts into the early 2000s, and tried to get jobs programming it throughout that time with no success at all. Throughout that time, Perl was still in use all over but declining, PHP was growing like an unpleasant weed, and it seemed Ruby was ascendant for the "cool" stuff... but Python wasn't cool, most hiring managers had never heard of it, and while Google used it, that was pretty much it for large company support. Then while I wasn't looking (I lost interest in dynamically typed languages and focused on modern static typed languages) it became insanely popular -- and I actually got pushed out of a lead role at a job in part because folks wanted to rewrite into Python something we did in Java/Scala. Python popularity skyrocketed over the next 10 years. Numpy had something to do with it but also many other factors, not a lot of them initiated by the Python community itself, or by Guido. All this to say, language popularity is fickle and not terribly predictable. Prognosticating like this is silly. Julia is nice. Kinda wish I had a job where I got to play with it. Which is about how I was with Python, 20 years ago.

nromiun 6y ago

> We were all going to heaven, and that right soon. The language wars would end, we would finally get a lingua franca for anywhere code performance mattered, Julia would take over the TIOBE Index, and we’d all be home for tea and medals. This type of thinking is so alien to me. A mainstream language like python has its appeals (like a large quantity of docs and many libraries), but TIOBE ranking? Language wars? Who cares about that? At the end of the day a language is a tool, nothing else (Matlab is a good example).

xaduha 6y ago

I have an irrational aversion to LLVM languages and I don't know why, because I have close to zero personal experience with them. But when I find out that some new language uses LLVM my interest in it drops.

deleted 6y ago

[deleted]

stellalo 6y ago

> What’s the unique selling point? It’s multiple dispatch, how did the almost-author-of-a-book-on-the-language not get that?

dunefox 6y ago
Maybe that's where the almost comes from.

systems 6y ago

I found Julia scoping rules to be weird, and a bit off putting While this clearly doesn't seem to impact its adoption, or its community from creating great things For the new comer to the language, the scoping rules just gives a bad feeling for the language, I wish they fix it in future versions check my github issue if you want to know more what I mean by off putting scoping rules https://github.com/JuliaLang/julia/issues/37187 https://github.com/JuliaLang/julia/issues/37187

stellalo 6y ago

This article starts off with the following premise: “one of Julia’s original promises was to take over other languages in terms of popularity” (paraphrased). Honestly, I cannot find such promise in the original announcement: https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/ Ex falso quodlibet

Xcelerate 6y ago

I think claims of Julia's death are premature. I used it all throughout grad school shortly after it was released, and there are things the language does so much better than any other language I know of that I find it hard to imagine it just disappearing into the ether. The only way I can think of it really dying off is if more popular languages absorb the best features of Julia, making it redundant. It's hard to make inroads into Python's domain because of the strong networks effects, but I think if one or two major companies onboard the language, then we might see a snowball effect. Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me.

coldtea 6y ago
>I used it all throughout grad school shortly after it was released, and there are things the language does so much better than any other language I know of that I find it hard to imagine it just disappearing into the ether That is also true of Common Lisp and Smalltalk, though, and both are as good as "into the ether".
- ragnese 6y ago
  Yeah. There's "dead" and there's "DEAD". Many languages are "dead": COBOL, probably Perl 5, Groovy, Common Lisp, etc.
- the_only_law 6y ago
  God there's been so many times I've been working on something and fighting with mainstream languages to produce what I want when I find a language that allows me to solve my problem expressively an simply with ease. Some of them see industrial usage but they're still not very common.
ragnese 6y ago
> Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me. Can you elaborate on two things: 1. What would this language have that Rust doesn't? I don't know Julia. 2. Why?? Rust's memory management is the main reason it isn't being adopted even faster than it is, IMO. The VAST majority of domains don't WANT Rust's memory management. Garbage collection is great and not even "slow" (see OCaml). Rust's memory management has to be the way it is because it needs to be useful in domains where C and C++ are used.

sradman 6y ago

Good stuff, hugged to death [1]: > In the end, code doesn’t make software – people and communities do... It’s hard to beat an incumbent, and even harder to do so without having a large target user community you can capture with a compelling use case. We need a better name for the category of Machine Learning Workbench tools that include Julia, R, and NumPy+ (the ML ecosystem that uses Python as an Internal DSL). The compelling use case for Julia is that it is a modern language built on top of the LLVM platform (like Rust and Swift). There is no shame in not winning when you were late out of the gate; see the story of ARM. The value proposition hasn't disappeared it just didn't outpace the evolving bricolage of NumPy+ and its new complementers (Jupyter, PyTorch, TensorFlow). [1] http://webcache.googleusercontent.com/search?q=cache:Awfh5p84MFYJ:https://chrisvoncsefalvay.com/2021/03/07/julia-a-post-mortem/&client=ms-unknown&hl=en&gl=ca&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:Awfh5p8...

adsharma 6y ago

There is another way to add value over python. Transpile python to Julia. One place where Julia has an opportunity is to make easily distributable small binaries, which work better than par files.

chrisvcsefalvay 6y ago

Y'all broke my server. :) Lots of great comments here. I don't do much Hacker News-based polemics, so I have extended the original post on my website with some summary responses to a bunch of really thoughtful comments here. Thanks all!

peey 6y ago

I've always viewed Julia as a language for scientific computing professionals [1]. The article pronounces Julia's death only based on popularity relative to other languages. Yet, it's not clear what the author is comparing it to. The comparisons I see are MATLAB and FORTRAN, to which Julia seems to stand third in TIOBE Index [2] that the author is using. The author doesn't seem to focus on this. The author mentions > Julia’s target user is harder to define. I have struggled with this while writing Learn Julia. I wonder if it may not be the case that the author has developed his own notion of what Julia ought to be. And I'll agree that Julia may have failed his grand vision to displace large parts of Python, but I do not think that that vision is based in reality. Python users that want to use frameworks written in other, faster languages (like C++) will forever continue to use Python and enjoy the vast libraries that it offers which aren't centred around scientific computing. [1]: There seems to be a list on https://juliacomputing.com/ https://juliacomputing.com/. Arguably their needs might be very different than the author's. But I can't say because the article's arguments are not based on technical shortcomings. [2]: In the TIOBE Index (as a proxy for popularity) MATLAB gets 1.04%, Fortran 0.83%, and Julia 0.41% (GNU's Octave, the main FOSS Matlab competitor, is nowhere to be seen). I do not know what these percentages mean though https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/