12 ms·

Why We Use Julia, 10 Years Later

325 points by KenoFischer 5y ago

stellalo 5y ago
I first learned about Julia somewhere in 2013, I thought “damn, this looks really nice”, but never used it seriously until 2016 (v0.4). This language gives me joy, I never get tired of it.
antifarben 5y ago
I wish CrystalLang would gain some popularity and thus traction. It seems to be a good alternative between high level syntax and performance.
eigenspace 5y ago
I started using Julia in 2017, and as a physics student who saw Python, Mathematica, and Matlab as a series of tools that I had to pull out sometimes to solve specific problems, it came as a great shock to me that I was suddenly interested in Julia for it's own sake. It's not an overstatement to say that this language totally changed my relationship with computers and programming.
- cbkeller 5y ago
  That sounds about like my experience too, only s/physics/geology/ :)
komuher 5y ago
I can reflect on like past few years (like 1.5 year ago i was disappointed by julia lack of progres but a lot have changed). Julia is getting usable even in "normal" applications not only academic stuff, as person who come back after 1.5/2 years to julia i feel like i can use it again in my job cause it is a lot more stable at have a lot of new neat futures + CUDA.jl is amazing. I hope Julia team will still explore a bit more static type inference and full AOT compilation if language got full support for AOT it'll be a perfect deal for me :).
- ChrisRackauckas 5y ago
  StaticCompiler.jl is making huge strides. 12 days ago a rewrite was merged (https://github.com/tshort/StaticCompiler.jl/pull/46 https://github.com/tshort/StaticCompiler.jl/pull/46), and now the static compiler can allocate and use the runtime (https://github.com/tshort/StaticCompiler.jl/pull/58 https://github.com/tshort/StaticCompiler.jl/pull/58). I would still be weary of using it too much, but hopefully optimistic of its near future.
  - eigenspace 5y ago
    Yeah, it's definitely in the early stages still, but this time I think there's much more infrastructure, and more people around with the right knowledge to advise on StaticCompiler's development, that I'm currently feeling pretty good about it's future. Here's the feature roadmap https://github.com/tshort/StaticCompiler.jl/issues/59 https://github.com/tshort/StaticCompiler.jl/issues/59 that should help people understand what currently works and what I think I can reasonably accomplish eventually
appleiigs 5y ago
I'm hoping Julia gets its killer app that can launch it to the next level like Rails or Numpy. Julia has a lot of pleasantries, but not enough to pry me away from what I'm productive with. There's certain amount of switching cost that needs to be overcome.
- mbauman 5y ago
  We already have (at least) one: Differential Equations and SciML.
  - thetwentyone 5y ago
    ... plus Pluto, language-wide automatic differentiation, multiple dispatch, lispy macros...
    - earleybird 5y ago
      Pluto is that app for me coupled with a simple portable install. Installing on windows (workday I'm consigned to flames of woe) is simply a matter of downloading portable install .zip file, a simple startup .bat script[0], 'add Pluto', 'import Pluto' and finally 'Pluto.run()' I now have an Observable-like[1]notebook with all the Julialang goodness without running an installer [0] my julia.bat looks like: @echo off @REM see https://docs.julialang.org/en/v1/manual/environment-variables/ @REM %%1 is the project directory set JULIA_PROJECT=%1 set JULIA_DEPOT_PATH=%~dp0JULIA_DEPOT set JULIA_BINDIR=%~dp0julia-1.7.0\bin set PATH=%JULIA_BINDIR%;%PATH% %JULIA_BINDIR%\julia [1] https://observablehq.com/ https://observablehq.com/
- hiepph 5y ago
  Matrix operations are already built-ins in Julia. And it's such a pleasant to work with compared to the syntax of Numpy. People just don't want to get away from the familiar thing (i.e. Python). And I don't think making a web framework would be a focus of Julia since it was built with science and computing mindset. This might be cliché but use right tools for the job. I still use Ruby for web development and Julia for the science and machine learning stuffs (gradually moved from Python ecosystem).
cube2222 5y ago
I've been working through the Statistical Rethinking[0] course with Julia recently and so far the language has been really intuitive, same for the libraries (Turing, Distributions). And it's nice that you don't have to vectorize your code and can use normal for-loops. Also, the way dynamic dispatch + specialization work is beautiful. [0]:https://github.com/rmcelreath/stat_rethinking_2022 https://github.com/rmcelreath/stat_rethinking_2022
rnikander 5y ago
There is something elegant about having all functions at the top level (or module) scope, `foo(x, y, z)`, but I there is also something really nice about function names scoped to the thing/noun/subject: `x.foo(a, b)`. As far as I know Julia only does the former. Sometimes the latter seems a lot easier to deal with.
- ivirshup 5y ago
  You can do both. Check out the difference between `import` and `using`: https://docs.julialang.org/en/v1/manual/modules/ https://docs.julialang.org/en/v1/manual/modules/
  - blindseer 5y ago
    I think you mean you can do `foo(x, y, z)` instead of `M.foo(x, y, z)`. You cannot do `x.foo(y, z)` instead of `foo(x, y, z)`, a feature I sorely miss in Julia. Nim is awesome in this regard. There are some functions / paradigms that are just better represented by `x.foo(y, z)`. Chaining functions in particular in typescript / javascript / rust is SOOO nice. Specifically, in Julia a lot of times I want to create a immutable struct with multiple fields, many of which have defaults. In Julia none of ways seem clean to accomplish this. In rust, something like this is very common: let m = App::new("My Program") .author("Me, me@mail.com") .version("1.0.2") .about("Explains in brief what the program does") .arg( Arg::new("in_file").index(1) ) In Julia the same thing is: m = App("My program") m = author(m, "Me, me@mail.com") m = version(m, "1.0.2") m = about(m, "Explains in brief what the program does") m = arg(m, index(Arg("in_file"), 1)) I think with improvements to the pipe operator this can be better but right now I find this painful to read / write.
    - sundarurfriend 5y ago
      > immutable struct with multiple fields, many of which have defaults With `Base.@kwdef` (or the enhanced `@with_kw` from Parameters.jl) on the struct definition, that example can be: m = App(name = "My program", author = "Me, me@mail.com", version = "1.0.2", about = "Explains in brief what the program does", arg = index(Arg("in_file"), 1) which seems pretty nice to me. Also, there's Chain.jl for a better pipe operator, though I agree improvements to the Base pipe would be great. To the original point, the problem with x.foo(y, z) is that it would be highly misleading in that it seems to suggest that x is somehow special to the dispatch of the call, which isn't true. While superficially it can feel more familiar, it would instead become a trap for people giving them a wrong mental model of the call's semantics.
RyEgswuCsn 5y ago
I just noticed that someone finally fixed that stretched minesweeper screenshot on Julia's landing page.
- logankilpatrick 5y ago
  A small but mighty fix: https://github.com/JuliaLang/www.julialang.org/pull/1527 https://github.com/JuliaLang/www.julialang.org/pull/1527
blindseer 5y ago
I didn't read every testimonial but I read a lot, and I have to say a lot of it resonated with me and reminded me of when I first came across Julia. Congrats on the 10 year journey, and I hope for more great progress in the future.
xiaodai 5y ago
I still have a couple of pain points * TTFP - this is the big one. Every thing is a sluggish sometimes * Sluggish IDE in VSCode; I am on Windows so start up is a bit of a pain i often have to wait 20+ s for it to become responsive * Non-robust Basic Data Science coverage e.g. GLM fails on some datasets that R can handle. So it's the only code in my workflow that still has R in it
memming 5y ago
I recently made some time to come back to Julia and it's been wonderful. Unlike the early frustrating days when major version updates broke so many things, the core is solid and the ecosystem is wonderful. I am so happy learning and programming that I have to stop myself from spending too much time messing with it. Kudos to the Julia developers!
urthor 5y ago
I count myself as someone surprised at Julia's success. As a replacement for Python, I've never understood the appeal, and it's probably not going to fill that niche. Still, as a replacement for Matlab/Mathematica, it's doing swimmingly. All the best.
- ska 5y ago
  I don't really understand this comment. It was never intended to be a replacement for python in general use; do you mean as a numpy/scipy replacement? In that case, I guess we'll see. Python will never be a particularly good language for implementing such things, but has become pretty ok for using them once someone has implemented (in another language, and made the python bindings). Network effect is the real barrier, python itself is very easy to toss for this use .
- sundarurfriend 5y ago
  "Replacement for X" is a vague phrase - will Julia take over every usecase of Python? Unlikely. Will projects with established Python codebases, that work well for them, suddenly switch to Julia? Nah. Will new projects that need a flexible performant language, that would have otherwise been shoehorned into Python as the closest available option, choose Julia instead? Quite likely, and that happens a lot. Python has its place, and is good at a lot of things. But there have always been a lot of projects that have straddled the line between numeric computing and general purpose computing, needing both, where Python was chosen for lack of choice, just because it was the best among the bad options. That's the pain point Julia addresses, and the people who have experience being stuck in that situation understand what its place is and why it has the success it has. (And being a well designed language that's a pleasure to use helps too.)
visviva 5y ago
I started playing with Julia in 2013, after searching for a Matlab replacement that was (according to my notes at the time) "... open (or more open than Matlab), fast, parallelizable, with good scientific/math libraries." My intent was to write a reusable and extensible library to enable my day to day work (astrodynamics and estimation). Two years later I had implemented enough tools and gained enough proficiency with it that I switched entirely away from using Matlab at all (even for smaller data analysis tasks), and I haven't looked back. It has made me objectively better at my job, and a much better programmer overall.
- ModernMech 5y ago
  I feel like most people who haven't steeped themselves in the Matlab ecosystem don't fully grok the true impact of Julia on technical computing.
tkuraku 5y ago
I really like julia. For certain problems matlab and python are unworkable. People complain about time to first plot, but that doesn't matter too much to me. The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python. You can call matplotlib, But it feels like a second class citizen. Plotting just needs to be better with a clear preferred method. There are tons of options.
- sinab 5y ago
  For which kinds of problems are matlab and python unworkable?
  - elcritch 5y ago
    Statistical bootstrapping techniques are the ones I ran into.
  - tkuraku 5y ago
    Optimization type problems. Also anything with loops that isn't easily vectorizable.
  - adgjlsfhk1 5y ago
    All of these have some exceptions, but are for the most part true: high energy physics lots of computational bio fluid dynamics rendering In general, python and matlab really struggle in problems where you want maximum performance, but the most efficient algorithms aren't vectorized. In some cases, this is solvable by writing python libraries in C/C++, but especially in scientific fields, the end users are often the same people writing the algorithms, so they don't gain much from a python library if they have to do all the hard work in C++ anyway. Julia gives them a way more productive dev experience while still having a good user experience.
    - moelf 5y ago
      high energy physics (HEP) shameless plug: https://github.com/tamasgal/UnROOT.jl https://github.com/tamasgal/UnROOT.jl indeed, the grants (in the millions $) given to rewrite C++ or Python just to handle array (because for loop sucks) and ends up making monorepo blobs is jaw dropping -- while it's almost free in Julia, with 1/100 of the line of code and more flexibility we can match and beat even C++ code...
pbohun 5y ago
Julia is a very pleasant language to work with. The type system, multiple dispatch, and package system all make it into top 10 of design. The only change I would recommend is to have a way to distinguish between creating and setting a variable. Without this distinction it is very easy (especially for someone with dyslexia) to misspell a variable and accidentally create a new one instead of assigning a value. Something like this would be nice: var x = 5 or even something like Go: x := 5
- blipmusic 5y ago
  Please, yes! It may sound dumb, but such a "simple" change (simple conceptually, can't speak of the dev challenge involved) change would be an enormous quality of life increase to me. I've ended up looking into scoping rules and what not when bug-hunting because of this, but often just ended up going back to a language with stricter syntax around variable creation (goes for moving away from Python etc as well). The more the code, the bigger of an issue this becomes.
  - porker 5y ago
    I third this. It'd make such a difference for me.
  - davnn 5y ago
    Would you be willing to provide an example where this becomes a problem? Probably unpopular opinion, but I don‘t think this should be a problem for structured applications and hints at a more fundamental design problem.
    - blipmusic 5y ago
      > Would you be willing to provide an example where this becomes a problem? It's not a specific example, as much as every piece of code where mutability is involved. I don't have a LOC number in mind, but it could be for blocks/local scopes. IMO syntactic explicitness helps clarity and thus bug hunting/maintenance, and I feel tooling shouldn't be an alternative for dealing with, albeit subjective, syntactic shortcomings. > this should be a problem for structured applications and hints at a more fundamental design problem Frankly, I don't see how introducing an explicit hint that a variable is created can ever be a bad thing. Explicit lack of mutability is also something I'd like to have (e.g. 'let' vs 'var') - sometimes I want to make sure not to accidentally change a value. We will shoot ourselves in the foot at some point, so a syntax that allows for a check whether I can actually change a value further down can only be a good thing. I absolutely do not trust myself. :) When things go wrong for this reason (difficult to spot typo etc) I may waste time on investigating whether blocks are actually leaky or not etc - I have issues with Python syntax for the same reason. Going in the other direction, I like Rust's perhaps overly verbose "let mut" much better, since this has other consequences for explicitness (mutable references '&mut X' vs immutable references '&X'). No special tooling or IDE required to spot this, I can 'cat' the code in a terminal and it's still obvious. I absolutely don't think Julia or Python should "go Rust", since their dynamic nature is a strength, especially so in academia where notebooks are popular. But a simple "I'm creating a variable" should IMO be a nice visual cue to any developer.
lenkite 5y ago
Good for exploratory programming but trying to make a single binary for any re-distributable app is a nightmare. PackageCompiler will always beat you up. And frankly, why can't Julia have a simple, single CLI command to create a binary like any other PL.
- adgjlsfhk1 5y ago
  Compiling multiple dispatch is very difficult. There are a potentially infinite number of methods to compile.
  - sundarurfriend 5y ago
    Yes. There are good attempts towards static compilation, and we will have it one day, but it's something that requires high levels of expertise and effort given the dynamic nature and design of Julia - not just a matter of "doing it like any other language".
- DNF2 5y ago
  "Any other PL"? Really? Well, that is news to me:) Anyway, the answer to your question is very simple: Because it's difficult, and a lot of work. Not because they can't be bothered, as your question seems to imply.
lenkite 5y ago
An opposing viewpoint on the issues of Julia from a user of Julia: "What's bad about Julia?" https://viralinstruction.com/posts/badjulia/ https://viralinstruction.com/posts/badjulia/
- rashidrafeek 5y ago
  The author of that post also has written in the main post: https://julialang.org/blog/2022/02/10years/#jakob_nissen_a_hrefhttpsgithubcomjakobnissenjakobnissen https://julialang.org/blog/2022/02/10years/#jakob_nissen_a_h...
lmc 5y ago
Jose Storopoli (@storopoli): "I've made amazing friendships here, co-authored a free open access and open source Julia Data Science book with Rik Huijzer and Lazaro Alonso." I just read this book. Every page was like, 'wow'. A couple of questions I had afterwards: * I saw the DateTime type, but it doesn't seem to have a timezone - how do you deal with timezones? * How is it to work with async code? * It's a garbage collected language, what are some techniques to avoid performance pitfalls due to that? If there's other Julia programmers around, any answers would be much appreciated!
- cbolton 5y ago
  For timezones the official[1] answer is to use TimeZones.jl. For async code Julia has "tasks" which are similar to goroutines in Go: they can be multiplexed on a number of OS threads for parallelism, and channels can be used to communicate with other tasks. The language provides some sugar to make some common things easier, for example to get the result of a long-running operation: # Make channel and pass it to anonymous function result = Channel() do chan # Anonymous function body sleep(5) put!(chan, "Done") end # Do stuff ... # Now get the result take!(result) When GC is a problem, the most common is to minimize allocations and disable GC at critical times. See [2] for a robotics example where some kind of realtime is required. The language provides tools to help diagnose allocations, and minimizing allocations is a popular sport in the community so it's easy to get help on that topic. Still, realtime is currently not where the language shines. [1] https://docs.julialang.org/en/v1/stdlib/Dates/ https://docs.julialang.org/en/v1/stdlib/Dates/ [2] https://ieeexplore.ieee.org/document/8793875 https://ieeexplore.ieee.org/document/8793875
  - FabHK 5y ago
    > minimizing allocations is a popular sport in the community Thanks for the chuckle :-)
  - lmc 5y ago
    Fantastic, this is all really useful info. Thanks very much.
AitchEmArsey 5y ago
Make the package management more Cargo-like and I'd probably adopt it wholesale; whenever I've tried Julia in the past the user experience of just getting started has been the off-putting part.
- socialdemocrat 5y ago
  I don’t know cargo well enough to know what that means but Julia has the best package management system I have ever used. It takes a bit time to get into because it merges the concept of packages and environments.
  - sundarurfriend 5y ago
    > It takes a bit time to get into because it merges the concept of packages and environments. Could you explain what you mean here? The point of environments is to manage packages and dependencies, so by definition they're going to be closely coupled. It seems something about it seemed unintuitive to you though, so I'd like to understand what it was.
- sundarurfriend 5y ago
  Julia's package management was inspired by Cargo, afaik. What did you find off-putting about it, what would make it more Cargo-like? I've heard from people who are not used to the REPL wanting to do things from the shell directly, if that's the problem, there's the jlpkg tool [1]. [1] https://github.com/fredrikekre/jlpkg https://github.com/fredrikekre/jlpkg
  - AitchEmArsey 5y ago
    The REPL was indeed part of my issue, though having tried again in the last couple of days following this post, my impression is much more positive than on my last check (around when v1.5 was new, I think). Also, Pluto is a marvel - seems to fix all of my complaints about Jupyter and is trivially easy to use.
dexterlagan 5y ago
I really, really wanted to like Julia. The syntax looked perfect to me (coming from scheme), and somehow everything felt 'right'. That's when I discovered that compiling to binary seemed to be frowned upon. I found some documentation on how to do this back when 1.0 came out, but it looked unnecessarily complicated and 'third-party'. I'm guessing Julia really is for sci-comp and data scientists, and not for producing redistributable bins. Does anybody know if Julia will ever become more 'general purpose', like say Racket or Python? Thank you.
- krumbie 5y ago
  I don't think it's frowned upon to compile, many people want this capability as well. If you had a program that could be proven to use no dynamic dispatch it would probably be feasible to compile it as a static binary. But as long as you have a tiny bit of dynamic behavior, you need the Julia runtime so currently a binary will be very large, with lots of theoretically unnecessary libraries bundled into it. There are already efforts like GPUCompiler[1] that do fixed-type compilation, there will be more in this space in the future. [1] https://github.com/JuliaGPU/GPUCompiler.jl https://github.com/JuliaGPU/GPUCompiler.jl
  - cbkeller 5y ago
    Yeah, not frowned upon at all. StaticCompiler.jl [1] has made huge strides in the past few weeks actually thanks to Mason and Valentin (swapping in GPUCompiler as the backend); you can even compile to a tiny standalone binary without linking to the runtime if you're willing to use some tricks e.g. [2] to avoid GC allocations (stack allocations and manual heap allocations are both fine): # This is all StaticCompiler-friendly using StaticTools function print_args(argc::Int, argv::Ptr{Ptr{UInt8}}) # c"..." lets you construct statically-sized, stack allocated `StaticString`s # We also have m"..." and MallocString if you want the same thing but on the heap printf(c"Argument count is %d:\n", argc) for i=1:argc # iᵗʰ input argument string pᵢ = unsafe_load(argv, i) # Get pointer strᵢ = MallocString(pᵢ) # Can wrap to get high-level interface println(strᵢ) # No need to `free` since we didn't allocate this memory end println(c"That was fun, see you next time!") return 0 end # Compile executable using StaticCompiler # `] add https://github.com/tshort/StaticCompiler.jl` to get latest master filepath = compile_executable(print_args, (Int64, Ptr{Ptr{UInt8}}), "./") yielding: shell> ./print_args 1 2 3 4 5.0 foo Argument count is 7: ./print_args 1 2 3 4 5.0 foo That was fun, see you next time! shell> hyperfine './print_args hello there' Benchmark 1: ./print_args hello there Time (mean ± σ): 2.2 ms ± 0.5 ms [User: 0.8 ms, System: 0.0 ms] Range (min … max): 1.5 ms … 5.5 ms 564 runs Warning: Command took less than 5 ms to complete. Results might be inaccurate. shell> ls -lh print_args -rwxr-xr-x 1 user staff 8.5K Feb 10 02:36 print_args GC allocations are allowed if you use instead the approach in this PR [3], but we haven't wrangled that approach to produce standalone binaries yet. [1] https://github.com/tshort/StaticCompiler.jl https://github.com/tshort/StaticCompiler.jl [2] https://github.com/brenhinkeller/StaticTools.jl https://github.com/brenhinkeller/StaticTools.jl [3] https://github.com/tshort/StaticCompiler.jl/pull/58 https://github.com/tshort/StaticCompiler.jl/pull/58
streamofdigits 5y ago
I get a sense that the julia community is more anxious about adoption than, e.g. python or R communities. Its probably natural given it is a relative newcomer in the broader "data science" / "scientific computing" thing and in the past years there was an explosion of interest / hype around some of its subsets (in particular anything that can be labelled machine learning or AI) But participating in that "hype" is not necessarily what will entrench julia for the long term. Turning its unique characteristics (unique versus these other two open source contestants, not across the entire programming language landscape) into unmissable developer / user experiences seems to me a safer route. E.g what makes R impossible to ignore is the richness of its statistical toolkit. What makes python impossible to ignore is the productivity boost for typical tasks etc.
plafl 5y ago
Julia, because fast can be beautiful. I don't know how much it's going to grow but it doesn't look like stalling in the near future. The reason is simple: it fulfills a need no other language does. I would guess there are some possibilities that could be a menace: 1. Someone manages to convince scientists to use a statically typed language. 2. Computing paradigm changes drastically. Everyone moves to quantum computing or similar. 3. In another 10 years someone learns from the lessons of Julia and improves on them to make a much better language.
- moelf 5y ago
  the first two are impossible -- looking at the 10k scientists who program at CERN
- deleted 5y ago
  [deleted]
wodenokoto 5y ago
I thought Chris Rackauckas was particularly good. I think he ends with a good summary of one of the many reasons solving the dual language problem is important: > There are so many places in math that are simply untouched because they sound like the domain of a compilers instead of "computational science", and I'm excited to see how the next 10 years bridges this gap in Julia. https://www.julialang.org/blog/2022/02/10years/#chris_rackauckas_a_hrefhttpsgithubcomchrisrackauckaschrisrackauckas https://www.julialang.org/blog/2022/02/10years/#chris_rackau...
KenoFischer 5y ago
For those who like to reminisce, here is the HN discussion from 10 years ago: https://news.ycombinator.com/item?id=3606380 https://news.ycombinator.com/item?id=3606380
pella 5y ago
"14 February 2012" is a birthday?
- ViralBShah 5y ago
  In a way - because the original blog post was https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/
  - tomrod 5y ago
    The fact yall are still working at improving it ten years later, with substantial progress, gives me hope for its longer term adoption in the future.
wiz21c 5y ago
I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of the documentation is often sub par. For a newcomer like me, working examples would be great. For example, if you use the plots library, you'll have hard time finding a list of all possible plots (the documentation talks about lots of things, but strangely, not a list of possible charts). I've also looked at doing linear regression and GLM and, again, you've code libraries but the examples are rare... - the startup time are still quite slow but that's ok because somehow you adapt your workflow around. - being able to use greek symbols as identifiers is super cool but your editor as to manage that, else you'll have to memorize shortcuts... But still, I keep on using it, it's much faster for my use case (data processing). I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)
- eigenspace 5y ago
  Yeah, having Revise.jl be able to redefine types would be delightful.
  - UncleOxidant 5y ago
    There's ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl
