18 ms·

What's Great about Julia?

198 points by jakobnissen 4y ago

aswanson 4y ago
The core language is unstable Welp. Im out.
- Tarrosion 4y ago
  I don't see that anywhere in the post - was that in a previous version, or somewhere else, or your summary? This is surprising, because the Julia devs have been very careful to maintain backwards compatibility since version 1.0 released in 2018.
  - mrtweetyhack 4y ago
  - celrod 4y ago
    I recently wanted to run some Python benchmarks, and was surprised to find that some major Python packages (i.e. Numba) didn't work on the latest Python release. In Julia, all open source packages that pass tests on the latest release are confirmed to also pass on a release candidate before that candidate can become the next release. A major package being incompatible with a new Julia version just doesn't happen. Julia takes its stability guarantees seriously.
    - ChrisRackauckas 4y ago
      Indeed. There's a nice example from yesterday where someone asked about whether anyone is planning to update ParallelDataTransfer.jl because it's so old (last update August 2018) that it doesn't have any of the modern package development features that became standard post v1.0. But I was like, that doesn't mean it's not working... Julia is stable. And indeed if you run it, it still passes tests on Julia v1.8, more than 4 years later. That's a testimony of just how stable post-v1.0 has been. And mind you, this is a library of tooling for distributed computing, so it's touching that is considered a deeper feature. Source: https://discourse.julialang.org/t/discontinuation-of-paralleldatatransfer-jl/91294 https://discourse.julialang.org/t/discontinuation-of-paralle...
ubj 4y ago
Great writeup. Minor comment about the portion of the post mentioning Conda being glacially slow: Mamba [1] is a much better drop-in replacement written in C++. Not only is it significantly faster, but error messages are much more sane and helpful. That being said, I do agree that Pkg.jl is much more sleek and modern than Conda/Mamba. [1]: https://github.com/mamba-org/mamba https://github.com/mamba-org/mamba
- modriano 4y ago
  Conda should have set the default for channel_priority to strict a while ago, it significantly reduces the search space [0], and it reduces the chances of the solver finding a poorly-specified-yet-nominally-compatible package build on some less rigorous channel. With strict channel_priority and conda-forge as my priority channel, it hasn't taken more than maybe a minute for to solve any dependencies (assuming the target packages are on the priority channel) for any of my own envs, although when I try to recreate envs that installed packages from many channels, I have experienced some long waits. [0] https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/conda-performance.html https://docs.conda.io/projects/conda/en/latest/user-guide/co...
  - adgjlsfhk1 4y ago
    A minute is still pretty long to just resolve version IMO.
eigenspace 4y ago
Nice post Jakob. I almost universally agree with the points here, especially the ones about the joy of optimizing Julia code.
clumsysmurf 4y ago
If one wanted to learn Julia, where is the best place to start? I looked at https://julialang.org/learning/books/ https://julialang.org/learning/books/ For new programming language XXX I look for a book like the "K&R for XXX". I see some older ones from Packt, but nothing like the official Rust Book, for example. There is "Think Julia" (OReilly) but its older.
- mxkopy 4y ago
  The way I learn new languages nowadays is 1. Look at example 'Hello world' code 2. Attempt a problem on Project Euler 3. Look at docs/source code to get what I'm missing 4. Repeat Julia docs are good for step 3. I don't think there are many super technical books like the one you're looking for, since Julia doesn't really have an industry that would produce them, and since the core is still being developed and all that.
- agucova 4y ago
  For experienced programmers, I usually recommend: 0. Watching this [0] Fireship video to get the “big picture” on the language. 1. Reading the “Noteworthy Differences from other Languages” [1] section of the manual, if your language is on the list. 2. Then, if you're hurried, read Learn Julia in Y Minutes [2], or otherwise read the official manual [3] in order, skipping sections you're not interested in. In case you're interested in scientific computing specifically, you can start from Chris Rackauckas' course on Parallel Computing and Scientific Machine Learning [4]. And if you don't have a straightforward application to test Julia on while learning, I would recommend doing the exercises available in Exercism [5], which are well-made and provide access to awesome mentors. As for books, Think Julia is pretty good imho, even if it's a little bit outdated. [0]: https://www.youtube.com/watch?v=JYs_94znYy0 https://www.youtube.com/watch?v=JYs_94znYy0 [1]: https://docs.julialang.org/en/v1/manual/noteworthy-differences/#Noteworthy-differences-from-MATLAB https://docs.julialang.org/en/v1/manual/noteworthy-differenc... [2]: https://learnxinyminutes.com/docs/julia/ https://learnxinyminutes.com/docs/julia/ [3]: https://docs.julialang.org/en/v1/manual/getting-started/ https://docs.julialang.org/en/v1/manual/getting-started/ [4]: https://www.youtube.com/watch?v=-lJK92bEKow&list=PLCAl7tjCwWyGjdzOOnlbGnVNZk0kB8VSa&index=2 https://www.youtube.com/watch?v=-lJK92bEKow&list=PLCAl7tjCwW... [5]: https://exercism.org/tracks/julia https://exercism.org/tracks/julia
