Greetings, everyone! About two years ago we stopped by here to tell y'all about our work on the Julia programming language. At the time we'd just finished the 2018 edition of our annual JuliaCon conference with 300 attendees. This year, because of the pandemic, there is no in-person conference, but to make up for it, there is an online version happening instead (which you should totally check out - https://live.juliacon.org/). It'll be quite a different experience (there are more than 9000 registrations already), but hopefully it is also an opportunity to share our work with even more people, who would not have been able to make the in-person event. In that spirit, I thought we were overdue for another round of question answering here.

Lots of progress has happened in the past two years, and I'm very happy to see people productively using Julia to tackle hard and important problems in the real world. Two of my favorite are the Climate Machine project based at Caltech, which is trying to radically improve the state of the art in climate modeling to get a better understanding of climate change and its effects and the Pumas collaboration, which is working on modernizing the computational stack for drug discovery. Of course, given the current pandemic, people are also using Julia in all kinds of COVID-related computational projects (which sometimes I find out about on reddit :) ). Scientific Computing sometimes seems a bit stuck in the 70s, but given how important it is to all of us, I am very happy that our work can drag it (kicking and screaming at times) into the 21st century.

We'd love to answer your questions about Julia, the language, what's been happening these past two years, about machine learning or computational science, or anything else you want to know. To answer your questions, we have:

/u/JeffBezanson Jeff is a programming languages enthusiast, and has been focused on Julia’s subtyping, dispatch, and type inference systems. Getting Jeff to finish his PhD at MIT (about Julia) was Julia issue #8839, a fix for which shipped with Julia 0.4 in 2015. He met Viral and Alan at Alan’s last startup, Interactive Supercomputing. Jeff is a prolific violin player. Along with Stefan and Viral, Jeff is a co-recipient of the James H. Wilkinson Prize for Numerical Software for his work on Julia.
/u/StefanKarpinski Stefan studied Computer Science at UC Santa Barbara, applying mathematical techniques to the analysis of computer network traffic. While there, he and co-creator Viral Shah were both avid ultimate frisbee players and spent many hours on the field together. Stefan is the author of large parts of the Julia standard library and the primary designer of each of the three iterations of Pkg, the Julia package manager.
/u/ViralBShah Viral finished his PhD in Computer Science at UC Santa Barbara in 2007, but then moved back to India in 2009 (while also starting to work on Julia) to work with Nandan Nilekani on the Aadhaar project for the Government of India. He has co-authored the book Rebooting India about this experience.
/u/loladiro (Keno Fischer) Keno started working on Julia while he was an exchange student at a small high school on the eastern shore of Maryland. While continuing to work on Julia, he attended Harvard University, obtaining a Master’s degree in Physics. He is the author of key parts of the Julia compiler and a number of popular Julia packages. Keno enjoys ballroom and latin social dancing (at least when there is no pandemic going on). For his work on Julia, Forbes included Keno on their 2019 "30 under 30" list.

Proof: https://twitter.com/KenoFischer/status/1287784296145727491 https://twitter.com/KenoFischer/status/1287784296145727491 https://twitter.com/JeffBezanson (see retweet) https://twitter.com/Viral_B_Shah/status/1287810922682232833

Comments: 658 • Responses: 57  • Date: 

akak1972756 karma

The original Julia goal was to have the speed of C and the simplicity of Python. To what extent have these goals been achieved, in your opinion?

loladiro522 karma

I think this has been completely achieved and we're trying to go beyond into things that aren't easily possible in either language. On the performance side, there is a certain level of performance that a language needs to have for it to be "fast" (which C and Julia have, but vanilla Python does not), but beyond that other things become more important for absolute performance. Those are things like memory layout, parallelism, algorithmic selection (ideally with automatic specialization to the particular problem). There are systems in limited domains that have all these features to achieve the extra performance (e.g. all the machine learning frameworks to this kind of stuff), but I would like to find ways to make these capabilities more generally available, so I think that's the frontier on the performance side.

On the simplicity side, obviously more capabilities bring some additional complexity, but I think something that Julia has always done well and that is extremely important to us is to start simple and have everything complicated be optional, so if you just want to get things done, or use it as a calculator you can. Only if you need to do something more complicated should you have to reach for the more complicated tools. I was discussing this approach with Chris Lattner (author of Swift) a few years ago over dinner and he called it the "Principle of Gradual Exposure of Complexity", which I think is a good term for it and one of the key things we're trying to do.

StefanKarpinski153 karma

Quite well, I think. You can write very simple Python-like code and it will, if you mind a few performance considerations, run as fast as C code—and sometimes faster. I think the comparison falters in two areas:

  1. Compiler latency. Since Python is interpreted, it doesn't have any compilation lags. Of course, as a result it's slow, but sometimes you don't want to wait for a compiler. It's an ongoing challenge to reduce compiler latency. A huge amount of progress has been made for the 1.5 release, reducing compilation latencies by 2-3x in many common cases. However, we're starting to change tack and focus on being able to statically compile and save more code, which will help even more since most code doesn't need to change from run to run.
  2. Perception of complexity. One of the great things about Julia is that it has this whole sophisticated, well-considered types system for when you need it. But people show up and want to learn Julia and are a little intimidated, thinking they need to learn all about types in order to write Julia code. I've tried to convey to people that they really don't, but that's a hard message to get through while also encouraging the people who want to learn that stuff. There's a perfectly useful, high-performance dialect of Julia that many people can use without ever needing to write any type annotations.

Somewhat ironically on the last point, Python has been adding type annotations in recent versions, so there's some convergence here. However, Python's type annotations are really just comments with special format that can be type checked—they add no expressiveness to the language. In Julia, on the other hand, using types and dispatch to express things is really, really useful. My casual impression is that the coherence of the mypy type annotations is a bit iffy, especially when it gets into parametric types. Julia's type system, on the other hand is very carefully thought through.

mriswithe30 karma

So it sounds kind of like how Cython deals with type annotations in that if you use them you get big performance gains because it can shortcut the compiler, but if you don't that's fine too, it will still compile down and be faster than standard python. Would that be a fair comparison?

StefanKarpinski27 karma

You don't generally need type annotations in Julia for speed. It's really only necessary for typed locations like typed data structures (Vector{Float64} for example) and typed fields in structs. It's useful for expression behavior via dispatch, but annotations don't help performance since the compiler specializes on actual types at runtime.

staticfloat56 karma

To illustrate this a bit, if you were to write a method such as:

function mysum(data) accumulator = 0.0 for x in data accumulator += x end return accumulator end

The method is written generically enough that there is no mention of what data is; we are simply assuming that whatever is passed in to mysum will be iterable. When my program calls mysum(data), if data is a Vector{Float64}, then a version of this method will be generated that does floating-point addition in the += method. If I call it with data as a user-defined LinkedList that contains arbitrary-precision Rational numbers, then a different version of this method will be compiled to do the appropriate iteration and summation.

When this method is used by calling code, which underlying mysum implementation gets used is up to the dynamic dispatch implementation, and thanks to type inference, this is often statically decidable. Example:

function do_work() data = randn(1024) .* 100 # This gives me a Vector{Float64} data = round.(Int64, data) # This gives me a Vector{Int64} return mysum(data) # Calls the Vector{Int64} specialization end

In this case, when I call do_work(), the compiler is able to propagate the types through the computation, figuring out where it knows without a doubt which method to call. In this case, it can call the mysum(x::Vector{Int64}) specialization. If the compiler cannot figure out ahead of time what the types are that are being passed in to your method, it will have to do dispatch at runtime, inspecting the concrete types of the parameters before it looks up which method to call in the method table.

So you can see from this how there is no performance impact at all in not specifying the types; either the compiler knows ahead of time what the arguments are and can jump directly to the appropriate method, or it doesn't know and must do a dynamic lookup. If you were to annotate your method with types that wouldn't help the compiler to know what the types at the call site are; you would instead need to add type assertions at the call site (Which is occasionally helpful in tough-to-infer locations).

As an aside on the expressiveness of parameter type annotations, my mysum() method commits the sin of assuming that the accumulator variable should start its existence as a Float64. Realistically, it should start life as the zero type of whatever is contained within data. If I were to restrict this to only work on Vector types, I could do this easily with parametric types:

function mysum(data::Vector{T}) where {T} accumulator = T(0) ... end

However this would now not work very well for things like the hypothetically-user-defined LinkedList type. Instead, we can use the eltype() method, which returns the element type of any container object given to it (and which the user can themselves extend for their LinkedList type):

function mysum(data) accumulator = eltype(data)(0) ... end

The beauty of this is that eltype(), just like mysum() itself, is going to reap the benefits of type inference and most likely be completely optimized out of the entire function. An Example implementation of eltype() is the simple one-liner:

eltype(x::Vector{T}) where {T} = T Which simply returns Float64 for an input of type Vector{Float64}, and since the compiler can determine that mysum() itself was called with that Float64, we have a very well-tailored summation function that is now extensible to all sorts of types and does not have any performance issues despite its extensibility.

JamieHynemanAMA55 karma

Bro what the fuck

loladiro24 karma

This kind of reply on technical topics is not unusual in our community :).