- moelf 5y ago
  there's also https://docs.juliaplots.org/latest/generated/gr/ https://docs.juliaplots.org/latest/generated/gr/ in the docs which is basically "all the kinds of plots you can make" (see the other comment for Makie gallary)
  - ChrisRackauckas 5y ago
    Examples and tutorials should go first. Some parts of the ecosystem, for some reason, put the manual and descriptions first. Give people code, then give people a manual for if they want to dig further. Thankfully, this is rather easy to fix.
socialdemocrat 5y ago
I cannot remember exactly when I discovered Julia or where. But I remember I got intrigued early on and wrote a blogpost about 9 years ago on Tumblr, which is still there comparing Julia to Ruby of all things: https://assoc.tumblr.com/post/70484963303/getting-comfortable-with-the-julia-programming-language https://assoc.tumblr.com/post/70484963303/getting-comfortabl... The normal thing today is comparing Julia to R, Matlab and Python. But my intro to Julia was actually trying to convert code examples in the O'Reilly book: "Exploring Everyday Things with R and Ruby: Learning About Everyday Things" to Julia. I thought that worked quite nicely and that the Julia code looked a lot nicer than the Ruby code. It made me write a follow up blog post a few days later: https://assoc.tumblr.com/post/71454527084/cool-things-you-can-do-in-julia https://assoc.tumblr.com/post/71454527084/cool-things-you-ca... Unlike your typical Julia user I was always into programming because I wanted to make computer games. I liked playing with Game engine architectures and those exposed me to the problem of handling collision between objects of different types. Multiple-dispatch solves that problem very elegantly. Traditional object-oriented languages are pretty bad at it. From the perspective of writing clean and expressive code, this really won me over to Julia early on before I had done much serious work with it. It became my goto language for writing Unix tools, replacing Go, Ruby and Python.
- bobbylarrybobby 5y ago
  For unix tools, I assume you mean command line tools? In which case how do you ameliorate the long startup time on each invocation?
  - socialdemocrat 5y ago
    Hehehe oh yeah, I almost forget about that because I stopped years ago bothering to actually make the tools into separate files that I start from the shell. It is more like Julia is my shell. I'll just have packages with common tools I use and launch them by calling functions from the REPL. I'll just have packages for doing doing image file conversions in batch, modifying source code, changing configuration files etc. Actually come to think about it, I used to have shell scripts in a pipeline to build an application for security. We had to obfuscate the source code and stuff like that. When I rewrote to Julia it all ran much faster. Even if there was a startup time, the workload was heavy enough that the higher performance of Julia easily outperformed bash.