UncleOxidant 4y ago
Agree with all of these points. Multiple Dispatch takes a bit of getting used to, but once you get it it just makes a lot of sense and allows for an amazing amount of code-reuse. And, yes, Julia's REPL is sooo much nicer to use than Python's - I always kind of cringe when I've gotta go back and use the Python REPL as it's so primitive by comparison. You can even tab-complete filenames in the current directory in the Julia REPL. Say you want to open a file called "example.log": julia> open("exam<TAB> will give you: julia> open("example.log"
- cdavid 4y ago
  It is not builtin, but ipython will give you that and most features mentioned in the article.
  - maegul 4y ago
    Yea. The comparison with the Python REPL makes me distrust this post a little. Any Python user who’d be interested in using Julia is or should be familiar with ipython. (If you’re not, it’s a better REPL originally made to make iterative scientific like programming easier in Python, made by the same person/people behind jupyter, which was originally called the ipython notebook.) Yes Python prides itself on its standard library and it’s be nice to have a better standard REPL. If this were the point being made I’d appreciate the post more. But, Python is a large and diverse ecosystem, so having different tools coming out of different domains all sharing the same language is part of the value, so it’s not the most hard hitting critique of Python. That the author made such a point of this, in my eyes, make them seem a little too keen to dunk in Julia’s major “big-brother” competitor rather than being as fair and accurate as they can. Though, I haven’t read their previous Julia-critical post, so I may very well be overreacting. Still, use ipython.
    - sundarurfriend 4y ago
      > Any Python user who’d be interested in using Julia is or should be familiar with ipython. I would have assumed so too, but the number of (reasonably competent) Python programmers who are shocked to know there are alternate REPL interfaces would suggest otherwise. I was lucky enough to get into Python when these thing were still new and shiny, so I came across ipython/bpython pretty early on. But nowadays the very fact that ipython is well-established means that people don't talk about it as much, assuming everyone knows about it, so it's very much possible that someone comes across news about Julia (which is still "new and shiny" enough to be in the news) and doesn't know about ipython. Defaults matter, and are the only thing used by a large segment of users, even in today's information-rich and one-tap-install world.
Volker_W 4y ago
Shameless plug: I wrote about what I think is bad about Julia: https://weissmann.pm/julialang/ https://weissmann.pm/julialang/
- adgjlsfhk1 4y ago
  As someone who really likes Julia, I agree with almost all of this. The good news is that a lot of these areas are getting active improvements.
- ChrisRackauckas 4y ago
  The error messages you mentioned in here have been completely overhauled. In fact, most things in SciML are now caught and throw very high level error messages. We also revamped the whole documentation and added docstrings everywhere. See https://sciml.ai/news/2022/10/08/error_messages/ https://sciml.ai/news/2022/10/08/error_messages/ . We're also in the middle of rolling out a new documentation (https://docs.sciml.ai/Overview/stable/ https://docs.sciml.ai/Overview/stable/) that has a lot more of a split between tutorials and references. It's not complete, but the core push of this should be completed in about 2 weeks. As for loading times, we've transformed those as documented in https://sciml.ai/news/2022/09/21/compile_time/ https://sciml.ai/news/2022/09/21/compile_time/ (taking a core case from 30 seconds to 0.1 seconds), and Julia v1.9 is releasing a feature where package precompilation can store LLVM-compiled binaries. So I think most of the blog post has already been addressed? The one thing we haven't done is improved type printing. I am with you on that one, and actually opened a Base Julia issue about it way before your blog post: https://github.com/JuliaLang/julia/issues/36517 https://github.com/JuliaLang/julia/issues/36517 . It requires a Base Julia fix though, so that's a bit out of my hands. Also, I think it would be good for Base Julia to do a bit of the error message interpreting that SciML has done, specifically for broadcast (https://github.com/JuliaLang/julia/issues/45086 https://github.com/JuliaLang/julia/issues/45086). So there are some more improvements to be done, but I don't think the blog post is up-to-date given the overhauls that were done in the summer of 2022 (thanks to your feedback). It would be nice to hear updated thoughts when you have a chance to try all of these improvements (especially when v1.9 comes out with the cached binaries)!
  - 4y ago
jostmey 4y ago
I loved the early iterations of Julia. It was everything I wanted… fast, simple, and readable. Somehow the language has become less simple and readable to the point I don’t recommend it anymore
canjobear 4y ago
As someone who has used and contributed to Julia, I find Yuri Vishnevsky's arguments about correctness totally fatal [0]. And Yuri's examples are not obscure, they are totally realistic scenarios where Julia silently returns wrong results in ways that may be hard to detect. I do mostly scientific computing, and the idea that I might have to retract a paper because of a bug in the programming language is intolerable. It doesn't matter how beautiful and fun to write and develop the language is if it can't be trusted to return correct results. [0] https://yuri.is/not-julia/ https://yuri.is/not-julia/
- Joel_Mckay 4y ago
  If I recall, the same argument was used to justify Octave's Fortran coded libraries for stats. Primarily, it was an argument about historical consistency in the assumptions people agreed upon at NASA. Julia's library compatibility is still an issue, but hardly related to the language itself. Unlike many languages, Julia has regression testing for its graphical plotting output. This means it can and usually does check that a given output matches a previously known function(s) output across each release iteration. This means that unlike many languages that fix/ignore various external library versions, Julia actually checks that data gives the exact same results every time. The caveat is that people must report issues to the project, or add regression tests to ensure correctness persists throughout the ecosystem. =)
- teruakohatu 4y ago
  This undated blog post (published in about May this year) is not the last word on Julia. There have been fixes made to issues brought up. Julia's authors get credit for trying to rewrite many core compute/LA libraries from scratch in a composable manner rather than using ancient fortran code nobody dares touch. That said, the article was a good wake up call to the community that tests and correctness is vital for trust. Edit: First paragraph removed as the person I referred to disagrees with me and asked me to make an edit.
  - fhoituwoeir324 4y ago
    >... using ancient fortran code nobody dares touch. Only the BLAS/LAPACK reference implementation are in F77. Intel MKL, OpenBLAS, ATLAS and other are all in a mix of C and ASM.
blindseer 4y ago
> A better catchphrase for Julia might be "The best expressiveness / performance tradeoff you have ever seen". Man, Jakob just has a way of writing that gets right to the point. Nice post. My only complaint about the post is that in Python you have many different REPL options. For example, both ipython and bpython are miles ahead of the Julia REPL. I agree though that the Julia default REPL is better than the Python default REPL. I particularly like the shell mode in Julia. You can also make your own modes, like a sql mode or any custom DSL mode. I have been very critical about Julia in the past, so I'll say some positive things before I complain more :) - The package management in Julia is god-like. Specifically, there's a whole subset of packages that are just binaries and libraries cross compiled on VMs for Windows / Mac / Linux + x86 / x64 / ARM, and it just works. There's no more trying to compile code on a users computer when trying to install a package, it's beautiful. It is truly a phenomenal piece of engineering, and I cannot praise it enough. Hats off to the core team responsible for this. - Multithreading is such a joy to use. Compared to any other dynamic GC language, Julia and Go are pretty much up there in terms of usability + features. So much better than Python or R. But while I prefer Julia over Go, I do prefer Rust over Julia. Now for some of my grievances. I'm a nobody in the Julia community so take my word for what it is worth. - Optimizing Julia code is a joy. However, learning how to optimize Julia code not straightforward. If you are coming from Python and/or don't have experience thinking about memory, cache lines, references, mutability etc, you have your work cut out for you in terms of learning how to optimize Julia code. In addition to that, there are Julia specific things you need to learn to know how to optimize your code. Do you know what the function barrier paradigm is? No? Too bad, now your codebase is 10x slower and refactoring could take weeks. And that's just the theory of everything you need to learn. There's SO many subtle ways your Julia code can be slow because the compiler wasn't able to "see through your code". And the tooling here is getting better but still has a LOONNNGGG way to go. Statically being able to check and assert for problematic inferences will improve this for me a la JET.jl but right now JET.jl is too slow to run on a large codebase. - Thinking with Multiple Dispatch (MD) is much like Thinking with Portals. Once you get it, you have this ah-ha moment. But the type system is overloaded in my opinion. You HAVE to use the type system for MD but people also use it for interfaces (AbstractArray for example). I think adding inheritance in the abstract type system was a mistake, and a trait or interface like approach would be way better for this. Maybe something like concrete types for dispatch and abstract types for interfaces? I don't think this will EVER change though, not in Julia 2.0 or 3.0 or later, because it is SO ingrained into the Julia community. I'm not explaining this well here but I've complained about it before in previous comments on HN and am too lazy to go find it and copy paste :) - There's a number of minor syntax / usability gripes I have that I don't think will ever be fixed as well. I generally think a programming language should incentivize you to "do the right thing", often my making it easier to type. In Julia this framework of thinking exists but isn't applied consistently. It is easier to create a immutable struct than a mutable struct struct Immutable x::Int y::Int end # vs mutable struct Mutable x::Int y::Int end However, if you want to use it to store user data, if you choose immutable structs, your interface for users is EXTREMELY annoying. For example, if they want to update `x` from `1` to be `2`. im = Immutable(1, 3) im = Immutable(2, im.y) With mutable structs: m = Mutable(1, 3) m.x = 2 There's third party packages that make this easier but this should ABSOLUTELY be in Base. There's similar complaints I have about type names in Julia. I'm incentivized to write `::String` instead of `::AbstractString`, `::Int` instead of `::Integer`. In Julia using `AbstractString` is almost always preferred. The naming is also quite annoying. Why does `AbstractString` have `Abstract` in the name but `Integer` not, when both of them are abstract types? I've said this before and I'll say it again. I think Julia core devs should have a usability expert come in and review their whole codebase and workflows and make suggestions. I have no idea how Rust has nailed this so well. In Rust, so many things are just consistent. You can guess what the names or behavior of what you want so often, it's awesome. TLDR: If you are thinking of using Julia for a large production codebase, wait 5 more years. I've learnt that the hard way. For personal projects it is amazing though.
the__alchemist 4y ago
I wanted to like Julia, but have been unable to. If I want fast numerical/scientific code, I have Rust. If I want to prototype numerical algorithms, plot things, prototype, REPL etc, I have Python. I was hoping Julia could replace the latter, but it's too slow-to-compile; need fast iteration. Julia's numerical syntax is unbeaten. I wish other languages would adopt it.
- adgjlsfhk1 4y ago
  If compile time is a major bottleneck and you want to use Julia, I highly recommend using -O1. Julia uses -O2 by default which is faster, but has a quite notable compile time impact (often 2x or so).
  - cbkeller 4y ago
    Latency / "ttfx" for all sorts of things has also dropped dramatically over the past ~year, and will get another big boost with the native code caching PR
  - xchkr1337 4y ago
    Why don't they just add an interpreter and only compile when needed, like V8 does?
    - goerz 4y ago
      "just"
    - adgjlsfhk1 4y ago
      Julia actually already has an interpreter that it uses for some stuff (like code in the global scope). adding more of a teired jit approach is on the Todo list, but it's a very large project.
    - syockit 4y ago
      It is already doing what V8 does. It's only compiling when needed. The problem is when you start to put in too many things in the startup script, which is going to compile the things it says it "needs", even though you may never use when running.
