Python is just such a weird language in general despite its popularity that I honestly cannot recommend anyone who starts programming to choose Python as their first language, contrary to popular sentiments. I mean, I was one of the first person to start using Python when I was in grad school almost a decade ago when everybody else in my field was still using Matlab for their lab code, for the simply reason that Numpy was less awful than Matlab and I needed something that can easily print graphs to PDFs.
The only thing good I can say about Python nowadays is that it's easy to get started for the first five minutes, and then you'll have to deal with all of its weirdness: significant whitespace, truthiness, duck typing, GIL, distribution/packaging, etc, etc.
I was a big fan of Julia as the potential replacement for Python for science for such a long time and I had evangelized it a lot previously, but recently I've been more and more convinced that JIT/multiple dispatch was only good if you already know how to program well to begin with, which for a lot of academics who are not working in computer science, they write quite horrific code. I think it may be better off to skip Python altogether and write your code in a statically typed language to begin with.
I think Python remains a very good intro language for getting kids in the door because it doesn’t demand too much tedious stuff, is flexible, and lets people actually solve problems rather than doing computer science.
In my experience the difficulty is understanding what exactly is important when teaching someone something new. And it largely depends on the goals. What you’d teach some biology undergrad is going to be very different from what you teach a bunch of robotics team high schoolers (and no you’re not teaching them the best language for controls and embedded).
What is the best language for controls and embedded, in your opinion? I assume from your comment that it's not a great choice as a first language to teach newbies, but I've never done anything in the field of robotics or embedded stuff, so I'm quite ignorant in that area.
If I'm not allowed to toot my own horn, I think for controls, you probably should not start with choosing a programming language, the first step is learning control theory and automata theory, you kinda have to understand feedback control/PID/steady state/jitter/hysteresis and the like. Python has never had great control libraries to begin with as far as I can remember (my info could be a bit outdated though), so the paid option is still Matlab/Simulink as it is their last niche really.
Embedded firmware, probably C/C++/Rust. Not the answer you want to hear, but these are the languages for bare metal applications. Of course, if you are just using an Arduino/Pi, just use their SDK for their hardware on whichever language they support.
Those two fields are just not very friendly towards beginners in general.
Sure, short list:
- Easier to write than Python other than the simplest script, almost no way to write bad code and have it compile, reads like pseudocode most of the time
- Compiles into Go binary, runs at Go speed, compiles at Go speed
- Trivial to wrap any Go library via LLMs, so any Go library is also an Oct library.
- Can metaprogram existing Go codebases, so it doesn't really replace Go, just supplements it
- Easy concurrency/parallelism
- SI units as types
- Can be used as build script for C/C++ in place of CMake
- Einstein tensor notation
- Builtin GPU acceleration via Vulkan
It was designed as a teaching language for academics to stop writing bad code, but now I just get LLMs to do research/science for me with it for fun.
Yeah! Like when helping teens set up PID controllers for their CAN-bussed robot, it was very much a "we've got a lot of example working Java code with a PID Controller library already. So we're using that." The language itself is so inconsequential at the early stage, that you really just pick whatever gets in your way the least.
None of them. Walks away. Stops. Turns. All of them.
It depends. If you're a teen I'm mentoring, you're probably starting with some Scratch to drive Lego robots around. Then on to Python to drive the same robots around but now with more fun!. Probably because you absolutely couldn't stand the standard line follower solution of jittering back and forth and you sniffed out the existence of better control loops you cannot realize in Scratch. If you're on the FIRST Robotics team you're probably doing Java or Python, mainly because that's just what we've geared up for (and this is really the core theme for me at least: at introductory levels, what really matters most is whatever is most readily accessible to you and whatever kit you already have).
If you're doing your own stuff and you're a newbie with absolutely no opinions on where you started or what you were trying to do, you'd probably start poking around with an Arduino or similar, so you could write MicroPython (it's Python but you squint your eyes a bit!) or C. There's so many great kits for beginners.
In the context of my comment: what I meant is that you wouldn't decide, "the professionals do it in C++, C, or Rust, so we'll start with one of those." I'm going to give you a recorder (Python) before I hand you bagpipes (C++).
If I'm teaching you programming and you've learned Scratch, I'm going to hand you Snap! (https://snap.berkeley.edu/) next. Because it's Scratch, but with the artificial limiters removed. Snap! (the exclamation mark is part of the name) allows you to store lists in variables and pass them as inputs to functions, and it has the standard list-handling functions you'd expect, like filter and map. Moreover, it also allows you to store blocks (functions, basically) in data structures and pass them as inputs to other blocks, so you can actually learn to write code in functional-programming style.
Once you learn that Brian Harvey, one of the two main designers of Snap!, was one of the principle people behind Berkeley Logo (which itself was a variant of Lisp, though that wasn't clear to me when I was learning Logo at age eight), it all starts to become clear. Snap! is itself nearly a Lisp, just lacking macros (and Brian Harvey is trying to figure out how to add a macro system to Snap!, with the primary challenge being making it comprehensible in graphical-blocks form).
We’re spoiled with great options. My kid jumped right from Scratch to JavaScript for game dev because he loves how he can put his games on the Web easily. Huge props to Microsoft Make Code Arcade for allowing you to port your Scratch to JS. It gave him a powerful way to see what he knows and how it looks like in JS.
Are academics who are not working in computer science interested in learning statically typed programming languages?
In the past, the usual answer to people who need a programming language but did not want to learn programming was to give them a domain specific language that focused on solving the specific problem they wanted to solve.
Well, many times in my field of mechanical engineering, they have to, because CFD and FEA are very performance sensitive. The professors I had were still writing FORTRAN and C++ before, but maybe they've switched to Rust now.
> I honestly cannot recommend anyone who starts programming to choose Python as their first language, contrary to popular sentiments
> I think it may be better off to skip Python altogether and write your code in a statically typed language to begin with
Having a good REPL is a huge advantage for beginners (and expert users too), but I'm not aware of any (popular) statically-typed languages with a good REPL.
Despite Python's many faults, it's easy to install (especially on Windows), it has a large standard library, there are third-party packages available for essentially everything, it comes with a user-friendly REPL out-of-the-box, and it gives comprehensible error messages. I'm not really aware of any other (popular) languages with all these attributes.
> Having a good REPL is a huge advantage for beginners (and expert users too), but I'm not aware of any (popular) statically-typed languages with a good REPL.
scala's repl is decent. It has its annoyances, but so does python's (white space sensitivity + repl + terminal emulators stuck in the late mid century don't mix).
I hate Python and I'm onboard with putting it down in many ways, but significant whitespace isn't weird in a first programming language. It's only weird if you've absorbed from some other language the convention that whitespace shouldn't be significant.
Haskell, Lean, and Agda too. But even if Python were the only one, it wouldn't be weird to someone for whom this was their first programming language. It would just seem the way programming languages are. There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read.
> There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read.
The idea is fine, I guess, although I certainly don't care for it. Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.
> Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.
First off, what editor could I end up using in 2026 that makes this a realistic problem? Even the most basic editors I know of have options to convert tabs to spaces automatically (and any responsible teacher will tell the student to indent with spaces), and to continue the previous line's indentation automatically.
Second, modern Python is stricter about this, and also gives clear error messages.
> and then you'll have to deal with all of its weirdness: significant whitespace
By "weirdness" here you apparently mean not having to worry about matching up curly braces, and getting what you want automatically just for indenting your code the way you're supposed to indent it anyway... ?
> truthiness
Which is different from how it works in other similar languages, how exactly?
> duck typing
Which is weird, how exactly?
> GIL
You can go a lot further than five minutes in Python without having to worry about threads at all, and if you do attempt threading, unless you're writing C extensions, the worst thing the GIL does is deny you the multi-core processing you thought you were going to get.
> distribution/packaging
Tons better now, but it was honestly never difficult, people just didn't care.
The only thing good I can say about Python nowadays is that it's easy to get started for the first five minutes, and then you'll have to deal with all of its weirdness: significant whitespace, truthiness, duck typing, GIL, distribution/packaging, etc, etc.
I was a big fan of Julia as the potential replacement for Python for science for such a long time and I had evangelized it a lot previously, but recently I've been more and more convinced that JIT/multiple dispatch was only good if you already know how to program well to begin with, which for a lot of academics who are not working in computer science, they write quite horrific code. I think it may be better off to skip Python altogether and write your code in a statically typed language to begin with.