Julia as first language

Thank you all for this great thread. It’s rich in ideas and point of views.

If I may add something, education is not a one-side-fits-all. So, what a good first language to learn is depends on many different factors.

  1. How the student is.
  2. What education background they come from.
  3. What they are trying to learn.

Or, to be more cheeky, not everyone is a freshman computer scientist trying to become a software engineer. :smile_cat:

I did teach Julia to university students with no programming background. They were in a path toward becoming “applied data scientists”. And they needed to learn how to wrangle data. They also needed to learn that most concepts and techniques in data wrangling are not language-specific (i.e., no, data frames are not just R things, and no, web scraping is not just a Python thing). Julia was a great experience (and I started teaching this course in 2018, so there was still a bit of instability in the language).

One great thing for them was the broadcasting and the fact that loops are not slow. That allowed for a “we build a function for an example input, and then scale to many inputs” kind of workflow.

In general, for students coming from a strongly mathematical (largely written) background, Julia is very pleasant as it lowers the jump from “how I would think and write this in mathematics” to “how I would write it in Julia”. They don’t usually care so much about “the machine” nor whether Julia is dynamic, OO, functional, compiled, … Maybe some will get curious, but others just want to code to prove their ideas. They are not becoming software engineers, they are becoming mathematicians/statisticians/biologists/psychologists/… who code (sometimes very well, and very complex things). And you don’t want to enter a classroom of biologists and try to teach them C.

PS I don’t teach that course anymore but I’ll be teaching one on Data Engineering next semester, where I will try to include as much Julia as possible, send me ideas :bulb: if you got any or you are keen to be a guest.

PPS there are biologists who are C wizard and witches, and would code you up a storm, no disrespect meant. It’s only a question of priorities.


My view on this is that Julia’s base API and standard library is opinionated on being “right” and “efficient” over being “easy”. There are also some inconsistencies due to evolution of the language and community design. I could enumerate them but many others have already done so and doing so will distract from the actionable steps.

If we would like Julia to be easy for new programmers, I suggest a Basic API package. The Basic API should value simplicity over all else, with ample documentation about why it may not be the most correct or efficient way of doing things in auxiliary help sections.

Here are some thoughts about what what that might entail.

  • Minimal direct use of type parameters.
  • Minimal use of curly braces.
  • Minimal use of macros.
  • Minimal use of in-place functions or any modifications of arguments.
  • A simple array constructor with no undef. E.g. emphasize zeros.
  • Ample use of keyword arguments when there is any ambiguity.
  • Use the minimum number of types.
  • Avoid use of generators and other “lazy” types in favor of their eager equivalents. e.g. collect everything.
  • Use if else rather than try-catch when possible. This may mean returning nothing and introducing type stability.
  • Use for loops rather than broadcasting or other reductions or folds.

This effectively would look like a distinct language but it would still technically be Julia, and that’s a place to start. Some will argue this is not Julian, not idiosyncratic Julia. That’s fine because this sublangauge has vastly different objectives. In particular, the main objective is to introduce basic programming to someone with no programming background.

What’s neat is that I think this is quite possible for us to create a BasicJulia dialect.


That looks pretty much what I do most of the time… maybe except for the broadcasting.


I think this vastly underestimates new programmers to their detriment. I do agree broadly that people should be eased into features, but a separate package that omits too many features also omits basic concepts people can easily learn and frustrates them with limitations. I am confident that people would hate to read the auxiliary help sections after all their effort going through what is effectively a tutorial, and realize that they didn’t really learn idiomatic Julia because the package authors didn’t think they could. Meanwhile their peers starting Python got to mutate a list on day 1.

Instead, I think those guidelines should be repurposed toward designing a beginner’s tutorial with many code examples, and those guidelines are progressively dropped as new concepts are introduced. It’s a matter of whittling down examples concept by concept, while keeping the code idiomatic and practical. People should leave the tutorial able to explore code and navigate packages on their own, not get blindsided by idiomatic Julia.

  • People can definitely understand argument mutation and initializing undef arrays, it’s not hard.
  • Type parameters are something you want people to grok early on, especially if they’re coming from Python where element types are shoved in arguments and attributes. You don’t want people ad-libbing type parameters in weird ways.
  • I think macros should be introduced early on, but very quickly and not how to write useful ones. It’s useful to explain that expressions are parsed and evaluated one by one, that macros transform an expression during parsing, and that macros should not be designed to replace existing structured expressions and higher order functions. Then it’s fairly safe to let people use macros. I see many users thinking @dothis(x) is just another function call, sometimes despite having seen others call @dothis a “macro.”

As for the overall question, it depends on first language for what purpose. Just any programming? Sure, Julia will get people thinking about types, functions, and structured programming as much as any other language. But for microcontroller enthusiasts, no. There are also many distinct paradigms, so if someone wanted to lean into object-oriented languages with statically typed variables and pointers, then definitely not.