MegaSec 4y ago
I love Julia, for reasons mainly covered in this post. The functional features are also fantastic.
klabb3 4y ago
Curious bystander here. Is there a cult follower on HN who can speak to the benefits of multiple dispatch, practically and compared to other languages? I know the sales pitch but I’m curious in particular about which practical coding problems and abstractions become obsolete with MD. It looks really promising, like “the way things were always supposed to be”, but I haven’t yet developed a full and intuitive understanding of what it means.
- cmcaine 4y ago
  I like it a lot even though almost all of my functions have no dispatch (only one implementation) or single dispatch (implementation differs based on the type of just one of the arguments). Firstly I like the aesthetic and implications of f(x, y, z) over x.f(y, z). I like that f is its own thing and not a property of x. Secondly, it's really nice to be able to reach however far down the callstack you need to go to patch some function "owned" by someone else to act correctly or more efficiently with whatever your type is. You can get correct code most of the time with single dispatch and well-thought-out interfaces, but getting interfaces right in advance is really tricky and requires coordination with other users of the interface whereas multiple dispatch can often work well without much coordination and can also handle cases where you want the implementation to vary dramatically based on the type (the OneHotVector in Karpinski's "Unreasonable effectiveness of multiple dispatch" talk is an example of this).
- Polygator 4y ago
  Have you seen the Unreasonable Effectiveness of Multiple Dispatch talk on YouTube? It's pretty good if you have the time
  - klabb3 4y ago
    Yes, but I should probably watch it again. Unfortunately it seems most people come from a mathematical angle, so most examples and references are not intuitive to grok for me. I am mostly curious about the implications for general purpose software development.