325 points by KenoFischer 5y ago

I first learned about Julia somewhere in 2013, I thought “damn, this looks really nice”, but never used it seriously until 2016 (v0.4). This language gives me joy, I never get tired of it.

antifarben 5y ago

I wish CrystalLang would gain some popularity and thus traction. It seems to be a good alternative between high level syntax and performance.

eigenspace 5y ago

I started using Julia in 2017, and as a physics student who saw Python, Mathematica, and Matlab as a series of tools that I had to pull out sometimes to solve specific problems, it came as a great shock to me that I was suddenly interested in Julia for it's own sake. It's not an overstatement to say that this language totally changed my relationship with computers and programming.

cbkeller 5y ago
That sounds about like my experience too, only s/physics/geology/ :)

komuher 5y ago

I can reflect on like past few years (like 1.5 year ago i was disappointed by julia lack of progres but a lot have changed). Julia is getting usable even in "normal" applications not only academic stuff, as person who come back after 1.5/2 years to julia i feel like i can use it again in my job cause it is a lot more stable at have a lot of new neat futures + CUDA.jl is amazing. I hope Julia team will still explore a bit more static type inference and full AOT compilation if language got full support for AOT it'll be a perfect deal for me :).

ChrisRackauckas 5y ago
StaticCompiler.jl is making huge strides. 12 days ago a rewrite was merged (https://github.com/tshort/StaticCompiler.jl/pull/46 https://github.com/tshort/StaticCompiler.jl/pull/46), and now the static compiler can allocate and use the runtime (https://github.com/tshort/StaticCompiler.jl/pull/58 https://github.com/tshort/StaticCompiler.jl/pull/58). I would still be weary of using it too much, but hopefully optimistic of its near future.
- eigenspace 5y ago
  Yeah, it's definitely in the early stages still, but this time I think there's much more infrastructure, and more people around with the right knowledge to advise on StaticCompiler's development, that I'm currently feeling pretty good about it's future. Here's the feature roadmap https://github.com/tshort/StaticCompiler.jl/issues/59 https://github.com/tshort/StaticCompiler.jl/issues/59 that should help people understand what currently works and what I think I can reasonably accomplish eventually

appleiigs 5y ago

I'm hoping Julia gets its killer app that can launch it to the next level like Rails or Numpy. Julia has a lot of pleasantries, but not enough to pry me away from what I'm productive with. There's certain amount of switching cost that needs to be overcome.

mbauman 5y ago
We already have (at least) one: Differential Equations and SciML.
- thetwentyone 5y ago
  ... plus Pluto, language-wide automatic differentiation, multiple dispatch, lispy macros...
  - earleybird 5y ago
    Pluto is that app for me coupled with a simple portable install. Installing on windows (workday I'm consigned to flames of woe) is simply a matter of downloading portable install .zip file, a simple startup .bat script[0], 'add Pluto', 'import Pluto' and finally 'Pluto.run()' I now have an Observable-like[1]notebook with all the Julialang goodness without running an installer [0] my julia.bat looks like: @echo off @REM see https://docs.julialang.org/en/v1/manual/environment-variables/ @REM %%1 is the project directory set JULIA_PROJECT=%1 set JULIA_DEPOT_PATH=%~dp0JULIA_DEPOT set JULIA_BINDIR=%~dp0julia-1.7.0\bin set PATH=%JULIA_BINDIR%;%PATH% %JULIA_BINDIR%\julia [1] https://observablehq.com/ https://observablehq.com/
hiepph 5y ago
Matrix operations are already built-ins in Julia. And it's such a pleasant to work with compared to the syntax of Numpy. People just don't want to get away from the familiar thing (i.e. Python). And I don't think making a web framework would be a focus of Julia since it was built with science and computing mindset. This might be cliché but use right tools for the job. I still use Ruby for web development and Julia for the science and machine learning stuffs (gradually moved from Python ecosystem).

cube2222 5y ago

I've been working through the Statistical Rethinking[0] course with Julia recently and so far the language has been really intuitive, same for the libraries (Turing, Distributions). And it's nice that you don't have to vectorize your code and can use normal for-loops. Also, the way dynamic dispatch + specialization work is beautiful. [0]:https://github.com/rmcelreath/stat_rethinking_2022 https://github.com/rmcelreath/stat_rethinking_2022

rnikander 5y ago

There is something elegant about having all functions at the top level (or module) scope, `foo(x, y, z)`, but I there is also something really nice about function names scoped to the thing/noun/subject: `x.foo(a, b)`. As far as I know Julia only does the former. Sometimes the latter seems a lot easier to deal with.

ivirshup 5y ago
You can do both. Check out the difference between `import` and `using`: https://docs.julialang.org/en/v1/manual/modules/ https://docs.julialang.org/en/v1/manual/modules/
- blindseer 5y ago
  I think you mean you can do `foo(x, y, z)` instead of `M.foo(x, y, z)`. You cannot do `x.foo(y, z)` instead of `foo(x, y, z)`, a feature I sorely miss in Julia. Nim is awesome in this regard. There are some functions / paradigms that are just better represented by `x.foo(y, z)`. Chaining functions in particular in typescript / javascript / rust is SOOO nice. Specifically, in Julia a lot of times I want to create a immutable struct with multiple fields, many of which have defaults. In Julia none of ways seem clean to accomplish this. In rust, something like this is very common: let m = App::new("My Program") .author("Me, me@mail.com") .version("1.0.2") .about("Explains in brief what the program does") .arg( Arg::new("in_file").index(1) ) In Julia the same thing is: m = App("My program") m = author(m, "Me, me@mail.com") m = version(m, "1.0.2") m = about(m, "Explains in brief what the program does") m = arg(m, index(Arg("in_file"), 1)) I think with improvements to the pipe operator this can be better but right now I find this painful to read / write.
  - sundarurfriend 5y ago
    > immutable struct with multiple fields, many of which have defaults With `Base.@kwdef` (or the enhanced `@with_kw` from Parameters.jl) on the struct definition, that example can be: m = App(name = "My program", author = "Me, me@mail.com", version = "1.0.2", about = "Explains in brief what the program does", arg = index(Arg("in_file"), 1) which seems pretty nice to me. Also, there's Chain.jl for a better pipe operator, though I agree improvements to the Base pipe would be great. To the original point, the problem with x.foo(y, z) is that it would be highly misleading in that it seems to suggest that x is somehow special to the dispatch of the call, which isn't true. While superficially it can feel more familiar, it would instead become a trap for people giving them a wrong mental model of the call's semantics.

RyEgswuCsn 5y ago

I just noticed that someone finally fixed that stretched minesweeper screenshot on Julia's landing page.

logankilpatrick 5y ago
A small but mighty fix: https://github.com/JuliaLang/www.julialang.org/pull/1527 https://github.com/JuliaLang/www.julialang.org/pull/1527

blindseer 5y ago

I didn't read every testimonial but I read a lot, and I have to say a lot of it resonated with me and reminded me of when I first came across Julia. Congrats on the 10 year journey, and I hope for more great progress in the future.

xiaodai 5y ago

I still have a couple of pain points * TTFP - this is the big one. Every thing is a sluggish sometimes * Sluggish IDE in VSCode; I am on Windows so start up is a bit of a pain i often have to wait 20+ s for it to become responsive * Non-robust Basic Data Science coverage e.g. GLM fails on some datasets that R can handle. So it's the only code in my workflow that still has R in it

memming 5y ago

I recently made some time to come back to Julia and it's been wonderful. Unlike the early frustrating days when major version updates broke so many things, the core is solid and the ecosystem is wonderful. I am so happy learning and programming that I have to stop myself from spending too much time messing with it. Kudos to the Julia developers!

urthor 5y ago

I count myself as someone surprised at Julia's success. As a replacement for Python, I've never understood the appeal, and it's probably not going to fill that niche. Still, as a replacement for Matlab/Mathematica, it's doing swimmingly. All the best.

ska 5y ago
I don't really understand this comment. It was never intended to be a replacement for python in general use; do you mean as a numpy/scipy replacement? In that case, I guess we'll see. Python will never be a particularly good language for implementing such things, but has become pretty ok for using them once someone has implemented (in another language, and made the python bindings). Network effect is the real barrier, python itself is very easy to toss for this use .
sundarurfriend 5y ago
"Replacement for X" is a vague phrase - will Julia take over every usecase of Python? Unlikely. Will projects with established Python codebases, that work well for them, suddenly switch to Julia? Nah. Will new projects that need a flexible performant language, that would have otherwise been shoehorned into Python as the closest available option, choose Julia instead? Quite likely, and that happens a lot. Python has its place, and is good at a lot of things. But there have always been a lot of projects that have straddled the line between numeric computing and general purpose computing, needing both, where Python was chosen for lack of choice, just because it was the best among the bad options. That's the pain point Julia addresses, and the people who have experience being stuck in that situation understand what its place is and why it has the success it has. (And being a well designed language that's a pleasure to use helps too.)

visviva 5y ago

I started playing with Julia in 2013, after searching for a Matlab replacement that was (according to my notes at the time) "... open (or more open than Matlab), fast, parallelizable, with good scientific/math libraries." My intent was to write a reusable and extensible library to enable my day to day work (astrodynamics and estimation). Two years later I had implemented enough tools and gained enough proficiency with it that I switched entirely away from using Matlab at all (even for smaller data analysis tasks), and I haven't looked back. It has made me objectively better at my job, and a much better programmer overall.

ModernMech 5y ago
I feel like most people who haven't steeped themselves in the Matlab ecosystem don't fully grok the true impact of Julia on technical computing.

tkuraku 5y ago

I really like julia. For certain problems matlab and python are unworkable. People complain about time to first plot, but that doesn't matter too much to me. The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python. You can call matplotlib, But it feels like a second class citizen. Plotting just needs to be better with a clear preferred method. There are tons of options.

sinab 5y ago
For which kinds of problems are matlab and python unworkable?
- elcritch 5y ago
  Statistical bootstrapping techniques are the ones I ran into.
- tkuraku 5y ago
  Optimization type problems. Also anything with loops that isn't easily vectorizable.
- adgjlsfhk1 5y ago
  All of these have some exceptions, but are for the most part true: high energy physics lots of computational bio fluid dynamics rendering In general, python and matlab really struggle in problems where you want maximum performance, but the most efficient algorithms aren't vectorized. In some cases, this is solvable by writing python libraries in C/C++, but especially in scientific fields, the end users are often the same people writing the algorithms, so they don't gain much from a python library if they have to do all the hard work in C++ anyway. Julia gives them a way more productive dev experience while still having a good user experience.
  - moelf 5y ago
    high energy physics (HEP) shameless plug: https://github.com/tamasgal/UnROOT.jl https://github.com/tamasgal/UnROOT.jl indeed, the grants (in the millions $) given to rewrite C++ or Python just to handle array (because for loop sucks) and ends up making monorepo blobs is jaw dropping -- while it's almost free in Julia, with 1/100 of the line of code and more flexibility we can match and beat even C++ code...

pbohun 5y ago

Julia is a very pleasant language to work with. The type system, multiple dispatch, and package system all make it into top 10 of design. The only change I would recommend is to have a way to distinguish between creating and setting a variable. Without this distinction it is very easy (especially for someone with dyslexia) to misspell a variable and accidentally create a new one instead of assigning a value. Something like this would be nice: var x = 5 or even something like Go: x := 5

blipmusic 5y ago
Please, yes! It may sound dumb, but such a "simple" change (simple conceptually, can't speak of the dev challenge involved) change would be an enormous quality of life increase to me. I've ended up looking into scoping rules and what not when bug-hunting because of this, but often just ended up going back to a language with stricter syntax around variable creation (goes for moving away from Python etc as well). The more the code, the bigger of an issue this becomes.
- porker 5y ago
  I third this. It'd make such a difference for me.
- davnn 5y ago
  Would you be willing to provide an example where this becomes a problem? Probably unpopular opinion, but I don‘t think this should be a problem for structured applications and hints at a more fundamental design problem.
  - blipmusic 5y ago
    > Would you be willing to provide an example where this becomes a problem? It's not a specific example, as much as every piece of code where mutability is involved. I don't have a LOC number in mind, but it could be for blocks/local scopes. IMO syntactic explicitness helps clarity and thus bug hunting/maintenance, and I feel tooling shouldn't be an alternative for dealing with, albeit subjective, syntactic shortcomings. > this should be a problem for structured applications and hints at a more fundamental design problem Frankly, I don't see how introducing an explicit hint that a variable is created can ever be a bad thing. Explicit lack of mutability is also something I'd like to have (e.g. 'let' vs 'var') - sometimes I want to make sure not to accidentally change a value. We will shoot ourselves in the foot at some point, so a syntax that allows for a check whether I can actually change a value further down can only be a good thing. I absolutely do not trust myself. :) When things go wrong for this reason (difficult to spot typo etc) I may waste time on investigating whether blocks are actually leaky or not etc - I have issues with Python syntax for the same reason. Going in the other direction, I like Rust's perhaps overly verbose "let mut" much better, since this has other consequences for explicitness (mutable references '&mut X' vs immutable references '&X'). No special tooling or IDE required to spot this, I can 'cat' the code in a terminal and it's still obvious. I absolutely don't think Julia or Python should "go Rust", since their dynamic nature is a strength, especially so in academia where notebooks are popular. But a simple "I'm creating a variable" should IMO be a nice visual cue to any developer.

lenkite 5y ago

Good for exploratory programming but trying to make a single binary for any re-distributable app is a nightmare. PackageCompiler will always beat you up. And frankly, why can't Julia have a simple, single CLI command to create a binary like any other PL.

adgjlsfhk1 5y ago
Compiling multiple dispatch is very difficult. There are a potentially infinite number of methods to compile.
- sundarurfriend 5y ago
  Yes. There are good attempts towards static compilation, and we will have it one day, but it's something that requires high levels of expertise and effort given the dynamic nature and design of Julia - not just a matter of "doing it like any other language".
DNF2 5y ago
"Any other PL"? Really? Well, that is news to me:) Anyway, the answer to your question is very simple: Because it's difficult, and a lot of work. Not because they can't be bothered, as your question seems to imply.

lenkite 5y ago

An opposing viewpoint on the issues of Julia from a user of Julia: "What's bad about Julia?" https://viralinstruction.com/posts/badjulia/ https://viralinstruction.com/posts/badjulia/

rashidrafeek 5y ago
The author of that post also has written in the main post: https://julialang.org/blog/2022/02/10years/#jakob_nissen_a_hrefhttpsgithubcomjakobnissenjakobnissen https://julialang.org/blog/2022/02/10years/#jakob_nissen_a_h...

lmc 5y ago

Jose Storopoli (@storopoli): "I've made amazing friendships here, co-authored a free open access and open source Julia Data Science book with Rik Huijzer and Lazaro Alonso." I just read this book. Every page was like, 'wow'. A couple of questions I had afterwards: * I saw the DateTime type, but it doesn't seem to have a timezone - how do you deal with timezones? * How is it to work with async code? * It's a garbage collected language, what are some techniques to avoid performance pitfalls due to that? If there's other Julia programmers around, any answers would be much appreciated!

cbolton 5y ago
For timezones the official[1] answer is to use TimeZones.jl. For async code Julia has "tasks" which are similar to goroutines in Go: they can be multiplexed on a number of OS threads for parallelism, and channels can be used to communicate with other tasks. The language provides some sugar to make some common things easier, for example to get the result of a long-running operation: # Make channel and pass it to anonymous function result = Channel() do chan # Anonymous function body sleep(5) put!(chan, "Done") end # Do stuff ... # Now get the result take!(result) When GC is a problem, the most common is to minimize allocations and disable GC at critical times. See [2] for a robotics example where some kind of realtime is required. The language provides tools to help diagnose allocations, and minimizing allocations is a popular sport in the community so it's easy to get help on that topic. Still, realtime is currently not where the language shines. [1] https://docs.julialang.org/en/v1/stdlib/Dates/ https://docs.julialang.org/en/v1/stdlib/Dates/ [2] https://ieeexplore.ieee.org/document/8793875 https://ieeexplore.ieee.org/document/8793875
- FabHK 5y ago
  > minimizing allocations is a popular sport in the community Thanks for the chuckle :-)
- lmc 5y ago
  Fantastic, this is all really useful info. Thanks very much.

AitchEmArsey 5y ago

Make the package management more Cargo-like and I'd probably adopt it wholesale; whenever I've tried Julia in the past the user experience of just getting started has been the off-putting part.

socialdemocrat 5y ago
I don’t know cargo well enough to know what that means but Julia has the best package management system I have ever used. It takes a bit time to get into because it merges the concept of packages and environments.
- sundarurfriend 5y ago
  > It takes a bit time to get into because it merges the concept of packages and environments. Could you explain what you mean here? The point of environments is to manage packages and dependencies, so by definition they're going to be closely coupled. It seems something about it seemed unintuitive to you though, so I'd like to understand what it was.
sundarurfriend 5y ago
Julia's package management was inspired by Cargo, afaik. What did you find off-putting about it, what would make it more Cargo-like? I've heard from people who are not used to the REPL wanting to do things from the shell directly, if that's the problem, there's the jlpkg tool [1]. [1] https://github.com/fredrikekre/jlpkg https://github.com/fredrikekre/jlpkg
- AitchEmArsey 5y ago
  The REPL was indeed part of my issue, though having tried again in the last couple of days following this post, my impression is much more positive than on my last check (around when v1.5 was new, I think). Also, Pluto is a marvel - seems to fix all of my complaints about Jupyter and is trivially easy to use.

dexterlagan 5y ago

I really, really wanted to like Julia. The syntax looked perfect to me (coming from scheme), and somehow everything felt 'right'. That's when I discovered that compiling to binary seemed to be frowned upon. I found some documentation on how to do this back when 1.0 came out, but it looked unnecessarily complicated and 'third-party'. I'm guessing Julia really is for sci-comp and data scientists, and not for producing redistributable bins. Does anybody know if Julia will ever become more 'general purpose', like say Racket or Python? Thank you.

krumbie 5y ago
I don't think it's frowned upon to compile, many people want this capability as well. If you had a program that could be proven to use no dynamic dispatch it would probably be feasible to compile it as a static binary. But as long as you have a tiny bit of dynamic behavior, you need the Julia runtime so currently a binary will be very large, with lots of theoretically unnecessary libraries bundled into it. There are already efforts like GPUCompiler[1] that do fixed-type compilation, there will be more in this space in the future. [1] https://github.com/JuliaGPU/GPUCompiler.jl https://github.com/JuliaGPU/GPUCompiler.jl
- cbkeller 5y ago
  Yeah, not frowned upon at all. StaticCompiler.jl [1] has made huge strides in the past few weeks actually thanks to Mason and Valentin (swapping in GPUCompiler as the backend); you can even compile to a tiny standalone binary without linking to the runtime if you're willing to use some tricks e.g. [2] to avoid GC allocations (stack allocations and manual heap allocations are both fine): # This is all StaticCompiler-friendly using StaticTools function print_args(argc::Int, argv::Ptr{Ptr{UInt8}}) # c"..." lets you construct statically-sized, stack allocated `StaticString`s # We also have m"..." and MallocString if you want the same thing but on the heap printf(c"Argument count is %d:\n", argc) for i=1:argc # iᵗʰ input argument string pᵢ = unsafe_load(argv, i) # Get pointer strᵢ = MallocString(pᵢ) # Can wrap to get high-level interface println(strᵢ) # No need to `free` since we didn't allocate this memory end println(c"That was fun, see you next time!") return 0 end # Compile executable using StaticCompiler # `] add https://github.com/tshort/StaticCompiler.jl` to get latest master filepath = compile_executable(print_args, (Int64, Ptr{Ptr{UInt8}}), "./") yielding: shell> ./print_args 1 2 3 4 5.0 foo Argument count is 7: ./print_args 1 2 3 4 5.0 foo That was fun, see you next time! shell> hyperfine './print_args hello there' Benchmark 1: ./print_args hello there Time (mean ± σ): 2.2 ms ± 0.5 ms [User: 0.8 ms, System: 0.0 ms] Range (min … max): 1.5 ms … 5.5 ms 564 runs Warning: Command took less than 5 ms to complete. Results might be inaccurate. shell> ls -lh print_args -rwxr-xr-x 1 user staff 8.5K Feb 10 02:36 print_args GC allocations are allowed if you use instead the approach in this PR [3], but we haven't wrangled that approach to produce standalone binaries yet. [1] https://github.com/tshort/StaticCompiler.jl https://github.com/tshort/StaticCompiler.jl [2] https://github.com/brenhinkeller/StaticTools.jl https://github.com/brenhinkeller/StaticTools.jl [3] https://github.com/tshort/StaticCompiler.jl/pull/58 https://github.com/tshort/StaticCompiler.jl/pull/58

streamofdigits 5y ago

I get a sense that the julia community is more anxious about adoption than, e.g. python or R communities. Its probably natural given it is a relative newcomer in the broader "data science" / "scientific computing" thing and in the past years there was an explosion of interest / hype around some of its subsets (in particular anything that can be labelled machine learning or AI) But participating in that "hype" is not necessarily what will entrench julia for the long term. Turning its unique characteristics (unique versus these other two open source contestants, not across the entire programming language landscape) into unmissable developer / user experiences seems to me a safer route. E.g what makes R impossible to ignore is the richness of its statistical toolkit. What makes python impossible to ignore is the productivity boost for typical tasks etc.

plafl 5y ago

Julia, because fast can be beautiful. I don't know how much it's going to grow but it doesn't look like stalling in the near future. The reason is simple: it fulfills a need no other language does. I would guess there are some possibilities that could be a menace: 1. Someone manages to convince scientists to use a statically typed language. 2. Computing paradigm changes drastically. Everyone moves to quantum computing or similar. 3. In another 10 years someone learns from the lessons of Julia and improves on them to make a much better language.

moelf 5y ago
the first two are impossible -- looking at the 10k scientists who program at CERN
deleted 5y ago
[deleted]

wodenokoto 5y ago

I thought Chris Rackauckas was particularly good. I think he ends with a good summary of one of the many reasons solving the dual language problem is important: > There are so many places in math that are simply untouched because they sound like the domain of a compilers instead of "computational science", and I'm excited to see how the next 10 years bridges this gap in Julia. https://www.julialang.org/blog/2022/02/10years/#chris_rackauckas_a_hrefhttpsgithubcomchrisrackauckaschrisrackauckas https://www.julialang.org/blog/2022/02/10years/#chris_rackau...

KenoFischer 5y ago

For those who like to reminisce, here is the HN discussion from 10 years ago: https://news.ycombinator.com/item?id=3606380 https://news.ycombinator.com/item?id=3606380

pella 5y ago

"14 February 2012" is a birthday?

ViralBShah 5y ago
In a way - because the original blog post was https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/
- tomrod 5y ago
  The fact yall are still working at improving it ten years later, with substantial progress, gives me hope for its longer term adoption in the future.

wiz21c 5y ago

I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of the documentation is often sub par. For a newcomer like me, working examples would be great. For example, if you use the plots library, you'll have hard time finding a list of all possible plots (the documentation talks about lots of things, but strangely, not a list of possible charts). I've also looked at doing linear regression and GLM and, again, you've code libraries but the examples are rare... - the startup time are still quite slow but that's ok because somehow you adapt your workflow around. - being able to use greek symbols as identifiers is super cool but your editor as to manage that, else you'll have to memorize shortcuts... But still, I keep on using it, it's much faster for my use case (data processing). I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)