LehighAce06458 karma

Have your seen any job postings requiring "3-5 years experience with Julia" yet?

loladiro644 karma

Yes, happens all the time, but Julia has been public for 8 years now, so that's not thaaaaat unreasonable. The funny ones are the "15 years of Julia experience" ones.

RoyiAvital214 karma

Julia is a truly real fresh approach to scientific computing - True advertising indeed :-).You have done amazing work to be proud of.

I was wondering about 3 things:

  1. If you didn't have the compatibility constraint of version 1, what would be the first thing you'd change in the language?
  2. What is the greatest potential (By changing the language) to gain the next significant step in performance in your opinion? What are you focused on solving to achieve that?By performance I don't mean things like Time to First Plot but actual running time.
  3. In the industry it is really important to be able to interact in current production code (Usually in `C` / `C++`). MATLAB solution for that is MATLAB Coder - Generator of static `C` code which can easily be embedded in current code (Either as code for compilation or to generate a static / dynamic library). Do you see in the future such capability form Julia? Generating static / dynamic libraries without the pre compilation overhead to be integrated into production?

Your work is really inspiring. Thank You!

loladiro87 karma

  1. Hmm, I'm not sure. In some respect, I don't feel the Julia 1.0 compatibility constraint, because there's always 2.0, so anything I want to change, I can just plan for now and we'll get around to eventually. I talked a bit about things I'd like to change here: https://www.reddit.com/r/IAmA/comments/hyva5n/we_are_the_creators_of_the_julia_programming/fzf3zni?utm_source=share&utm_medium=web2x
  2. Custom Compiler passes that allow you to make domain specific optimizations for your particular application. I think that could be huge and we could do really well at it.
  3. The canonical answer to static compilation requests is https://github.com/JuliaLang/PackageCompiler.jl. It's not quite there yet and we need to do some work to streamline it, but it does basically work.