- socialdemocrat 4y ago
CoreyFieldens 4y ago
Everytime Julia is mentioned on HN, I see a surprising amount of people who dislike the language for whatever reason. I understand a lot of their concerns (time to first plot, debugging sucks, IDE support isn't amazing yet). However, I don't see a lot of alternatives for the niche that Julia occupies. If you want to do high performance scientific computing, there aren't a lot of options in terms of languages. Python is the de facto but it's so slow for anything that can't be well represented as vectorized NumPy operations. There are ways around that like Numba, Jax, Cython, etc. but their use cases are pretty limited, and they don't work well with other Python packages. There is, of course, C and C++ which are commonly used to speed up Python or as standalone packages. However, C++ is such a complicated beast that writing performant and correct code takes forever. C is much more manageable, but I find that there are not a lot of scientific packages written in pure C. This isn't even touching on the horrendous build system that is CMake. Fortran is a pretty simple looking language and would probably be the closest to Julia in terms of speed and expressiveness, but the writing is on the wall and Fortran's days are numbered. I am not aware of many new packages being developed using it. Other than that, there's languages like Rust and Go but those have ecosystems that are so small, they make Julia's ecosystem look like Python's. I really don't want to spend my time as a grad student writing basic numerical libraries from scratch.
- ska 4y ago
  > but the writing is on the wall and Fortran's days are numbered. They've been saying this since the late 1980s. Not that I think it's particularly lively, mind.
  - eesmith 4y ago
    For fun, I looked for even earlier examples. Here's a couple: From "The Handbook of Computers and Computing", by Arthur H. Seidman and Ivan Flores, 1984, https://archive.org/details/handbookofcomput00seid/page/342/mode/2up?q=dead https://archive.org/details/handbookofcomput00seid/page/342/... : > For many years, it has been popular to predict that FORTRAN soon will be a dead language, to be replaced by a "better" language. Despite the undeniable fact that there are more eloquent, rich and powerful languages available, FORTRAN continues to be used widely and, indeed, is still the most popular programming language for scientific and engineering applications. From NASA Conference Publication 2055, Engineering and Scientific Data Management, 1978,https://archive.org/details/NASA_NTRS_Archive_19780025833/page/n175/mode/2up?q=dead https://archive.org/details/NASA_NTRS_Archive_19780025833/pa... > Margaret White: ... I know FORTRAN is essentially a dead language, but there is a lot of FORTRAN around. Would you care to respond? > Jim Browne: Is there anyone from IBM who would care to respond? The microphone is yours. Who is it? How many times has FORTRAN been buried?
chenzhekl 4y ago
For me, Julia lags in deep learning compared to Python and lacks many valuable packages like PyTorch and PyG. Another reason that stops me from adopting Julia is that it lacks good learning resources. I can grasp Python within an afternoon. But the same thing is pretty hard for Julia.
nixpulvis 4y ago
"Multithreading is easy" Famous last words.
- adgjlsfhk1 4y ago
  Especially for scientists, it often is. Embarrassingly parallel is the norm. Multithreading is only actually hard when you have significant interaction between the threads.
- jakobnissen 4y ago
  Hah, that's funny. Actually, I had to stop abandon a Julia package of mine because I just couldn't figure out how to debug some threading issues. What I meant was that, when multithreading is hard in Julia, it's not Julia that makes it hard. Julia gives you exactly all the tools you need, easily available. It's that the problem is hard, i.e. you fuck it up even with good tools available. In my work though, problems tend to be simple to parallelize.
jweir 4y ago
I started to use Julia to reply to a question on Twitter with a full program. I tried Ruby first but it was just a bit too long. Julia fit the ticket. I could write a simple simulation that was understandable inside the Tweet.
ChrisRackauckas 4y ago
Thanks for sharing. Being a developer of a lot of libraries, it's easy to spend every day just focused on what's bad right now. Indeed, that's what you do because that's what needs to get fixed! But it's nice to take a step back every once in awhile and see what has been accomplished. I think there's a long ways to go still, but there is a lot of good in there. Thanks for taking the time to highlight it.
college_physics 4y ago
when choosing a foreign language to learn most normal people would not examine which one has the most elegant grammar, the most performant representation of information or any such abstract design elements. people ask instead: whom will I be able to communicate with. what kind of cultural repository (wealth) do I get access to. how will I benefit to justify spending the limited opportunities I have to reprogram my brain. the programmer-to-programmer aspect of computer languages is not appreciated enough, especially not in the modern, highly networked and open source way of developing software. yes, the primary purpose is to marshal ones and zeros in silicon chips and it does matter if the language helps you do that in a sane way but this is just one of the many factors people consider. I think, unfortunately for Julia and other aspiring challengers, right now the primary social network dynamics among developers is "winner takes all". e.g., its not a deep secret that the meteoric rize of python is because it enabled countless people to aspire to be part of the perceived AI/ML/FAANG gold rush. Over time programmer eyeballs motivate investment in ecosystem evolution and a benign spiral is set in motion. I don't have a crystal ball as to when/if/how the current pyfever might cool down. You can't predict those things, they are an emergent property of our very complex networks. Maybe some killer feature or julia or rust or go or dart or kotlin will trigger some regime change, but unless it does, any discussions of alternate greatness have a distinct detached feeling to them.
- ssivark 4y ago
  > people ask instead: whom will I be able to communicate with. what kind of cultural repository (wealth) do I get access to. how will I benefit to justify spending the limited opportunities I have to reprogram my brain. Choosing the lowest common denominator language to be able to communicate with the “most number of people” is a specific bias (nothing wrong with it). People pick languages with many different motivations — something might sound/read elegant, or there’s a specific group of people they want to engage with (Eg: anime enthusiasts, kernel developers, statisticians, etc.) > I think, unfortunately for Julia and other aspiring challengers, right now the primary social network dynamics among developers is "winner takes all". Only for certain use cases. Between Python and Julia, there’s exactly one language I want to program in, and will strongly prefer every time I can get away with it. I don’t want to diss on Python — its ecosystem/workflow is a substantial improvement over the previous era, but it has so many warts (for certain fundamental needs, Eg generic programming) that you can never fix the problem “additively” by extending the ecosystem instead of radically redesigning the language ground up.
lukego 4y ago
I'm programming in Julia today and really enjoying it. Julia is the language that spares me from reaching for Python. I appreciate that. It doesn't replace all the other languages in my quiver but nor does it have to. (If I compare Julia with Lisp or R/tidyverse/ggplot2 then frustrations emerge but "doctor doctor it hurts when I do this.")
m_nyongesa 4y ago
I'd like to point out two things I _don't_ like about Julia that seem to be idiosyncratic but nevertheless matter to me: 1. Rather than use something like reStructuredText or Texinfo they used Markdown, and then of course had to define a bunch of custom additional stuff to make it work for documentation, plus a custom program to publish the documentation to a limited number of formats. Unlike the two documentation languages I mentioned, the Juila "customized Markdown" isn't publishable to Info, so it can't be used in Emacs: rather, it's basically just a bunch of web pages. 2. Julia is completely dependent on LLVM. Even Rust (which was initially like that) now has a GCC-based implementation.
- sundarurfriend 4y ago
  Regarding 1., Markdown is much more accessible to the average person, especially the average programmer, than the formats you mention. Markdown is basically becoming a common-knowledge thing where if a person is at least somewhat tech-savvy, you can assume they know at least some basic Markdown.
  - m_nyongesa 4y ago
    My point was that the Markdown format itself is not complete enough for the task at hand i.e. making documentation. So all the people involved have to 1) learn all the customized extensions specific to this one project (and remember to differentiate them from the other custom versions for other projects, e.g. Rust's one), and 2) learn a custom deployment system. I'd rather just learn one thing and use it for many different projects.
- mbauman 4y ago
  It's funny, Julia used to use reStructuredText and I could _never_ get the syntax right when doing doc changes. Markdown is significantly more accessible in the common case of just writing prose and code examples. Why do you care about LLVM?
  - m_nyongesa 4y ago
    Interesting. I've heard that complaint before and I'm not sure how to address it since I have only used reStructuredText in what are likely smaller projects. I think it's strange for a language to absolutely rely on the architecture of one compiler. Ideally it should have at least two that are both under FLO (free/libre/open) licenses. Regarding LLVM specifically, see here: https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html
RivieraKid 4y ago
I used to really like Julia but over time have heavily moved to the view that my ideal general-purpose programming language would look a lot like Swift, perhaps with some bits of Julia, e.g. the REPL. Julia doesn't have a good support for OOP. I don't think FP is the optimal way to solve all possible programming tasks. Usually a mix of both approaches leads to the most simple, maintainable and readable code. And I'm really not sold on multiple dispatch. In Swift, I would simply implement the join function by adding an extension on `Array<String>`. And the + function would just be, for example, `static func + (left: Vector2D, right: Vector2D) -> Vector2D`. I've never come across a situation where I wished Swift would support multiple dispatch. On the other hand, the fact that Julia doesn't use the object.method() has 2 very clear drawbacks: lack of completion in an IDE and poor readability (example: `object.doSomething(a, b, c).doSomethingElse(a, b, c)` - imagine how would this look in Julia).
- m_nyongesa 4y ago
  I don't understand what the Julia language offers over for example OCaml, which has a solid type system yet also has a REPL as well as a scientific computing library: https://ocaml.xyz/ https://ocaml.xyz/ https://ocaml.xyz/docs/ https://ocaml.xyz/docs/
  - galangalalgol 4y ago
    Performance (c-like is stretching it, but not by much) and existing libraries for everything I can imagine.
  - dunefox 4y ago
    Usable strings come to mind.
- galangalalgol 4y ago
  doSomethingElse( doSomething( object, a, b, c), a, b, c) Not that bad is it? I think I like it better actually, especially if a b and c had variable names that were longer
xyzzy4747 4y ago
Just use Rust. Enough said.
winstonprivacy 4y ago
>I don't know much about the intricasies of multithreading, so I couldn't tell you if Julia's approach to multithreading is groundbreaking or well designed. What I can tell you, is that in Julia, it is so easy to use multiple threads effectively, that even though I don't feel that confident writing complex multithreaded code, most my performance sensitive scripts are multithreaded where it's obvious to do so. Threading may be easy but the approach they are taking is not very performant for various hardware-related reasons.
- sundarurfriend 4y ago
  What do you mean by that? Could you give specifics?

198 points by jakobnissen 4y ago

aswanson 4y ago

The core language is unstable Welp. Im out.

Tarrosion 4y ago
I don't see that anywhere in the post - was that in a previous version, or somewhere else, or your summary? This is surprising, because the Julia devs have been very careful to maintain backwards compatibility since version 1.0 released in 2018.
- mrtweetyhack 4y ago
- celrod 4y ago
  I recently wanted to run some Python benchmarks, and was surprised to find that some major Python packages (i.e. Numba) didn't work on the latest Python release. In Julia, all open source packages that pass tests on the latest release are confirmed to also pass on a release candidate before that candidate can become the next release. A major package being incompatible with a new Julia version just doesn't happen. Julia takes its stability guarantees seriously.
  - ChrisRackauckas 4y ago
    Indeed. There's a nice example from yesterday where someone asked about whether anyone is planning to update ParallelDataTransfer.jl because it's so old (last update August 2018) that it doesn't have any of the modern package development features that became standard post v1.0. But I was like, that doesn't mean it's not working... Julia is stable. And indeed if you run it, it still passes tests on Julia v1.8, more than 4 years later. That's a testimony of just how stable post-v1.0 has been. And mind you, this is a library of tooling for distributed computing, so it's touching that is considered a deeper feature. Source: https://discourse.julialang.org/t/discontinuation-of-paralleldatatransfer-jl/91294 https://discourse.julialang.org/t/discontinuation-of-paralle...

ubj 4y ago

Great writeup. Minor comment about the portion of the post mentioning Conda being glacially slow: Mamba [1] is a much better drop-in replacement written in C++. Not only is it significantly faster, but error messages are much more sane and helpful. That being said, I do agree that Pkg.jl is much more sleek and modern than Conda/Mamba. [1]: https://github.com/mamba-org/mamba https://github.com/mamba-org/mamba

modriano 4y ago
Conda should have set the default for channel_priority to strict a while ago, it significantly reduces the search space [0], and it reduces the chances of the solver finding a poorly-specified-yet-nominally-compatible package build on some less rigorous channel. With strict channel_priority and conda-forge as my priority channel, it hasn't taken more than maybe a minute for to solve any dependencies (assuming the target packages are on the priority channel) for any of my own envs, although when I try to recreate envs that installed packages from many channels, I have experienced some long waits. [0] https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/conda-performance.html https://docs.conda.io/projects/conda/en/latest/user-guide/co...
- adgjlsfhk1 4y ago
  A minute is still pretty long to just resolve version IMO.

eigenspace 4y ago

Nice post Jakob. I almost universally agree with the points here, especially the ones about the joy of optimizing Julia code.

clumsysmurf 4y ago

If one wanted to learn Julia, where is the best place to start? I looked at https://julialang.org/learning/books/ https://julialang.org/learning/books/ For new programming language XXX I look for a book like the "K&R for XXX". I see some older ones from Packt, but nothing like the official Rust Book, for example. There is "Think Julia" (OReilly) but its older.

mxkopy 4y ago
The way I learn new languages nowadays is 1. Look at example 'Hello world' code 2. Attempt a problem on Project Euler 3. Look at docs/source code to get what I'm missing 4. Repeat Julia docs are good for step 3. I don't think there are many super technical books like the one you're looking for, since Julia doesn't really have an industry that would produce them, and since the core is still being developed and all that.
agucova 4y ago
For experienced programmers, I usually recommend: 0. Watching this [0] Fireship video to get the “big picture” on the language. 1. Reading the “Noteworthy Differences from other Languages” [1] section of the manual, if your language is on the list. 2. Then, if you're hurried, read Learn Julia in Y Minutes [2], or otherwise read the official manual [3] in order, skipping sections you're not interested in. In case you're interested in scientific computing specifically, you can start from Chris Rackauckas' course on Parallel Computing and Scientific Machine Learning [4]. And if you don't have a straightforward application to test Julia on while learning, I would recommend doing the exercises available in Exercism [5], which are well-made and provide access to awesome mentors. As for books, Think Julia is pretty good imho, even if it's a little bit outdated. [0]: https://www.youtube.com/watch?v=JYs_94znYy0 https://www.youtube.com/watch?v=JYs_94znYy0 [1]: https://docs.julialang.org/en/v1/manual/noteworthy-differences/#Noteworthy-differences-from-MATLAB https://docs.julialang.org/en/v1/manual/noteworthy-differenc... [2]: https://learnxinyminutes.com/docs/julia/ https://learnxinyminutes.com/docs/julia/ [3]: https://docs.julialang.org/en/v1/manual/getting-started/ https://docs.julialang.org/en/v1/manual/getting-started/ [4]: https://www.youtube.com/watch?v=-lJK92bEKow&list=PLCAl7tjCwWyGjdzOOnlbGnVNZk0kB8VSa&index=2 https://www.youtube.com/watch?v=-lJK92bEKow&list=PLCAl7tjCwW... [5]: https://exercism.org/tracks/julia https://exercism.org/tracks/julia

UncleOxidant 4y ago

Agree with all of these points. Multiple Dispatch takes a bit of getting used to, but once you get it it just makes a lot of sense and allows for an amazing amount of code-reuse. And, yes, Julia's REPL is sooo much nicer to use than Python's - I always kind of cringe when I've gotta go back and use the Python REPL as it's so primitive by comparison. You can even tab-complete filenames in the current directory in the Julia REPL. Say you want to open a file called "example.log": julia> open("exam<TAB> will give you: julia> open("example.log"

cdavid 4y ago
It is not builtin, but ipython will give you that and most features mentioned in the article.
- maegul 4y ago
  Yea. The comparison with the Python REPL makes me distrust this post a little. Any Python user who’d be interested in using Julia is or should be familiar with ipython. (If you’re not, it’s a better REPL originally made to make iterative scientific like programming easier in Python, made by the same person/people behind jupyter, which was originally called the ipython notebook.) Yes Python prides itself on its standard library and it’s be nice to have a better standard REPL. If this were the point being made I’d appreciate the post more. But, Python is a large and diverse ecosystem, so having different tools coming out of different domains all sharing the same language is part of the value, so it’s not the most hard hitting critique of Python. That the author made such a point of this, in my eyes, make them seem a little too keen to dunk in Julia’s major “big-brother” competitor rather than being as fair and accurate as they can. Though, I haven’t read their previous Julia-critical post, so I may very well be overreacting. Still, use ipython.
  - sundarurfriend 4y ago
    > Any Python user who’d be interested in using Julia is or should be familiar with ipython. I would have assumed so too, but the number of (reasonably competent) Python programmers who are shocked to know there are alternate REPL interfaces would suggest otherwise. I was lucky enough to get into Python when these thing were still new and shiny, so I came across ipython/bpython pretty early on. But nowadays the very fact that ipython is well-established means that people don't talk about it as much, assuming everyone knows about it, so it's very much possible that someone comes across news about Julia (which is still "new and shiny" enough to be in the news) and doesn't know about ipython. Defaults matter, and are the only thing used by a large segment of users, even in today's information-rich and one-tap-install world.

Volker_W 4y ago

Shameless plug: I wrote about what I think is bad about Julia: https://weissmann.pm/julialang/ https://weissmann.pm/julialang/

adgjlsfhk1 4y ago
As someone who really likes Julia, I agree with almost all of this. The good news is that a lot of these areas are getting active improvements.
ChrisRackauckas 4y ago
The error messages you mentioned in here have been completely overhauled. In fact, most things in SciML are now caught and throw very high level error messages. We also revamped the whole documentation and added docstrings everywhere. See https://sciml.ai/news/2022/10/08/error_messages/ https://sciml.ai/news/2022/10/08/error_messages/ . We're also in the middle of rolling out a new documentation (https://docs.sciml.ai/Overview/stable/ https://docs.sciml.ai/Overview/stable/) that has a lot more of a split between tutorials and references. It's not complete, but the core push of this should be completed in about 2 weeks. As for loading times, we've transformed those as documented in https://sciml.ai/news/2022/09/21/compile_time/ https://sciml.ai/news/2022/09/21/compile_time/ (taking a core case from 30 seconds to 0.1 seconds), and Julia v1.9 is releasing a feature where package precompilation can store LLVM-compiled binaries. So I think most of the blog post has already been addressed? The one thing we haven't done is improved type printing. I am with you on that one, and actually opened a Base Julia issue about it way before your blog post: https://github.com/JuliaLang/julia/issues/36517 https://github.com/JuliaLang/julia/issues/36517 . It requires a Base Julia fix though, so that's a bit out of my hands. Also, I think it would be good for Base Julia to do a bit of the error message interpreting that SciML has done, specifically for broadcast (https://github.com/JuliaLang/julia/issues/45086 https://github.com/JuliaLang/julia/issues/45086). So there are some more improvements to be done, but I don't think the blog post is up-to-date given the overhauls that were done in the summer of 2022 (thanks to your feedback). It would be nice to hear updated thoughts when you have a chance to try all of these improvements (especially when v1.9 comes out with the cached binaries)!
- 4y ago

jostmey 4y ago

I loved the early iterations of Julia. It was everything I wanted… fast, simple, and readable. Somehow the language has become less simple and readable to the point I don’t recommend it anymore

canjobear 4y ago

As someone who has used and contributed to Julia, I find Yuri Vishnevsky's arguments about correctness totally fatal [0]. And Yuri's examples are not obscure, they are totally realistic scenarios where Julia silently returns wrong results in ways that may be hard to detect. I do mostly scientific computing, and the idea that I might have to retract a paper because of a bug in the programming language is intolerable. It doesn't matter how beautiful and fun to write and develop the language is if it can't be trusted to return correct results. [0] https://yuri.is/not-julia/ https://yuri.is/not-julia/

Joel_Mckay 4y ago
If I recall, the same argument was used to justify Octave's Fortran coded libraries for stats. Primarily, it was an argument about historical consistency in the assumptions people agreed upon at NASA. Julia's library compatibility is still an issue, but hardly related to the language itself. Unlike many languages, Julia has regression testing for its graphical plotting output. This means it can and usually does check that a given output matches a previously known function(s) output across each release iteration. This means that unlike many languages that fix/ignore various external library versions, Julia actually checks that data gives the exact same results every time. The caveat is that people must report issues to the project, or add regression tests to ensure correctness persists throughout the ecosystem. =)
teruakohatu 4y ago
This undated blog post (published in about May this year) is not the last word on Julia. There have been fixes made to issues brought up. Julia's authors get credit for trying to rewrite many core compute/LA libraries from scratch in a composable manner rather than using ancient fortran code nobody dares touch. That said, the article was a good wake up call to the community that tests and correctness is vital for trust. Edit: First paragraph removed as the person I referred to disagrees with me and asked me to make an edit.
- fhoituwoeir324 4y ago
  >... using ancient fortran code nobody dares touch. Only the BLAS/LAPACK reference implementation are in F77. Intel MKL, OpenBLAS, ATLAS and other are all in a mix of C and ASM.

blindseer 4y ago

> A better catchphrase for Julia might be "The best expressiveness / performance tradeoff you have ever seen". Man, Jakob just has a way of writing that gets right to the point. Nice post. My only complaint about the post is that in Python you have many different REPL options. For example, both ipython and bpython are miles ahead of the Julia REPL. I agree though that the Julia default REPL is better than the Python default REPL. I particularly like the shell mode in Julia. You can also make your own modes, like a sql mode or any custom DSL mode. I have been very critical about Julia in the past, so I'll say some positive things before I complain more :) - The package management in Julia is god-like. Specifically, there's a whole subset of packages that are just binaries and libraries cross compiled on VMs for Windows / Mac / Linux + x86 / x64 / ARM, and it just works. There's no more trying to compile code on a users computer when trying to install a package, it's beautiful. It is truly a phenomenal piece of engineering, and I cannot praise it enough. Hats off to the core team responsible for this. - Multithreading is such a joy to use. Compared to any other dynamic GC language, Julia and Go are pretty much up there in terms of usability + features. So much better than Python or R. But while I prefer Julia over Go, I do prefer Rust over Julia. Now for some of my grievances. I'm a nobody in the Julia community so take my word for what it is worth. - Optimizing Julia code is a joy. However, learning how to optimize Julia code not straightforward. If you are coming from Python and/or don't have experience thinking about memory, cache lines, references, mutability etc, you have your work cut out for you in terms of learning how to optimize Julia code. In addition to that, there are Julia specific things you need to learn to know how to optimize your code. Do you know what the function barrier paradigm is? No? Too bad, now your codebase is 10x slower and refactoring could take weeks. And that's just the theory of everything you need to learn. There's SO many subtle ways your Julia code can be slow because the compiler wasn't able to "see through your code". And the tooling here is getting better but still has a LOONNNGGG way to go. Statically being able to check and assert for problematic inferences will improve this for me a la JET.jl but right now JET.jl is too slow to run on a large codebase. - Thinking with Multiple Dispatch (MD) is much like Thinking with Portals. Once you get it, you have this ah-ha moment. But the type system is overloaded in my opinion. You HAVE to use the type system for MD but people also use it for interfaces (AbstractArray for example). I think adding inheritance in the abstract type system was a mistake, and a trait or interface like approach would be way better for this. Maybe something like concrete types for dispatch and abstract types for interfaces? I don't think this will EVER change though, not in Julia 2.0 or 3.0 or later, because it is SO ingrained into the Julia community. I'm not explaining this well here but I've complained about it before in previous comments on HN and am too lazy to go find it and copy paste :) - There's a number of minor syntax / usability gripes I have that I don't think will ever be fixed as well. I generally think a programming language should incentivize you to "do the right thing", often my making it easier to type. In Julia this framework of thinking exists but isn't applied consistently. It is easier to create a immutable struct than a mutable struct struct Immutable x::Int y::Int end # vs mutable struct Mutable x::Int y::Int end However, if you want to use it to store user data, if you choose immutable structs, your interface for users is EXTREMELY annoying. For example, if they want to update `x` from `1` to be `2`. im = Immutable(1, 3) im = Immutable(2, im.y) With mutable structs: m = Mutable(1, 3) m.x = 2 There's third party packages that make this easier but this should ABSOLUTELY be in Base. There's similar complaints I have about type names in Julia. I'm incentivized to write `::String` instead of `::AbstractString`, `::Int` instead of `::Integer`. In Julia using `AbstractString` is almost always preferred. The naming is also quite annoying. Why does `AbstractString` have `Abstract` in the name but `Integer` not, when both of them are abstract types? I've said this before and I'll say it again. I think Julia core devs should have a usability expert come in and review their whole codebase and workflows and make suggestions. I have no idea how Rust has nailed this so well. In Rust, so many things are just consistent. You can guess what the names or behavior of what you want so often, it's awesome. TLDR: If you are thinking of using Julia for a large production codebase, wait 5 more years. I've learnt that the hard way. For personal projects it is amazing though.