eigenspace 5y ago
Yeah, having Revise.jl be able to redefine types would be delightful.
- UncleOxidant 5y ago
  There's ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl
moelf 5y ago
there's also https://docs.juliaplots.org/latest/generated/gr/ https://docs.juliaplots.org/latest/generated/gr/ in the docs which is basically "all the kinds of plots you can make" (see the other comment for Makie gallary)
- ChrisRackauckas 5y ago
  Examples and tutorials should go first. Some parts of the ecosystem, for some reason, put the manual and descriptions first. Give people code, then give people a manual for if they want to dig further. Thankfully, this is rather easy to fix.

socialdemocrat 5y ago

I cannot remember exactly when I discovered Julia or where. But I remember I got intrigued early on and wrote a blogpost about 9 years ago on Tumblr, which is still there comparing Julia to Ruby of all things: https://assoc.tumblr.com/post/70484963303/getting-comfortable-with-the-julia-programming-language https://assoc.tumblr.com/post/70484963303/getting-comfortabl... The normal thing today is comparing Julia to R, Matlab and Python. But my intro to Julia was actually trying to convert code examples in the O'Reilly book: "Exploring Everyday Things with R and Ruby: Learning About Everyday Things" to Julia. I thought that worked quite nicely and that the Julia code looked a lot nicer than the Ruby code. It made me write a follow up blog post a few days later: https://assoc.tumblr.com/post/71454527084/cool-things-you-can-do-in-julia https://assoc.tumblr.com/post/71454527084/cool-things-you-ca... Unlike your typical Julia user I was always into programming because I wanted to make computer games. I liked playing with Game engine architectures and those exposed me to the problem of handling collision between objects of different types. Multiple-dispatch solves that problem very elegantly. Traditional object-oriented languages are pretty bad at it. From the perspective of writing clean and expressive code, this really won me over to Julia early on before I had done much serious work with it. It became my goto language for writing Unix tools, replacing Go, Ruby and Python.

bobbylarrybobby 5y ago
For unix tools, I assume you mean command line tools? In which case how do you ameliorate the long startup time on each invocation?
- socialdemocrat 5y ago
  Hehehe oh yeah, I almost forget about that because I stopped years ago bothering to actually make the tools into separate files that I start from the shell. It is more like Julia is my shell. I'll just have packages with common tools I use and launch them by calling functions from the REPL. I'll just have packages for doing doing image file conversions in batch, modifying source code, changing configuration files etc. Actually come to think about it, I used to have shell scripts in a pipeline to build an application for security. We had to obfuscate the source code and stuff like that. When I rewrote to Julia it all ran much faster. Even if there was a startup time, the workload was heavy enough that the higher performance of Julia easily outperformed bash.