We’ve spent the past 9 years developing a new programming language. We’re the core developers of the Julia Programming Language. AuA.

Developing a language from scratch has got to be difficult for a number of reasons, but one of them is how you're forced to make design decisions without knowing the full ramifications for years. In hindsight, what were the best and worst decisions you've made?

Sometimes I'm surprised how much a seemingly minor features changes the way the language is used. At the hackathon after the first JuliaCon, Tim Holy and I implemented a feature called generated functions (staged functions at the time), which are basically a hook back into the compiler that allows you to generate code based on the types of the arguments. I wanted it for my C++ package (basically allowing julia to act as a C++ REPL) and he wanted it to speed up arrays. Nowadays, it's not used as much for arrays anymore, since the compiler has improved enough to make it unnecessary, but it is the basis for https://github.com/jrevels/Cassette.jl, which is a general non-standard executing framework that we're planning to use for everything from debugging to automatic differentiation.

It's too common that open source developers don't get the appreciation they deserve for what can be thankless work. So, firstly, thank you for your work on Julia!

Question: years ago, it felt like Julia was on a warpath to take on R and Python as the language to use for data science. It feels like that momentum has slowed lately. Do you agree and, if so, what do you think needs to happen to rekindle that enthusiasm?

I wouldn't characterize us as ever having been on a warpath with R or Python. We play very well with them through integrations like PyCall.jl and RCall.jl, as well as working with Jupyter notebooks. I think there's more than enough space for everybody.

With respect to data science, I agree that it's been lagging a bit behind in Julia compared to some other numerical application domains, but particularly with 1.0, we've tried to do a lot of the ground work to change that. With 1.0, we have compiler support for high-performance missing value support (https://julialang.org/blog/2018/06/missing), which was one of the biggest asks of the Julia data science community and I do hope they take good advantage of it, because it was a massive amount of work ;). On the package ecosystem side, meta-packages like the https://github.com/queryverse/Queryverse.jl are starting to make sure that all the disparate functionality is available in one uniform package. There's also https://github.com/JuliaComputing/JuliaDB.jl, which you can think of as a distributed, out-of core alternative to pandas, if you happen to have very large data sets. With all that, I do think the future is very bright here, and especially now that the core language has stabilized, we can focus a lot more attention on the core ecosystems.

Hey all, thanks for all your amazing work on Julia! Any favourite packages? Packages that people should know about but haven't gotten the attention they deserve?

Revise.jl has got to be my favorite package. OhMyREPL.jl is pretty awesome also.

I'm mostly an R programmer, but have been experimenting with and reading about Julia obsessively all year.

I've learned a TON about programming language design/theory from following discussion/blogs on Julia, reading the excellent documentation, and researching on my own.

Do you guys have any recommended books or resources on the subject to save myself and others some time? If you had to learn about programming language design from scratch, what would you recommend?

I kind of cheated by working with Jeff, but I think the best way to go about learning about programming language design is to use as many languages as possible. They each have their own feel, and figuring out what things work and why is crucially important. I did learn a little bit about formal programming language theory, but I haven't actually found it super useful in the day to day work of language development. A lot of what we do is API design, which is much more of a human question than a technical question (many APIs are technically possible, most are a horrible idea). Knowing what other things are out there that have solved the same problem is hugely beneficial for that.

In terms of implementation, basically everything I know about compilers has been a result of needing to do something and then reading up on the theory of how to do it. I'm much more of a "top-down" learner where I start with a problem and then recurse into the underlying concepts to figure out how to do it. E.g. I start by looking at what LLVM does, try to figure out why it does it and then read the papers it references.

There is of course various books that are often cited. The Dragon book (Compilers: Principles, Techniques, and Tools) is a classic. I found https://softwarefoundations.cis.upenn.edu/ a pretty good textbook for the more academic PLT view of things while still being practical enough to keep me interested.

Do you think there is still a need for people to purchase Matlab license anymore when Julia can handle matrix operations just as well?

Depends on what you're doing. We're actually seeing more people migrate from bespoke legacy systems or C++ than from Matlab. Particularly if Matlab works fine for you, there's often very little reason to switch. If you were starting a new project today, Julia would probably be a good option, but there are other of course (Python chief among them). There's probably not a lot of reasons to start a new project in Matlab these days.

First, I would like to thank you to create such amazing project as Julia.
For me it is an amazing experience see how this great language evolves.
It truly shines because of you doing such a brilliant work with your choices and ambitions, it reflects your amazing capabilities.

With your permission 3 questions:

1. Could you describe your work day? How does it look like for Language developers?
   For instance, Keno, what does it means to be the main developer of the Julia Compiler?
2. What's the next big decision, relating to Julia, on the table now? What are your thoughts about it?
3. What's your second favorite Language after Julia?

Thank You.

Could you describe your work day? How does it look like for Language developers? For instance, Keno, what does it means to be the main developer of the Julia Compiler?

I think the workday is pretty much the same as any software developer, with the primary difference being how much of the communication is done out in the open. The start of my day is usually spent catching up on GitHub issues, email, discourse, etc. Afterwards, I usually either have a long-term ongoing project (for much of the past six months that was reworking the optimizer to handle the new iteration protocol and our new missing data support) for some high-priority bug that I need to take care of. Then there's various calls and meetings. For example, every Thursday, we have a "triage" call, where we discuss the most urgent items that need taken care of, what things are release blocking and generally try to make decisions on things that get stuck. These calls can be quite intense (on occasion they've gone on for six hours).