MasZakrY87 karma

There are many multiple-dispatch-based languages out there (of course not as common) such as lisp. What was the reasoning for creating a brand new language instead of enhancing already formed tools?

loladiro102 karma

A lot of languages offer multiple dispatch as an optional feature, but very few languages rely on multiple dispatch as their core paradigm. The language that previously came closest was probably Dylan. The problem with multiple dispatch is that it is really, really hard to optimize well, so I think in languages where it is optional, you tend to run into a bit of a chicken-and-egg problem. Because the mechanism isn't super fast, people don't use it and because people don't use it, nobody bothers to go optimize it. That said, though, the design goal of Julia was not primarily to write a multiple dispatch language, it was to write a language that would be really good for computational science. Multiple dispatch just happens to be a paradigm that works well for that domain (because you need to work with lots of weird and complicated abstractions - numbers, arrays, devices, data structures - and compose them in complicated ways. Multiple dispatch gives you a good way to structure that. I think it would be fair to say that we were surprised how well multiple dispatch as a paradigm actually works when optimized well. We knew it would be nice, but it has turned out to be absolutely critical.

SorryToSay35 karma

As a layman among I imagine thousaaaaands reading this.

WHAT IS MULTIPLE DISPATCH?

I imagine a lot of us who never have coded "get" how coding works based off of instructions that propel instructions that propel instructions that is basically a task master of one dude sitting on a throne saying to his 70 worker peasant/slaves what to do and how to work together. That's my basic understanding of coding.

Now explain multiple dispatch to me?

loladiro106 karma

Programming languages translate between something the user understands and something the machine understands. The language determines how sophisticated that translation is. For example, the programmer may write `a + b`, and the machine will go off and do things. Now the difference between static dispatch, single dispatch and multiple dispatch is basically the following: If the language always tries to do the same thing, no matter what `a` and `b` are, that's static dispatch. If the machine looks at what `a` is to decide what to do, that's single dispatch, and if the machine looks at both `a` and `b` that's multiple dispatch. There's many reasons multiple dispatch is useful, but one of the primary ones is that it allows easy extensibility. Suppose you have two people, one working with cats, one working with dogs.

The cat person might write:

meet(a::Cat, b::Cat) = meow()

the dog person might write

meet(a::Dog, b::Dog) = sniff()

but what if you're neither of those people, but you got a dog from one and a cat from the other. In a single dispatch system, you'd have to go talk to the cat and the dog person and get them to change their code to something like:

meet(a::Cat, b) = if isa(b, Cat); meow(); elseif isa(b, Dog); growl(); else; error(); end

and similarly to the dog person.

In a multiple dispatch system, you don't have to go to either person, and you can just say:

meet(a::Cat, b::Dog) = growl()