the__alchemist 4y ago

I wanted to like Julia, but have been unable to. If I want fast numerical/scientific code, I have Rust. If I want to prototype numerical algorithms, plot things, prototype, REPL etc, I have Python. I was hoping Julia could replace the latter, but it's too slow-to-compile; need fast iteration. Julia's numerical syntax is unbeaten. I wish other languages would adopt it.

adgjlsfhk1 4y ago
If compile time is a major bottleneck and you want to use Julia, I highly recommend using -O1. Julia uses -O2 by default which is faster, but has a quite notable compile time impact (often 2x or so).
- cbkeller 4y ago
  Latency / "ttfx" for all sorts of things has also dropped dramatically over the past ~year, and will get another big boost with the native code caching PR
- xchkr1337 4y ago
  Why don't they just add an interpreter and only compile when needed, like V8 does?
  - goerz 4y ago
    "just"
  - adgjlsfhk1 4y ago
    Julia actually already has an interpreter that it uses for some stuff (like code in the global scope). adding more of a teired jit approach is on the Todo list, but it's a very large project.
  - syockit 4y ago
    It is already doing what V8 does. It's only compiling when needed. The problem is when you start to put in too many things in the startup script, which is going to compile the things it says it "needs", even though you may never use when running.

MegaSec 4y ago