That sounds like the first great idea! :smiley:

Still, I would question if that wouldn’t make more sense for a library, that is entirely dedicated to this purpose of education, and not touting it as some kind of productive library.

I also discourage everyone from writing stuff like, “why this may not be the most efficient way” and something of that sorts. The last thing I want to know, when learning new things, is that I am actually doing it wrong, or somehow not good enough.

Just imagine you are teaching your kid bicycling, and as they are doing that, you tell them,
“The grown-ups use no support wheels, and until you don’t use them, you are not really bicycling.”

Just tell them how to do it without support wheels in a later training session.

I absolutely agree with you here :smiley:

I think immutability, and immutable data structures as such, are much more sensible to teach at first.

We are talking about Julia as first language, so they dont come with baggage from Python.

Could we say, that this simply comes down to teaching them how to use macros, and not how to write them?

1 Like

Teach beginners about macros, that is, they should be aware that macros are not function calls and each one has independent syntax, but teach them not to write macros. IMO macros are hugely overused and writing a macro should require a license, so to speak. Pehaps it would be beneficial to disable automerge of general registry PRs for packages which define public macros?

1 Like

I think it’s mostly a pedagogical issue.

If you need to prevent them from committing stuff that uses macros, you are also admitting that we failed to communicate, why we don’t use them for their use case.

That only covers our miscommunication.

It reminds me of Elm.

People there are prominently exposed to absent type classes, and some people literally wrote violent threats about that decision. Evan, the language designer used them in the language itself, but deemed them to be too powerful, to be used as part of the language.

Clear split between usage internally and externally. People didn’t like that. I think it’s a smart decision.

You don’t need type classes, to implement frontend web apps. :man_shrugging:t3:
Elm did choose to not provide those complex features to the people, since they knew, it would abuse them.

F# and other languages deliberately did the same, to keep the language simpler, for the purpose of simpler codebases. While they are advanced languages, are capable of implementing macros and first class modules, they deliberately stay away from them, to prevent abuse.

Nim has superb macro capabilities, as it is also homoiconic at its heart, and people are abusing macros as well. And macros are advertised on the front page, and touted as one of the key features.

So we can choose, supposedly, between abuse of power and no power at all.
I simply don’t think that is a good split. I think we can do better. :wink:

The documentation makes a very good job, to warn about macros right now.

I think it’s sufficient, to tell people, that using macros is a beginner topic, and actually implementing them is a topic for people who are on the opposite side of experience. :slightly_smiling_face:

So, I think splitting it into two - using macros and writing them - helps to avoid the dichotomy of overusing them and presenting them as a solution.

It would let people feel involved, and as a part of the family.


The more I think of it, I think it may be beneficial to ping someone, and set a tag.
When someone commits stuff that contains a macro, simply set it to macro and let people inspect it. I would also create a message, that reads like “are you sure… these are the implications”

But outright preventing them from committing, is too steep, imho.
It feels too strict.

True, but I think a first-language tutorial should also serve as a beginner’s tutorial for people coming from other languages too. It’s far more likely that someone encountered another more popular language before Julia anyway, and no tutorial should ignore these people and tell them “don’t read me.”

And here people should be told about stack memory. Heap memory is talked about when mutable types are introduced later. But it won’t take long for people to get to an explanation of heap memory.

1 Like

It is not necessarily about teaching new programmers. Maths & CS students are not the same as e.g. biologists who also need to learn say how give an injection to a lab rat. Those others cannot be taught to the same curricula as programmers, still many of them are taught the basics of programming, and Julia could be made suitable for this purpose.

1 Like

As someone who is coming from the perspective of a user, that is new to programming, and likes to pick up a modern language in the first place, I cannot tell you how tiring this is.

I cannot count anymore, how often I heard about the details of what object orientation is, by the hundredths’ person telling me what it not is, in contrast to functional programming.

And only by that.

There is a place for “I am coming from Python, I am interested about Julia” tutorials.
They are beneficial, and I recommend doing them.

I like how they are done in Gleam.

And please, for the love of god, spare the people reading our tutorial are already a programmer.
And that automatically happens, when you are considering them to be Python programmer.

This is one of the most pervasive misconceptions, and one that entirely destroys the whole purpose of a beginner introduction.

People who are programming in Python for years, are not in the same ballpark of those who use Julia as a first language.

Introduction to computer programming should not require Python skills.
As an introduction to Python should not require Julia skills.

There is a distinct place for all of them, do not mix concepts, because it seems they are all beginners from your perspective, as their perspective is likely to be different. :slightly_smiling_face:

A language, supposed to introduce other people into programming, should reduce possible confusion and distraction. And that means, you omit everything that is not absolutely basic to the understanding of the feature at hand. In order to understand how to build a function, I dont need to know how its done in Python.

That’s way too early. Low level details like stack and heap should not be on a beginners mind at all.


I think it already is, conditional on the student(s) actually having to write code for which Julia is a good match. If this does not hold, I don’t really see the point if teaching them Julia. There are great scripting languages out there for calling canned procedures, eg R (data cleaning, making plots, simple data analysis).

Again, please see https://bisc195.wellesley.edu. In one semester, I had bio students go from “never coded before” to writing a package that compares and analyzes coronavirus genomes, writing unit tests, commiting things to GitHub, etc.


I agree, I do not think a Julia tutorial should explain paradigms that don’t exist in Julia. After all, the tutorial isn’t specifically intended for people who know other languages either. My earlier statement meant we shouldn’t omit easy details for simplicity’s sake because people’s preexisting programming knowledge can skew them into misconceptions, especially since they are more likely to attempt experimenting with code. This is a good clarification.

I disagree. We certainly shouldn’t go into much detail. But you’re not going to understand why some practices matter if you can’t at least imagine main memory as a virtual sequence of bytes and know how efficiently memory is freed on the stack versus the heap. Arrays won’t make sense, you won’t know why people tell you to use immutable types instead of mutable types, you won’t know why @time reports “allocations” or what they are, you won’t know why reassigning that variable to a different type caused allocations. You’re right that implementation details are mostly unnecessary and confusing at the beginning, but ZERO implementation details are also baffling. The little bit is not hard for a beginner to pick up, and it’s harder to pick up other things without it, I can say that from personal experience.


Yes, that’s my point to. Whether a person has coded before is just one factor that determines whether Julia is a good language for them, and perhaps not even the most important one.

Motivation, intelligence, attention to fine detail, perseverance, and last but not least having a good instructor are IMO much more important for getting benefits from Julia than whether it is one’s first language or not.


And lots of other disagreements…

I would like to propose that there may not be one tutorial to rule them all. And that’s fine. I’m not going to teach my bio students about macros or stack / heap etc, because I’ve been using Julia effectively for ~6 years, and I barely understand them. Others may have different opinions / experiences, and you know those best, so your approach can be different.

I would further like to propose that, at this point, discussions about lesson content might best be had on a repo with actual content. I think there’s consensus that julia can be a good first language. So go forth - make it so!


I mean, same here. I don’t know what’s in a stack frame and I can’t tell you how any operating system finds free memory. I’m talking about literally cartoonishly little detail, more grunting “computer like compact memory, I write this to compact memory”, less systems engineering. For example, having a diagram of a square attaching to a chain of squares to represent push!ing an element to a Vector{Float64}, or Vector{Any} having squares with arrows to distant blocks to represent references. I remember my confused phase learning NumPy, and such diagrams really helped me through it.

1 Like

This is fine (we all have priorities), but note that a lot can be learned about this in a few hours. Same applies to macros.

1 Like

Correct me if I’m wrong, but it seems to me that we’ve all converged on the same answer: Julia is a great choice for a first language. Maybe not the only choice, and the “best” choice is a different discussion.

Now it seems like the discussion is mostly, what is the best way to teach julia to non-programmers? combined with “what tutorials exist or need to be created to teach non-programmers?”

I will go out on a limb and say most of these resources do exist Just go to the JuliaLang.org Learning page! Perhaps these resources aren’t touted enough, but there is certainly enough material to teach beginners from different backgrounds. It even covers different ways people learn from RTFM to tutorials to full length books to YouTube videos. The JuliaLang YouTube tutorial playlist alone has 9 entries with a total of 103 individual videos.

Given all the information that is currently out there, is the issue simply that people don’t know where (or how) to look for it? Maybe the JuliaLang.org homepage needs to be edited to put learning resources front-and-center? Are the resources out-dated and not helpful anymore? :man_shrugging:


Well, the discussion has always been about the willingness of community members to commit to Julia as a first language. :slightly_smiling_face:

I am not saying this is not the case, I am not saying Julia is not a good first language.

I do observe, that it is in practice a very science oriented language.
It’s enough to look into this forum, any blog post about it, and every article surrounding it.

So I question, if all the cornerstones are already at their place. :slightly_smiling_face:

I definitely think, that the potential is there, and it still doesn’t take a psychic to see,
that Julia isn’t used like that.

And I think that has a lot to do, with how we see newbies. And I think the Julia community sees newbies mostly in the form of students, who have to program, and who might as well do it in Julia.

And we would probably all agree, that this is a quite narrow definition of a newbie.
I would rather introduce people from other backgrounds to the language.

And I like to know, if I am alone.