There's lot of nuance here, but that's the basic idea. When I say "go to", I here I may or may not mean "go talk to". Sometimes it's a question of how you organize your code, sometimes it's literally a different person writing different code. It may sound a bit abstract, but the practical effect of being able to express things cleaner is really quite profound. Also of course in reality, the objects of interest aren't cats and dogs, but complicated matrix types, or equations, or weird number types or neural networks, or something like that, but the core problem remains. You don't want the person working on neural networks to also have to know about quaternions, but you may want to put quaternions in your neural network. The expression problem (https://en.wikipedia.org/wiki/Expression_problem) is the technical term of this extensibility difficulty.

Gobbedyret56 karma

Thank you for creating this great language, which I've been using regularly since your last AMA. My questions pertain to what I think are some of the major problems with Julia now:

  1. Currently Julia does not support inheritance (of the regular kind). This means that, if I want to "wrap" some type, e.g. create a Dict-like object with only a few methods changed, it requires overriding all necessary methods, which is a huge amount of code. Even worse, there is no way of knowing which methods to overwrite! In contrast, in classical OOP, this is very easy to do. There is a very old GitHub issue called "abstract interfaces", but nothing has really been done in this area. Are you discusssion mechanisms for either supporting classical inheritance, or for formalizing interfaces, such that leaf types can be copied?

  2. You've been making real progress on compile time latency recently (thank you for that). But while you work towards making compilation faster, we Julians are tirelessly working towards writing more and more Julia code and taller software stacks. For some applications the overall direction has been going the wrong way (try playing around with Turing or ApproxFun if you doubt me). What can be done to mitigate this development of longer and longer compile times?

Thank you again for your work.

loladiro46 karma

  1. I don't think we'll ever add classical inheritance, but we might do something around interfaces. It's a complicated topic (and a big change to the language) and it's not the most pressing issue, so it's not really actively being worked on. I do want to do better eventually, but I think we have bigger fish to fry in the meantime.

  2. Yeah the amount of Julia code outpacing the improvements in the compiler is a real problem (a good problem, because it means that people are using the language more, but a real problem nonetheless). I think there's several answers. One is that we're hoping to multi-thread the compiler in the not too distant future, which should be make things faster. Another answer is that I'd like to do more system image based caching, so you don't have to recompile things as often. Also, for the ML ecosystem in particular, our current AD frameworks are quite compile heavy, which I'm hoping to address in the next generation.

tarrosion34 karma

With 20/20 hindsight, what are

  • some design features of 1.0 you'd like to take back
  • some features you wish had been included in 1.0 (or at least didn't have to wait for 2.0)?

loladiro32 karma

Honestly, I'm pretty happy with how 1.0 turned out. There was a lot of churn pre-1.0 to clean up interfaces and get things right, and while I'd like to revisit some of them (I was just complaining about search/find the other day) I think that by in large 1.0 was a good release and in particular a good foundation for the 1.x series, where we've continued to improve things without needing to do breaking changes. There are some features that I wish that Julia had that didn't make it into 1.0, but I don't think I would have wanted to hold the 1.0 release for those features to become available. Among them are

I. Better abstractions for plugging into the compiler - We've had generated functions for quite a while now, but they're a bit limiting in what they can do and their over- and abuse has caused some problems. We should have better ways for people to precisely plug into the compiler and get done what they need. This is the big project I'm working on now, so hopefully we'll have something to play with for 1.x, but it probably won't be done until 2.0.

II. A better system for (im)mutability. We've talked about this for a really long time and I think we have some good ideas, but we haven't gotten around to implementing it yet. In particular, I'd like things to be basically immutable by default and then have well-controlled ways to do mutation (at least in library code, mutation is quite useful interactively). There's a fair amount of optimization potential left on the table due to mutability issues, as well as conceptual problems in some areas (e.g. automatic differentiation - what does it mean to take the derivative of a thing if that thing is later mutated - you probably want a "by-value" copy that, but that would be much more cleanly expressed with immutable objects).

tinosulzer29 karma

What is the business model for Julia Computing, given that Julia is open-source? And what did you do before creating Julia Computing?

loladiro47 karma

For the business model of the company (Julia Computing), there's roughly three parts:

  1. Helping people use Julia for their applications or problems (through consulting, support, etc.) and having them pay us for it directly
  2. Building additional tooling that people who need enterprise features or large scale or business critical deployments need and selling licenses (see https://juliacomputing.com/products/juliateam)
  3. Partnering with people building applications for particular domains that currently have bad software and selling better software directly to end users.

Before Julia Computing, the company, I was in college (but I started working on Julia, the language in high school).

retrovertt21 karma

what is a programming langue?

loladiro29 karma

Good question, a programming language is generally a set of rules for writing things down you want computed. Most programming languages (but not all) also come with a program that takes input written using those rules and actually computes the thing for you. I've written about it a bit here: https://www.forbes.com/sites/quora/2019/04/05/how-are-computer-programming-languages-created/ (originally on on Quora, but I'm not sure how their registration wall works these days - it used to be quite aggressive).

CerealPlayer20 karma

How would you recommend learning Julia? As a junior data-scientist working with R and Python I'm unfamiliar with the language, but I'm keen to expand my horizons.

loladiro17 karma

Have you seen https://juliaacademy.com/? We've been trying to get people who are developing educational content in Julia to bring that all together in a curated manner.

friendlycompguy18 karma

How far (and in what direction) do you think Julia has to go to be widely adopted for Machine learning (both research and production)? Right now, it's mostly just cpp and python. I've seen Flux.jl, but I'm not sure how it compares to pytorch. Is it just inertia of the industry that stops them from venturing into another language?

loladiro20 karma

In my opinion Julia has all the right ingredients to be the go to solution for machine learning, but I will admit that we are lacking a bit of polish. Part of the problem is just that it's hard to compete with efforts as well funded as Tensorflow and Pytorch. We only have a couple people actively working on this stuff. That said, I think Julia (and Flux.jl) is being used a fair amount for machine learning research (exploring new architectures, problem domains, approaches, etc.), because of its flexibility and the ease of trying new things (Flux.jl is only a few thousand lines of code, so it's easy to add new things). Because of Julia's excellent performance we also tend to to quite well in benchmarks here. The big thing that people currently don't do a lot in Julia is running big production machine learning tasks. That's mostly just because they've been tuned to hell in other systems so it's both hard to compete and even if you do, you offer little "extra" to convince people to switch. Our approach has always been that we want everything to be generic rather than special case tuning a few models (such that you don't fall off a performance cliff if you try something new), but as a result, things have probably taken a bit longer. That said, I'm optimistic that we will improve in this area in the very near future also. I'm working on a new AD system that should help with some of the performance problems on bigger models, and there's also work being done on memory management issues that have prevented training full batch sizes on some production models. I think it's just a matter of resolving those couple of issues, but we'll see what the future brings.