I love Julia, for reasons mainly covered in this post. The functional features are also fantastic.

klabb3 4y ago

Curious bystander here. Is there a cult follower on HN who can speak to the benefits of multiple dispatch, practically and compared to other languages? I know the sales pitch but I’m curious in particular about which practical coding problems and abstractions become obsolete with MD. It looks really promising, like “the way things were always supposed to be”, but I haven’t yet developed a full and intuitive understanding of what it means.

cmcaine 4y ago
I like it a lot even though almost all of my functions have no dispatch (only one implementation) or single dispatch (implementation differs based on the type of just one of the arguments). Firstly I like the aesthetic and implications of f(x, y, z) over x.f(y, z). I like that f is its own thing and not a property of x. Secondly, it's really nice to be able to reach however far down the callstack you need to go to patch some function "owned" by someone else to act correctly or more efficiently with whatever your type is. You can get correct code most of the time with single dispatch and well-thought-out interfaces, but getting interfaces right in advance is really tricky and requires coordination with other users of the interface whereas multiple dispatch can often work well without much coordination and can also handle cases where you want the implementation to vary dramatically based on the type (the OneHotVector in Karpinski's "Unreasonable effectiveness of multiple dispatch" talk is an example of this).
Polygator 4y ago
Have you seen the Unreasonable Effectiveness of Multiple Dispatch talk on YouTube? It's pretty good if you have the time
- klabb3 4y ago
  Yes, but I should probably watch it again. Unfortunately it seems most people come from a mathematical angle, so most examples and references are not intuitive to grok for me. I am mostly curious about the implications for general purpose software development.