What's the next big decision, relating to Julia, on the table now? What are your thoughts about it?

There's lots of design decisions to be done every day, but I think the biggest upcoming area will the multi threading. We're adding support for scheduling co-routines onto multiple threads (https://github.com/JuliaLang/julia/pull/22631) and to take advantage of that well, we'll have to figure out various aspects of the parallel memory and execution model.

What's your second favorite Language after Julia?

I don't really pick favorites, but I think there's a couple of languages we can learn things from. For example, I'd really like to do something about restricted memory ownership models (which would allow more aggressive optimizations in various cases) and the Rust people have obviously done a lot of thinking there. We can't quite copy their design, since our users have different expectations, but I'm still hoping there's something we can do there. I'm also partial to formal verification like you'd find in Coq or Idris.

Is static compilation of Julia code/packages mature enough already for production?

It does work and people are using it (even in production), but it's a bit complicated at the moment. There's definite improvements planned to the implementation and the tooling in the 1.x development cycle. Some of the biggest things on the todo list here are to make sure that binary dependencies work well (https://github.com/JuliaPackaging/BinaryBuilder.jl will help) and to make sure we can produce binaries that only have the code you need for you application, rather than including everything under the sun. That said, you may be interested in the following videos from JuliaCon, which discussed how to ship statically compiled applications with Julia:

https://www.youtube.com/watch?v=kSp6d3qSb3I

https://www.youtube.com/watch?v=G1HJnaRxMLQ

Are there ever any plans or dreams for a Julia CAS?

We're not planning to work on one ourselves, but there's a group in Germany that has a fairly large grant to do exactly this: http://nemocas.org/.

Favorite movie?

Hard to choose, but I'd say some of my favorites are the Matrix, Good Will Hunting and Spaceballs. I am more of a Sci-Fi TV than a movie person though. I think I'd rank my favorite shows as Dark Matter, Stargate, Firefly, The Expanse, TNG, Voyager, DS9.

To u/loladiro (Keno Fischer), just out of pure curiosity: Where are you from? You seem to have studied in the US but I'm not sure whether you're American also.

I'm from Germany. Lived in Ratingen, near Düsseldorf for most of my life and went to Gymnasium (Germany middle school/high school) in Essen. I came to the US as an exchange student when I was 14 (fun fact, you can fly alone as a 14-year old on a German airline, but not on an American one and if you're booked on both, they will just leave you stranded in the middle) and spent two years in Salisbury, MD, before moving up to Cambridge, MA for college, where I've lived since.

I came to the US as an exchange student when I was 14 (fun fact, you can fly alone as a 14-year old on a German airline, but not on an American one and if you're booked on both, they will just leave you stranded in the middle) and spent two years in Salisbury, MD

This makes it sound like you got stranded in Maryland for two years because of an airline transfer issue 😂

Hah, I first got stranded by Lufthansa in Frankfurt, after being denied boarding to Philly. Luckily we managed to convince Lufthansa to put me on one of their flights to Philly instead and we got my host family to pick me up there (still a decent drive from Salisbury).

What were you're reasons for pursuing a degree outside of Germany and even outside of Europe?

I didn't really plan to do go to college in the US, but I had been watching lecture videos on MIT OCW, so I was a bit obsessed with MIT being the place I wanted to go. That didn't end up working out, but during my time in Maryland, I did get the chance to go to Harvard, and it seemed to me that that was not an opportunity one should turn down.

What are you looking forward to in v2.0?

P.s.: Thanks for all the great work so far!

Figuring out the multi-threading model over the 1.x time frame should lead to it being amazing in 2.0. I'm also looking forward to getting better tooling. There's some amazing things we've been talking about for a very long time with respect to profiling, debugging, better error messages etc. Other than that, there's some amazing things happening in the ecosystem and I think the primary emphasis of 2.0 should be whatever support those packages need from the core language.

Just wanted to say I'm very excited for Julia and have been trying to get the jump on everyone else by using it early. Coming from python, i like the fact that there is a pythonic way to do things. Julia is much more flexible but is there or will there perhaps in the future be an equivalent concept?

Yes, people refer to a Julian way of doing things. Usually that means making good use of multiple dispatch or taking some of the patterns that have been successful in popular packages and using them in your own code. We don't want to ever require anybody to do something a certain way though.

One of Julia's key selling points is solving the two languages problem, where instead of writing my core library in C/C++ and my application in Python, I can do everything in Julia. In the meantime, however, it seems like we have a new two "devices" problem where now I write my core computing algorithms in CUDA for the GPU (or TensorFlow for the TPU) and wrap those in a higher-level API. This is especially acute in machine learning, where there a ton of different accelerators being developed (from GPUs to TPUs to FPGAs).

What do you think Julia's role is in this new "two devices" world?

Write everything in Julia still ;). Here's our GPU compiler: https://github.com/JuliaGPU/CUDAnative.jl. I also spent some time at Google earlier this year to discuss running Julia on TPUs (put on hold to get 1.0 out, but I intend to take it up again). At the end of the day, everything has to be programmed in something and why not have that something be Julia.

Where does the name come from? Is this a Facebook situation where one of you was dumped by a girl named Julia?

The name Julia comes from an earlier project that Jeff had called Julia. In fact, in our keynote at JuliaCon (https://www.youtube.com/watch?v=1jN5wKvN-Uk), we discuss this in a bit of detail. Our very first email conversation had the name Julia already in it, and the julia logo was already in one of the first commits.

That begs the question: is there any particular reason why Jeff called his other project Julia? This isn't explained in the video either. Or is it just Julia all the way down?

Or is it just Julia all the way down?

🐢

• 🐢
  • 🐢
    • ...

julia> 🐢() = 🐢()

🐢 (generic function with 1 method)

julia> 🐢()

ERROR: StackOverflowError:

Stacktrace:

[1] 🐢() at ./REPL[1]:1 (repeats 80000 times)

I have two suggestions that would trigger a positive phase change in Julia's growth:

1. Enable useful web assembly support for front and back end Julia programs.

2. Convince a large company to use and work on Julia for their machine learning stack.

Any plans to pursue these?

Enable useful web assembly support for front and back end Julia programs.

Yes, this is something we're interested in, particularly because people are facing an analogue of the two language problem when they start trying to put Web UIs onto their Julia applications. There's a couple of approaches here (e.g. https://github.com/MikeInnes/Charlotte.jl, https://github.com/tshort/ExportWebAssembly.jl). I'm expecting that we'll see more of that in the near future.

Convince a large company to use and work on Julia for their machine learning stack.

We're talking to all the large companies but many of them have significant NIH syndrome until something gets super popular. That said, a few of them are seriously evaluating Julia, so hopefully something will come out of that.

This is my first time hearing about Julia. I was wondering, who do you imagine would most use Julia and to Keno Fisher, I'm really curious, how did you get involved with this project as a high schooler?

Julia was created as a way for people who need to get numerical work done to do so faster, easier and in particular without having to switch to a different language, just because they wanted to get a bit of performance. As such, we've seen the most uptake in academia and in industries that need to do a lot of computing (e.g. Finance).

As for how I got involved, I originally learned about this area of computing my taking Andrew Ng's ML MOOC, which was taught in Octave. Afterwards, I participated in a competition called the Mathematical Contest in Modeling (https://www.comap.com/undergraduate/contests/mcm/), where you basically model a problem and write a research paper about it over the course of 96 hours. The Octave code I wrote for that (to simulate the total mass of leaves on a tree), ran fairly slow, so I had to be awake every 3 hours to check the results, add them to the paper, tweak things and kick off another run. I was already a pretty good programmer, so I considered helping out with Octave to make it go faster, but a few weeks later Julia was announced, so I decided to work on that instead. One of the fantastic things about GitHub is that everybody can contribute, independent of your level of experience, where you come from or what your background is. The Julia community is very inclusive. I'm also happy to say that I'm not the only high schooler who's taken this path with the Julia Community. E.g. Yingbo Ma, who is one of the most prolific contributors started in high school.

One of the trends (at least from my POV) in the data science and ML worlds is to more explicitly embrace the two-language problem by pushing more logic into the "lower-level" language (C/C++) while making the upper-level (relatively) thin bindings.. TensorFlow and Apache Arrow (both written in C++) are good examples of what I mean (especially compared to Scikit-Learn and Pandas respectively) -- most of their core logic is written in C++, but bindings are accessible to multiple languages (Java, C, Python, Go, JavaScript, etc), which allows different languages to interoperate more-or-less seamlessly (as long as you stick within the framework). Arguably Apache Spark's dataframe API is another example, where the core logic is Scala and it's accessible through Scala, Python, and R. BLAS/LAPACK might be the original example of this (although TBH I've only interacted with them through NumPy and SciPy).

I guess I have two questions here:

1. Do you think Julia is well-suited to writing some of the "infrastructure" libraries / frameworks? Is Julia well-suited to writing, e.g. a deep learning framework that's accessible through other languages or do you think C and C++ will continue to be the language(s) of choice here?
2. What do you think of this trend in general? Do you think, for example, that Julia will end up binding to Apache Arrow for most of its dataframe heavy lifting, or do you think people will prefer to write their own versions in pure Julia?

Do you think Julia is well-suited to writing some of the "infrastructure" libraries / frameworks? Is Julia well-suited to writing, e.g. a deep learning framework that's accessible through other languages or do you think C and C++ will continue to be the language(s) of choice here?

Yes, I think we'll see people doing more of this kind of thing with julia. There's already projects like https://github.com/JuliaDiffEq/diffeqr which expose Julia's differential equations ecosystem to R, and as more and more such killer use cases are developed in Julia, I fully expect people to want to call them from other languages.

What do you think of this trend in general? Do you think, for example, that Julia will end up binding to Apache Arrow for most of its dataframe heavy lifting, or do you think people will prefer to write their own versions in pure Julia?

The entire reason for Julia's existence is to be able to do everything in the same language. We have excellent support for bindings to other languages in order to re-use prior work, but I think if people use julia as yet another high level glue language only, we'll have failed. There's significant advantage to having everything in the same language, both to the user (being able to see how every part of the stack works and improve it for your use case) and the machine (doing analysis, e.g. automatic differentiation through all layers. You lose those when you go between languages.

> Yes, I think we'll see people doing more of this kind of thing with julia. There's already projects like https://github.com/JuliaDiffEq/diffeqr which expose Julia's differential equations ecosystem to R, and as more and more such killer use cases are developed in Julia, I fully expect people to want to call them from other languages.

That's super cool! I'm definitely going to take a look! Maybe this is me being selfish, but I would 100% recommend spending energy on exposing bindings to Julia libraries this as frictionless as possible. At least at $DAYJOB (and I imagine it's similar at a lot of places), we have a ton of investment in Python and C++ already and I can't see us moving away from that anytime soon, but if there are killer libraries in Julia exposed to Python we'd definitely want to use them!

Out of curiosity -- how does the packaging and multiple dispatch work when exposing bindings to other languages? Does it only work with a handful of types, letting Julia pre-compile everything, or do you have to ship with the Julia language to JIT things?

Out of curiosity -- how does the packaging and multiple dispatch work when exposing bindings to other languages? Does it only work with a handful of types, letting Julia pre-compile everything, or do you have to ship with the Julia language to JIT things?

Depends on what you want to do. These bindings tend to ship a full julia, as well as the capability to get a foreign language handle to julia objects (and sometimes more fancy things like direct memory sharing between julia and the host langauge). We've recently started replacing openlibm by julia implementations and there has been talk of offering those replacement implementations in a C-compatible libm library for others to use, which at that point would be a more limited form of binding that does not ship most of the julia runtime and would only ship the compute kernels themselves.

I've checked out the progress of Julia every once in a while. Now that 1.0 is out, what's the best way to learn the language and maybe even contribute to it?

Check out the youtube channel (https://www.youtube.com/user/JuliaLanguage) for some great introductory material on various topics. As for contributing, just pick anything on GitHub labeled with the "good first issue" label: https://github.com/JuliaLang/julia/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22.

I love the language. Could you share what you can about the business plan for Julia Computing? Also how you plan on evangelizing (other than being the best language, of course.)

Well, the business plan is fairly simple. Make enough money to pay people to make Julia amazing for everybody. The key is figuring out what we can charge for without compromising that goal. At JuliaCon, we announced that we're starting to do payed online training as well as a product called JuliaTeam, which should help companies that are using Julia manage and control which packages are available in their organization, as well as have a 1-click way to get support for various packages from us. There's a couple other things we're doing, but we hope that things like JuliaTeam will work well, both in terms of generating revenue, but also in giving companies confidence when deploying Julia in their organizations.

It seems like programming has moved further away from mathematical to something... else. It seems like very few programmers actually know basic math (I mean basic from a mathematicians point of view, not that they can't add and subtract). What are your thoughts on this, and what are your thoughts on the effect this has had on the industry? Do you think Julia's popularity is a sign of this changing, that people want modern languages that allow them to bridge the gap between software and mathematics more easily?

I think knowing mathematics or rather the theory of whatever your working on is important to get things done and to make the right choices, but as you say, you can get far without it. What I think julia is very good at is to be able to describe concepts closely enough to the mathematical notation of the field that it is easier for programmers to make the jump from just trying to get things done to understanding the math. Take ML for example. A dense NN layer in Flux.jl is implemented like this: https://github.com/FluxML/Flux.jl/blob/master/src/layers/basic.jl#L78. Even if you don't know much about math, you can see that there's a matrix multiplication and an addition (which may not be so obvious if the same is implemented in a few thousand lines of C++ or CUDA). So I hope that Julia can help guide people to the underlying mathematical beauty.

I'm extremely interested in language design, I'd love to work on a language after school (masters CS student graduating in May). I built a compiler from scratch for a course which was beyond rewarding, and I've built a toy language with PLY (python lex/yacc).

What tips do you have for someone interested in language design that would like to do it professionally? Should I be trying to contribute to an open source language? Should I continue to develop toy languages for experimentation?

Thanks!

Well, language design is a bit of a specialized field and there's not too many places doing it, particularly if you want to do actual language design yourself rather than just working on a language implementation. That said, there is a number of very active open source language communities out there. At Julia Computing, we tend to hire from people who have existing experience contributing to Julia in the open source community and I imagine companies supporting other languages work similarly. If you want to do toy languages, I'd recommend playing with a couple different kinds (imperative, functional, pattern matching, etc) and try out new techniques. And don't get too attached to any one of them or you may find your next decade taken up by actually implementing it fully ;).

Julia 1.0 is really a great release. What I miss the most compared to other languages is a debugger. Are there any plans for developing a debugger (and keeping it up-to-date with julia releases)?

I intend to update ASTInterpreter2 to 1.0, which is at least half of a debugger. You may also be interested in https://github.com/timholy/Rebugger.jl. I do have plans for a more fully featured, native, out-of-process debugger, but that's a bunch of work that I'll need to figure out how to find the time for.

I have a math background and my primary language is rather Python, although I'm luring around the Julia community for many years now. I'm not that experienced in Julia, I've only converted my old numerical analysis exercises from MATLAB to Julia, but it was a lot of fun!

Could you mention some beginner-friendly Julia packages, that are looking for contributors? I would love to give something back to the Julia community or maybe even get a part of it!

Depends on what you're looking for. We've been having a lot of fun getting students to reimplementing various research papers in machine learning (see https://github.com/FluxML/model-zoo/pulls) or differential equation solvers (various packages under https://github.com/JuliaDiffEq). Because of the 1.0 release, there's also various packages that still need some tweaks to work properly on 1.0, so if there's some package you find interesting, try installing 0.7 and see if you can't fix any warnings that come up (those warnings are generally errors in 1.0).

How will r/programmerhumor mock you?

Probably one based indexing, but I hope they can come up with something more clever.

Julia looks like a fantastic language for data analysis, and I'm excited there's finally a good (free) alternative to Matlab. Recently it seems there's been a trend in the scientific community to switch to python over Matlab for increased flexibility when programming.

I looked though the documentation and was slightly disappointed though. It seems there are a lot of small intricacies that would make this a more time consuming language to learn, similar to C++ or Ruby. Additionally, in the documentation it looked like I saw a lot of "you can totally do this bad practice coding, but you shouldn't because it's bad practice". I guess this is a more personal preference to like more strict programming languages but I think they're easier to work with while learning and in the long run. It looks like Julia is the opposite paradigm compared to languages like Go.

For these reasons I think this will be fantastic for scientific computing, but I'm not seeing it as widely adopted for general purpose programming. I'm not trying to be negative because this looks like great work, I was just wondering to get your thoughts on this?

We tend to have a general philosophy of letting you do whatever you want in your program (I mean, hey it's your program after all - if there's an easy hack to get things done just do it) and then build tools to help you improve your code afterwards if you want to (if you're just building a one off, you might not care). Perhaps the most obvious of these tools at the moment are the various @code_typed-style introspection tools to tell you what the compiler was able to find out about your code and guide you to improving it for additional performance. There's a couple of extra ones that are less mature. I think we'll see more of that in the future. Julia is quite statically analyzable (which the compiler does for performance), so there's some very powerful tools that can be built for correctness, or paradigm adherence also. However, we really try to make sure that Julia "doesn't get in your way" if you're just trying to get something done and this dual approach seems to be a good way to get it done. They key is to make it integrated nicely to make sure that users actually take advantage of it. That'll be ongoing work, but I'm confident we'll be able to figure out a good way to do it.

Programmer here. Never heard of Julia before. Took a quick look at your docs. This looks to me like Matlab m-file programming meets Golang.

I guess this language was designed for academics familiar with Matlab to take the plunge and use a real compiled language for performance, etc?

I know a number of scientists that are outgrowing Matlab for their needs. I guess Julia is designed to fill that niche?

It was designed for a similar user community. Matlab (and systems like it) got many things about the ergonomics scientific computing right, but many things about language design horribly wrong. The goal of Julia was to have something that was "non-scary" to scientists and domain experts, but have very strong foundations as a proper programming language. One of the most powerful things about julia is how composable and generic julia code tends to be (mostly thanks to the way that multiple dispatch works and meshes with specialization), which is not something you would find in either Matlab or Go. I'd encourage you to take a deeper look into the docs (and maybe even try the language). There's some very cool and powerful ideas in the language that you don't really find elsewhere.

First of all, I'm a big fan of Julia ever since I tried to interface CUDA code with (numpy) python, where it took me a long time just to figure out what interfacing package I should use. The contrast with the ease of callling compiled functions from julia couldn't have been greater. I rewrote my python code to julia and I was up and running in about a week. By now I'm totally hooked and feel quite limited by other languages, either because of performance ("should I really be writing this python loop?") or missing multiple dispatch.

• I get that you wanted to release during JuliaCon, but wasn't it perhaps better if you had more time between the releases of 0.7 and 1.0 so more packages could get themselves 1.0 compatible for the release? It felt a bit disappointing for me when I tried installing packages after the great 1.0 release and got errors.

• The programming paradigm of Julia, with the focus on multiple dispatch, is quite different from other, standard languages. In my experience, I found it not obvious how I should approach writing a module and making a good, reusable interface, for instance the dilemma between "Let the user put a function in a struct and call the function as t.f(...) or let the user subtype and define f(t::MyType, ...)", I'm still not sure (when) which is the right choice. As a (non-computer) scientist first, my programming skills are limited, which probably adds to my confusion, but do you know if some resources/guidelines have been developed for this kind of thing?

• How soon after the release did you discover the analogue of that typo you see right after you press send on an email: that one bad thing that could/should have been fixed but now you're stuck with it because of the stability guarantees of 1.0.

Edit: Oh yeah, thank you so much for making this amazing language.

I get that you wanted to release during JuliaCon, but wasn't it perhaps better if you had more time between the releases of 0.7 and 1.0 so more packages could get themselves 1.0 compatible for the release? It felt a bit disappointing for me when I tried installing packages after the great 1.0 release and got errors.

It's a trade off. It was a bit rushed perhaps, but all things considered I think it was the right decision. Doing it at JuliaCon allowed us to achieve this milestone as a community rather than just having a few core developers tag it and call it a day. Also, actually releasing the thing made the transition to 1.0 much faster. At this point we have about the same fraction of the ecosystem working on 1.0 as we did on 0.7 a week ago and things are still going up. The dust here will be settled in a week or two, but everyone's memory of the 1.0 tagging event will last much longer.

The programming paradigm of Julia, with the focus on multiple dispatch, is quite different from other, standard languages. In my experience, I found it not obvious how I should approach writing a module and making a good, reusable interface, for instance the dilemma between "Let the user put a function in a struct and call the function as t.f(...)
or let the user subtype and define f(t::MyType, ...)
", I'm still not sure (when) which is the right choice. As a (non-computer) scientist first, my programming skills are limited, which probably adds to my confusion, but do you know if some resources/guidelines have been developed for this kind of thing?

It takes a bit of getting used to, but often some patterns will feel natural and some won't. The easiest way to get that intuition is to play with some of the more popular julia libraries (Distributions, ColorTypes, the Images.jl stack) and see what kind of patterns they use and in what situations they do. There are a couple of guides around, but I don't think they're a substitute for gaining that intuition.

How soon after the release did you discover the analogue of that typo you see right after you press send on an email: that one bad thing that could/should have been fixed but now you're stuck with it because of the stability guarantees of 1.0.

I don't think we've found that yet. I'm sure we will, but we did spend a long time getting 1.0 in shape to make sure that doesn't happen. There's always bugs of course, and there was one particular regression which would have been very embarrassing to ship 1.0 with (https://github.com/JuliaLang/julia/issues/28527), but luckily that was caught just before we were about to release and it made it into 1.0.

I don't really have a question, just wanted to say thanks!

My undergraduate physics thesis was based on a project to speed up a nonlinear optics simulation done in matlab by 'translating' to Julia, it was great fun!

I feel lame not asking a question in an AmA, so:

What's your goto syntax colour scheme?

Thank you for stopping by. Glad we were able to be of help ;).

My editors currently are all set to Monokai, but I'm not too picky on what the colors are. I do like having the colors though.

Hey, 17-year-old guy with very little programming experience here.
So, I have a very basic knowledge of C++ from high school and I was wondering if Julia would be a good starter language to learn, since you mentioned that it is "dirt simple to learn"?
If yes, would you point me to tutorials or books on Julia? :)

I think Julia in general is a good language to get started with, since it can span much of the abstraction stack in programming, from very low level bit manipulation to very high-level functional programming abstractions. For an introduction to Julia, you might like the recent JuliaCon introductory tutorial: https://www.youtube.com/watch?v=cPYgipsg4DM. Fair warning though, if you get started with Julia, you may be too frustrated by other languages to ever want to use something else again ;).

Ooh, I just thought of another question:

On the one hand as language developers you hack away at language issues/problems, on the other hand there are people who use (features of) Julia for projects in ways you never would have imagined ahead of time. How did you manage to stay close to those people, such that you know what they want and need (which will not always be obvious, even to the users themselves)?

On the one hand as language developers you hack away at language issues/problems, on the other hand there are people who use (features of) Julia for projects in ways you never would have imagined ahead of time. How did you manage to stay close to those people, such that you know what they want and need (which will not always be obvious, even to the users themselves)?

Some people complain loudly on GitHub or elsewhere when things don't work for them, so we find out that way. We also try to work closely with people who have particularly interesting or challenging problems to make sure Julia works well for them (and we learn what doesn't work that way). For example, I worked on the Celeste project last year (https://www.nextplatform.com/2017/11/28/julia-language-delivers-petascale-hpc-performance/). We're still not through the list of all the improvements we could make that would have made that project easier.

Since creating the company, we also have commercial users now of course, and we tend to hear about their problems.

Why is it that programming languages make architectural decisions that make them good/bad at doing certain tasks? Is it not possible to create one that simply has concurrent systems that can interact with each other to provide the most efficient architecture for a given task?

There's many trade offs in programming language design that can make it more suited for one task or another. For example, if your programming language is focused on shell scripting, you may not care about having operations for low level memory access, because your users don't tend to need that. Not implementing those operations make your job easier, and you can guarantee that the user won't shoot themselves in the foot by scribbling over the important memory. Another important consideration is implementation complexity. Some features are just very hard to implement. For example, Multiple Dispatch, which we do in Julia is great for expressing mathematical operations, but implementing it in a performant manner is really hard, and much of the design of Julia is geared towards making that possible. It would be basically impossible to take julia's multiple dispatch system and just bolt it onto an existing language in a high performance manner. That said though, money and time can make up for a lot of deficiency in language design. Modern JavaScript engines are true marvels of engineering and pretty damn fast, despite JavaScript not being a language that's very easy to optimize.

I'm a former Computer Science student currently enrolled in a Msc Data Science. Is there any chance to contribute to the language, considered my knowledge? I would like to find something to apply what I'm currently studying and Julia seems cool to start with.

I started contributing in high school, so I'd say your overqualified already ;). The best way to get started is to try Julia on a problem you care about, see what issues you find, report them and (if you're up for a challenge) fix them. When I was in school, I used julia for all my numerical problem sets and lab reports and some fun generic functionality came out of that (e.g. SIUnits.jl and improvements to plotting packages). The best thing to fix is something that frustrates you when trying to work with it.

Imagine I'm new to coding. If I wanted to expand my programming knowledge, should I learn Julia? What kinds of things would I be able to do? (web? mobile apps? something different?)

Julia excels at anything that involves heavy computation. These days, the hottest variant of that is probably machine learning. I did a few of the AI/ML MOOCs a few years ago and I think it would be quite pleasant to do the coding exercises for those in Julia. There is a number of julia tutorials available online if you're looking to get started.

Any chance of someday see currying in Julia?

As an add-on to Stefan's reply, we do in general make comparison operators curried as of 1.0 to allow things like:

findall(==(1), arr)

which finds all elements of the collection `arr` equal (in the == sense) to 1.

It took quite a bit of work to see actual code samples while digging through your site. (admittedly on mobile)

Generally with a new language, this is what I look for before all the "why it's so awesome"

Is this just poor planning or are you afraid people will be turned off by the syntax and navigate away before learning the "why's"?

We've just changed up the design of the website and the sample code lost in the process. Issue about it here: https://github.com/JuliaLang/www.julialang.org/issues/115

I am comforted by the fact that this was noticed by a dev. I'll just chalk its absence to the fact that you were so busy over engineering a language that you under engineered the site.

ヾ(⌐■_■)ノ♪

Pull Requests to the website welcome ;)

As a web developer (already programming in js and python), is there a reason I would want to learn Julia?

Depends on the kind of thing you do. If there's any sort of numerical computing involved in the back end that Julia would be good at, I think you'd find Julia also has the rest of the stack available. Otherwise, you may be able to define abstractions slightly nicer in Julia than in other languages, but Julia probably isn't as much of a no-brainer in web dev as it is in some other areas. One thing that's coming up though is Go-like scheduling of coroutines to multiple threads, so maybe at that point people will be interested in using Julia for server applications if they miss generics and other language features in Go.

Why did you make it when you are well aware that it will never be popular or even acknowledged?

whats the point? no one will use it, they will just use the popular ones available now rather than yours?

That's a bit of a glim view of the world. You've got to believe that you can make a difference. The reason to solve any problem is because you experienced the problem yourself and want to come up with a solution. We were frustrated by the programming languages we had available and thought we could do better. Even if you fail miserably, you'll have gained an understanding of what programming languages do, what works and doesn't work, and how hard it is to do things right. On the other hand, the Julia community has seen fairly consistent user growth since I first started working on it in 2012, which at least gave us some idea that we're on the right track.