xor011015 karma

Love Julia, although sometimes it feels like we get the long compiling times and slow development cycle of C++, together with the silly runtime mistakes of Pyton (eg function call missing an argument). How can we make sure we are not getting the worst of both worlds?

loladiro10 karma

Are you using Revise (https://github.com/timholy/Revise.jl) for your interactive workflow? Usually people only pay the compilation cost once a day or so when they start their session, which is still a problem, but it's not quite as bad as a static language. I talked a bit about potential compile time improvements in a different answer: https://www.reddit.com/r/IAmA/comments/hyva5n/we_are_the_creators_of_the_julia_programming/fzfinzb?utm_source=share&utm_medium=web2x.

xor01105 karma

Unfortunately it seems I often do things that interfere with Revise. It has definitely helped me in some occasions, although nowadays I don't even try. I might be doing something wrong. It's hard for me to get help also, because it's not FOSS and it's also an "unusual" Gtk.jl project

loladiro6 karma

That's too bad. I hope that we can improve Revise to fix your use case, because while we'll continue to improve compile times, it'll never get to the level of interactivity that Revise provides.

darf13 karma

What are your favorite things in upcoming julia releases (1.5 and 1.6)?

loladiro9 karma

Time travelling bug reports! https://julialang.org/blog/2020/05/rr/

Aen-Seidhe11 karma

What GPUs are you targeting for parallelization?

loladiro10 karma

See https://juliagpu.org/. NVIDIA is the most mature option at the moment, but AMD support is being worked on by the MIT Julia lab. We're also working with Intel to have support ready once Xe comes out, but that's still a few months away.

tylermw89 karma

I think one of the main reasons why R has been such a great language for statistics and data science is the CRAN: A curated, central repository of R packages that enforces a set of minimum standards to ensure portability across platforms and avoid malicious/breaking behavior from user-contributed packages. What does the Julia ecosystem do/plan to do to support and manage user-contributed packages?

loladiro14 karma

Ironically, a lot of early R package developers came to Julia because they found the CRAN requirements to be overly imposing (e.g. demanding support for hardware architectures they don't have access to, etc.). I don't think we want to take such a heavy hand to curation, but we might want a way to highlight popular or high quality packages that meet some criteria (so don't prevent people from registering things, but just give more exposure to high quality packages). https://juliahub.com/ might be a natural place to do that. Maliciousness is a different question of course and all package registrations and version changes currently go through a waiting period where somebody usually looks at them. That's probably not super scaleable in the long term, but it works ok for now, so we'll revisit that when it becomes a problem.

SadRafeHours8 karma

What do you guys order at Macdonalds?

loladiro10 karma

I avoid McD. My parents thought it was unhealthy when I was young, so I never picked up the taste and it doesn't seem like starting now would be a great idea.

No_Step_0n_Snek7 karma

I saw your presentation at the Intel HPC convention in Denver a few years ago. What changed have happened since then to bring it beyond the astronomy field and into the mainstream?

loladiro6 karma

Great to have you. That was a fun project to talk about (for others that was the Celeste collaboration - write up here https://juliacomputing.com/case-studies/celeste.html). I don't think Julia was really ever an astronomy thing. There's a number of astronomers using it and obviously Celeste was a splashy project, but there's communities that are using it much more (e.g. mathematical optimization). I think it's just continued maturity and availability of the libraries that people need that helps push things forward.

tarrosion7 karma

What channels do the Julia creators or general powers-that-be use to ensure they're up to date on how common users feel? (Bonus points for people who tried to be users but gave up!)

I worry sometimes that on Discourse/Slack, all of the "recognizable names" are running 1.5 or nightly unlike the common folk still on the latest stable release. "The source is very readable and practically self-documenting, just check that" is common advice which, in expectation probably works better for the advice-giver than the advice-receiver. Etc.

loladiro6 karma

Obviously Discourse and Slack and GitHub are important feedback channels, because a lot of the "power users" that are creating packages for the whole ecosystem hang out there and making them productive is one of the best ways to ensure high quality for the end users also.

Apart from that, some of us do a fair amount of teaching (so get exposed to the "new user" view from students) and at the company, we obviously directly support a good number of commercial end users that tend to be more conservative than the average open source user.

AirportWifiHall56 karma

Is the Python Numba package the same thing as Julia or are there other differences?

loladiro5 karma

No, it's not the same thing. Julia is a completely new programming language. There are some similarities in that both share LLVM as a code generator, but Numba is still fundamentally limited to python semantics. That's a problem for a few reasons. One, there are some patterns in Python that make it hard to optimize, so if you support them faithfully, there's certain optimizations you can't do (or only with tons of effort) and b) even if you have a fast Python JIT, most of your code will still be written in C, which will always be opaque to your compiler and causes a huge performance boundary.

papersnowaghaaa6 karma

As a mathematician with little to no programming background (have algorithms, complexity, and a bunch of CS theory but no software engineering under my belt) getting into machine learning, taking into consideration available libraries, etc, would you recommend Julia over Python? Please excuse a novice question.

loladiro8 karma

Depends on what exactly you're working on, but I think for this use case, I can recommend Julia pretty unequivocally. Alan Edelman, who is one of the other co-creators of the language is a math professor at MIT (working mostly in random matrix theory) and his needs have driven a lot of the libraries and terminology of the language.

entangledamplitude5 karma

Are you happy with the kind of community participation that has developed around Julia, including particularly the pipeline of users maturing into contributors? (to libraries, and also the core language)

Have you given any deliberate thought to this aspect (post 1.0, if it’s relevant), and do you have any thoughts towards whether this ought to be a focal goal, and if so, how to go about it?

loladiro4 karma

Hmm, excellent question. We do try to make it as easy as possible for users to contribute fixes to a package (just `dev` it in the package manager, and once you're ready submit it as a PR) and we have a few structured ways to get new people into the community (e.g. through GSoC). I'm sure we could do more, but people's time to set these things up is always a limitation, both on the administrative side and on the technical side to get people feedback. If you have ideas, I think we're all ears.

wereman5 karma

How is the developer tooling with Julia? I find this is my #1 reason for not using more of a variety of programming languages. There is such variation in terms of the quality of things like intellisense, live debugging, editor integration, etc.

loladiro6 karma

It's getting better, but I wouldn't say it's mature yet. I feel very strongly about developer tooling, so this is something I'd like to see us be awesome at, but we've got some ways to go still.

danxorhs4 karma

How do I even get started to learn at all?

loladiro4 karma

awksomepenguin4 karma

How does creating a new programming language actually advance computing and not just do this?

loladiro6 karma

If you're gonna do this, you better have it be 10x better at something, otherwise you're just part of the problem. In the case of Julia, I'd like to believe we've achieved that, but it has of course taken more than a decade and likely tens of millions of dollars if you added it all up. It's definitely no small or easy decision.

atypicalbit4 karma

I have these two things in mind:

1) Does Julia have any kind of package for symbolic mathematics, along the lines of SymPy in python?

2) What are your most favourite music bands/influences?

loladiro4 karma

  1. Several. If you just literally want the same feature set as SymPy, just use it from Julia: https://github.com/JuliaPy/SymPy.jl ;) If you're doing number theory, try http://nemocas.org/, which is a big effort out of Germany. And of course to some extent Julia itself is a toolkit for doing symbolic mathematics.
  2. I listen to a lot of things. When really focusing, I usually prefer classical or epic film scores. Since I do a fair amount of dancing I also like to listen to danceable music a fair bit, just to train myself to quickly catch the beat. For Latin social dancing, that tends to overlap with Latin Pop (e.g. Luis Fonsi). I'm also quite partial to musical theater.

yerroslawsum4 karma

Hi, I'm completely unacquainted with the... coding scene, if I can say that.

I'm curious about a few things:

- What would make someone create new coding languages out there? What's the goal you guys are trying to achieve?

- How hard is it to "enter the scene" with other languages present for you? I'm guessing that it quite literally depends on the frequency of use which, in turn, depends on reach. Are there areas where you guys can excel and "capture a niche to grow"?

- How hard would you say your language is to learn? If one wanted to get into the whole scene, would your language be a good start?

//

Gah, I checked other replies after posting and apparently your language isn't new at all. :O Sorry for the assumption. But hey, if you guys are up to it, just entertain the idea that it was. So, hypothetically speaking. :)

loladiro4 karma

It's new-ish, about 10 years old at this point (most programming languages are 20-40 years old). The motivations are listed in this blog post: https://julialang.org/blog/2012/02/why-we-created-julia/. As you might imagine, convincing people to switch programming languages is hard - they'll have re-learn a lot of things, and maybe re-write some things, so you really need to be significantly better to convince people to switch. Whatever the case may be, creating a new language that is competitive with those used for real world systems will take hundreds of programmer-years worth of work and millions of dollars (so you better make a good one if you're gonna try).

As for how easy it is to learn, we hope the answer is very. It is used extensively in teaching, particularly in the sciences where it may be the students' first exposure to programming.

ExeusV4 karma

What's the difference between language designed

by person/team with not strong background in theoretical CS (aka step by step, feature by feature and so on)

and person/team with an actual very strong background in theoretical CS (more mathematically/formally designed?)?

It's about ability to formally prove its correctness or something?

loladiro8 karma

I don't think languages designed by either pure CS people or pure applications people tend to end up very nice to use. If the language is designed by CS people, it has all the bells and whistles, but you end up with beginner documentation like "I/O operations are performed as monadic transforms over the input representation", at which point end users just start running, so you never get any interesting use cases that could actually test the boundaries of the language. On the other hand, if the language is written by the applications people, it'll be super useful, but as a CS person, you just go "Oh no, no, no, no" when you look at the semantics (mostly for reasons immaterial to why the language is nice to use - but impossible to fix once it's been around long enough for the CS people to get interested). You really need to have a mix of folks to design a good language and I think we've been fortunate enough to have that. Unless you're doing a theorem prover, I don't think trying to prove the correctness of your language in any formal way is all that important and eventually the CS types will comes along and do it for you anway, since they enjoy that kind of stuff (but as I said, you should at least have a few of them early on to avoid stepping into any sinkholes, you won't be able to get out of).

Doge_Business4 karma

How do you even code a coding language? Do you have to use a different code language?

loladiro4 karma

I've sent this elsewhere, but I wrote about that in https://www.forbes.com/sites/quora/2019/04/05/how-are-computer-programming-languages-created/, happy to answer follow up questions.

TROPiCALRUBi4 karma

Since you say Julia has achieved the speed of C and the simplicity of Python, would you say this language could make C obsolete?

loladiro7 karma

No, C has a place in the world (I actually think C is a much simpler language than Python, but that's using a different notion of simplicity than people mean when they say Python is simple). Rust has a better chance to obsolete C, but it is also not particularly "simple".

gemengelage4 karma

Which languages do you draw the most inspiration from?

loladiro5 karma

I think it's fair to say that we always like to look at other languages and see if there are any good ideas we can make use of. Much of Julia is in the LISP tradition of languages, but with a syntax more familiar to users coming from the mathematical programming world, so obviously there's lots of inspiration from those communities. Since that answer is a little boring, let me point to some things that Julia doesn't have yet, but that I like in other languages and I want to draw inspiration from at some point in the future:

  1. There was a little known and now discontinued language out of facebook (http://skiplang.com/) that had some strong opinions and special syntax for dealing with mutable vs immutable objects. I've been meaning to do something about that in Julia, so that's certainly a place to look at.
  2. I also like Rust as a language, though their philosophy is a bit opposite ours with the compiler doing strong static enforcement. I don't think we'd ever do anything like that, but I think some of their terminology and approaches could be useful if we want to have the compiler start reasoning about lifetimes more.
  3. I find formal methods tantalizing, but whenever I use them, I get assembly language flashbacks, because you just have to be so explicit about everything. One project I looked into a bit a year or so ago was F* (https://www.fstar-lang.org/), which I think has some interesting ideas, that I'd like to see if we can bring to Julia (optionally of course).

F_D_P3 karma

What would Julia tangibly give someone over Python? Coming from C, C++ and C#.

loladiro4 karma

Performance. Assuming you're leaving C++, for a good reason, if you use Python, you'd probably find yourself back there sooner rather than later, because Python isn't fast enough. And now you have two problems ;)

tarrosion3 karma

What do you see as the advantages and disadvantages of the "let a thousand flowers bloom" approach to the ecosystem? Are there any changes planned to gently adjust the balance between consolidation and experimentation?

(Context: I'm a happy Julia user but at times can be overwhelmed when there are many superficially similar packages accomplishing similar goals. I perceive that often the packages take very different approaches under the hood, but as an end user these distinctions are somewhere between invisible, confusing, and irrelevant.)

loladiro3 karma

We do try to encourage collaboration, but in the end it's a new language, so you gotta let people explore the design space to see what works and what doesn't. If one approach ends up being clearly superior, I think that approach will win out in the end, things just haven't had enough time yet to shake out that way.

Arkzath3 karma

Can it be used for solar cell simulation?

loladiro4 karma

I am not sure of anybody using it for solar cell simulation in particular, but I do know of a number of materials science applications that are quite similar. I wouldn't be surprised to see solar cell research also though, since it's in the domain of things that Julia is really good at.

MrRavenMan3 karma

What’s your favorite food?

loladiro6 karma

I'm not sure I would say I have a favorite food. There is lots of food I like, but if I keep eating it too much, I stop liking it for a while. That said, during the pandemic I've settled on having Müsli with fresh pear, raisins and Yogurt for breakfast each day (except today, because I'm out of ingredients) with varying dinners, though I do tend to get take out from them local Indian restaurant quite frequently (to which I like to add feta and fresh mango).

MileHighScrub3 karma

How do you like your eggs?

loladiro7 karma

Scrambled with plenty of black pepper, some onions, roasted potatoes, some feta cheese if I have it.

turbotong3 karma

How'd you avoid this problem?

https://xkcd.com/927/

loladiro7 karma

By not creating something because there's too many competing things, but because all the competing things weren't good enough for us ;). Then the question is how do you win and the answer is try to be better.

SFM613193 karma

Hi! Why would you make the first index = 1 and not 0?

loladiro8 karma

Well, first, I mean zeroth, it's traditional in mathematical computing languages to start array indices at one, and second, I mean first, the difference is whether indices are ordinals or offsets. In Julia they're always ordinals and generalize that way, so we don't do offset indexing.

gaj73 karma

Can you explain why you decided on a dynamic type system? I get that it is par for the course among popular scientific computing languages, but is there a reason for this? Are dynamic types somehow a good fit technically for this domain? Do dynamic types appeal to the demographic?

Disclaimer: I'm a Haskell / Standard ML fanboy. Types are comfortable for me, and I don't get how other programmers prefer to push them out of sight. Yet I know a lot of people do prefer the dynamic approach, so I must be missing something.

loladiro5 karma

Dynamic languages help with interactive exploration, because they explicitly allow deferring checking of invariants until runtime. As a result, you can interactively refine a somewhat correct program into a correct program, while looking at output, exploring options, trying alternatives, etc. If everything is static, the iteration cycle for these kinds of things is usually much longer.

YeetGod822502 karma

I think Julia will become much, much more popular than it is now. Because of that... would you recommend any online courses on Julia?

loladiro3 karma

Thanks we hope so (and perhaps the 10k attendees at JuliaCon this year are some indication). We've been curating courses on Julia at https://juliaacademy.com/, so that may have what you need.

nDream2 karma

Silly question. Can Julia be used for game dev? Is it beginner friendly?

I want to teach myself how to program, and was thinking of learning by creating very very basic games.

loladiro2 karma

In theory yes, but it's not a focus area for the community, so a bunch of the tooling you'd expect is missing. I think as a beginner, picking a different area would be better if you want to learn Julia. For Game dev, you usually want to pick some system that comes with a language and all the game dev tooling you need (art/world editors, etc.). It is obviously possible to do a game from scratch (that's how that tooling was built afterall), but it's a daunting task, so using pre-made tools is probably a better way to get started.

HoboOfTheSeas2 karma

In computer forensics. I love to use python as a tool to help investigate.

How would Julia benefit those in computer forensics and security?

loladiro2 karma

Julia should be able to do all the things that python does, no problem. I think the point at which you'd really start wanting to use Julia is if you want to analyze bigger data sets (e.g. large network traces) or run more complicated analyses that are hard to do performantly in python. Of course there's also a whole machine learning based subfield to computer security now, so that might be an area of interest also.

73mm1n2 karma

What are your all's favorite cake flavor?

loladiro3 karma

Does pie count as cake? If so, lemon meringue. Otherwise, probably apple sheet cacke.

kirsebaer-_-2 karma

Hi

I know a lot HTML, some CSS and have started with JavaScript. Eventually I'd like to become a pen tester or bug bounty hunter. I was told to learn C and Python since I would be able to make my own tools then, and it would give me a good foundation. Should I replace Python with Julia? Is there any point to learn Python instead? I hope my question makes sense.

loladiro4 karma

I think that's a decent idea. You probably still want to learn a little bit of Python to make sure you can read it, but Julia should be able to do all the things that Python can and more (Plus you can always call any Python code from Julia using https://github.com/JuliaPy/PyCall.jl).

Emerald-122 karma

I have considered learning coding (python) as a mere personal curiosity. I have never heard of Julia before, is it something I should look in to, why/why not?

loladiro3 karma

I'd like to think Julia is a good language to learn programming with, but obviously since it's newer, there may be fewer resources available (it's always important to match resources with the correct background a person has). See if https://juliaacademy.com/ has anything of interest for you. Personally, I find Julia the most fun language to write in , which I hope is a good reason to use it :). Ultimately what language to learn first depends on what you want to do with it, so it's hard to give specific advice, but if you just want to play with something in general, I don't think you can go wrong with Julia.

Explicit_Pickle1 karma

So who is this Julia gal anyway?

forsakenquantum1 karma

I'm really excited about the possibilities of Julia and have used it in several projects. I find I end up going back to Python often, though, because I find the scoping rules in Julia to be pretty confusing and difficult to debug when something is wrong. Are you committed to the current way of scoping, and if so, why do you think it's best?

loladiro2 karma

Depends what you mean. Julia 1.5 will bring back soft scope at the REPL, which has been one of the primary scoping complaints in the 1.x era. Beyond that, I suspect there won't be any new scoping changes in the near term. If you want to know the rationale, you'll have to ask about a particular aspect of it.

forsakenquantum2 karma

I think the two main things I ran into were 1) if I declared variables at the top level in a script that wasn't wrapped in a module and then tried to change them in a for loop, the changes wouldn't hold after exiting the for loop, and 2) it seemed like I had a similar problem inside a function, where a variable declared outside a for loop couldn't be modified by it. The first one was frustrating but at least I could work around it by wrapping things at the top level in a module, but the second one was confusing as to why it was happening and how to fix it.

loladiro2 karma

For 1), if the loop itself is at global scope that will be changed by soft scope in the REPL, for 2), loops do modify the outer variable in local scope (which is why 1) was confusing), so I'd have to see an example to say what the issue is.