socialdemocrat 4y ago

CoreyFieldens 4y ago

Everytime Julia is mentioned on HN, I see a surprising amount of people who dislike the language for whatever reason. I understand a lot of their concerns (time to first plot, debugging sucks, IDE support isn't amazing yet). However, I don't see a lot of alternatives for the niche that Julia occupies. If you want to do high performance scientific computing, there aren't a lot of options in terms of languages. Python is the de facto but it's so slow for anything that can't be well represented as vectorized NumPy operations. There are ways around that like Numba, Jax, Cython, etc. but their use cases are pretty limited, and they don't work well with other Python packages. There is, of course, C and C++ which are commonly used to speed up Python or as standalone packages. However, C++ is such a complicated beast that writing performant and correct code takes forever. C is much more manageable, but I find that there are not a lot of scientific packages written in pure C. This isn't even touching on the horrendous build system that is CMake. Fortran is a pretty simple looking language and would probably be the closest to Julia in terms of speed and expressiveness, but the writing is on the wall and Fortran's days are numbered. I am not aware of many new packages being developed using it. Other than that, there's languages like Rust and Go but those have ecosystems that are so small, they make Julia's ecosystem look like Python's. I really don't want to spend my time as a grad student writing basic numerical libraries from scratch.

ska 4y ago
> but the writing is on the wall and Fortran's days are numbered. They've been saying this since the late 1980s. Not that I think it's particularly lively, mind.
- eesmith 4y ago
  For fun, I looked for even earlier examples. Here's a couple: From "The Handbook of Computers and Computing", by Arthur H. Seidman and Ivan Flores, 1984, https://archive.org/details/handbookofcomput00seid/page/342/mode/2up?q=dead https://archive.org/details/handbookofcomput00seid/page/342/... : > For many years, it has been popular to predict that FORTRAN soon will be a dead language, to be replaced by a "better" language. Despite the undeniable fact that there are more eloquent, rich and powerful languages available, FORTRAN continues to be used widely and, indeed, is still the most popular programming language for scientific and engineering applications. From NASA Conference Publication 2055, Engineering and Scientific Data Management, 1978,https://archive.org/details/NASA_NTRS_Archive_19780025833/page/n175/mode/2up?q=dead https://archive.org/details/NASA_NTRS_Archive_19780025833/pa... > Margaret White: ... I know FORTRAN is essentially a dead language, but there is a lot of FORTRAN around. Would you care to respond? > Jim Browne: Is there anyone from IBM who would care to respond? The microphone is yours. Who is it? How many times has FORTRAN been buried?

chenzhekl 4y ago

For me, Julia lags in deep learning compared to Python and lacks many valuable packages like PyTorch and PyG. Another reason that stops me from adopting Julia is that it lacks good learning resources. I can grasp Python within an afternoon. But the same thing is pretty hard for Julia.

nixpulvis 4y ago

"Multithreading is easy" Famous last words.

adgjlsfhk1 4y ago
Especially for scientists, it often is. Embarrassingly parallel is the norm. Multithreading is only actually hard when you have significant interaction between the threads.
jakobnissen 4y ago
Hah, that's funny. Actually, I had to stop abandon a Julia package of mine because I just couldn't figure out how to debug some threading issues. What I meant was that, when multithreading is hard in Julia, it's not Julia that makes it hard. Julia gives you exactly all the tools you need, easily available. It's that the problem is hard, i.e. you fuck it up even with good tools available. In my work though, problems tend to be simple to parallelize.

jweir 4y ago

I started to use Julia to reply to a question on Twitter with a full program. I tried Ruby first but it was just a bit too long. Julia fit the ticket. I could write a simple simulation that was understandable inside the Tweet.

ChrisRackauckas 4y ago

Thanks for sharing. Being a developer of a lot of libraries, it's easy to spend every day just focused on what's bad right now. Indeed, that's what you do because that's what needs to get fixed! But it's nice to take a step back every once in awhile and see what has been accomplished. I think there's a long ways to go still, but there is a lot of good in there. Thanks for taking the time to highlight it.

college_physics 4y ago

when choosing a foreign language to learn most normal people would not examine which one has the most elegant grammar, the most performant representation of information or any such abstract design elements. people ask instead: whom will I be able to communicate with. what kind of cultural repository (wealth) do I get access to. how will I benefit to justify spending the limited opportunities I have to reprogram my brain. the programmer-to-programmer aspect of computer languages is not appreciated enough, especially not in the modern, highly networked and open source way of developing software. yes, the primary purpose is to marshal ones and zeros in silicon chips and it does matter if the language helps you do that in a sane way but this is just one of the many factors people consider. I think, unfortunately for Julia and other aspiring challengers, right now the primary social network dynamics among developers is "winner takes all". e.g., its not a deep secret that the meteoric rize of python is because it enabled countless people to aspire to be part of the perceived AI/ML/FAANG gold rush. Over time programmer eyeballs motivate investment in ecosystem evolution and a benign spiral is set in motion. I don't have a crystal ball as to when/if/how the current pyfever might cool down. You can't predict those things, they are an emergent property of our very complex networks. Maybe some killer feature or julia or rust or go or dart or kotlin will trigger some regime change, but unless it does, any discussions of alternate greatness have a distinct detached feeling to them.

ssivark 4y ago
> people ask instead: whom will I be able to communicate with. what kind of cultural repository (wealth) do I get access to. how will I benefit to justify spending the limited opportunities I have to reprogram my brain. Choosing the lowest common denominator language to be able to communicate with the “most number of people” is a specific bias (nothing wrong with it). People pick languages with many different motivations — something might sound/read elegant, or there’s a specific group of people they want to engage with (Eg: anime enthusiasts, kernel developers, statisticians, etc.) > I think, unfortunately for Julia and other aspiring challengers, right now the primary social network dynamics among developers is "winner takes all". Only for certain use cases. Between Python and Julia, there’s exactly one language I want to program in, and will strongly prefer every time I can get away with it. I don’t want to diss on Python — its ecosystem/workflow is a substantial improvement over the previous era, but it has so many warts (for certain fundamental needs, Eg generic programming) that you can never fix the problem “additively” by extending the ecosystem instead of radically redesigning the language ground up.

lukego 4y ago

I'm programming in Julia today and really enjoying it. Julia is the language that spares me from reaching for Python. I appreciate that. It doesn't replace all the other languages in my quiver but nor does it have to. (If I compare Julia with Lisp or R/tidyverse/ggplot2 then frustrations emerge but "doctor doctor it hurts when I do this.")

m_nyongesa 4y ago

I'd like to point out two things I _don't_ like about Julia that seem to be idiosyncratic but nevertheless matter to me: 1. Rather than use something like reStructuredText or Texinfo they used Markdown, and then of course had to define a bunch of custom additional stuff to make it work for documentation, plus a custom program to publish the documentation to a limited number of formats. Unlike the two documentation languages I mentioned, the Juila "customized Markdown" isn't publishable to Info, so it can't be used in Emacs: rather, it's basically just a bunch of web pages. 2. Julia is completely dependent on LLVM. Even Rust (which was initially like that) now has a GCC-based implementation.

sundarurfriend 4y ago
Regarding 1., Markdown is much more accessible to the average person, especially the average programmer, than the formats you mention. Markdown is basically becoming a common-knowledge thing where if a person is at least somewhat tech-savvy, you can assume they know at least some basic Markdown.
- m_nyongesa 4y ago
  My point was that the Markdown format itself is not complete enough for the task at hand i.e. making documentation. So all the people involved have to 1) learn all the customized extensions specific to this one project (and remember to differentiate them from the other custom versions for other projects, e.g. Rust's one), and 2) learn a custom deployment system. I'd rather just learn one thing and use it for many different projects.
mbauman 4y ago
It's funny, Julia used to use reStructuredText and I could _never_ get the syntax right when doing doc changes. Markdown is significantly more accessible in the common case of just writing prose and code examples. Why do you care about LLVM?
- m_nyongesa 4y ago
  Interesting. I've heard that complaint before and I'm not sure how to address it since I have only used reStructuredText in what are likely smaller projects. I think it's strange for a language to absolutely rely on the architecture of one compiler. Ideally it should have at least two that are both under FLO (free/libre/open) licenses. Regarding LLVM specifically, see here: https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html

RivieraKid 4y ago

I used to really like Julia but over time have heavily moved to the view that my ideal general-purpose programming language would look a lot like Swift, perhaps with some bits of Julia, e.g. the REPL. Julia doesn't have a good support for OOP. I don't think FP is the optimal way to solve all possible programming tasks. Usually a mix of both approaches leads to the most simple, maintainable and readable code. And I'm really not sold on multiple dispatch. In Swift, I would simply implement the join function by adding an extension on `Array<String>`. And the + function would just be, for example, `static func + (left: Vector2D, right: Vector2D) -> Vector2D`. I've never come across a situation where I wished Swift would support multiple dispatch. On the other hand, the fact that Julia doesn't use the object.method() has 2 very clear drawbacks: lack of completion in an IDE and poor readability (example: `object.doSomething(a, b, c).doSomethingElse(a, b, c)` - imagine how would this look in Julia).

m_nyongesa 4y ago
I don't understand what the Julia language offers over for example OCaml, which has a solid type system yet also has a REPL as well as a scientific computing library: https://ocaml.xyz/ https://ocaml.xyz/ https://ocaml.xyz/docs/ https://ocaml.xyz/docs/
- galangalalgol 4y ago
  Performance (c-like is stretching it, but not by much) and existing libraries for everything I can imagine.
- dunefox 4y ago
  Usable strings come to mind.
galangalalgol 4y ago
doSomethingElse( doSomething( object, a, b, c), a, b, c) Not that bad is it? I think I like it better actually, especially if a b and c had variable names that were longer

xyzzy4747 4y ago

Just use Rust. Enough said.

winstonprivacy 4y ago

>I don't know much about the intricasies of multithreading, so I couldn't tell you if Julia's approach to multithreading is groundbreaking or well designed. What I can tell you, is that in Julia, it is so easy to use multiple threads effectively, that even though I don't feel that confident writing complex multithreaded code, most my performance sensitive scripts are multithreaded where it's obvious to do so. Threading may be easy but the approach they are taking is not very performant for various hardware-related reasons.

sundarurfriend 4y ago
What do you mean by that? Could you give specifics?