Great question that I don’t have a good answer to. My bit about python was more just a throwaway joke that was also supposed to indicate that my own opinions aren’t sufficient to write the linked article.

Here are some wrong answers, but with reasons for and none against:

• Assembly: really gets you to understand that you are contending with a computer chip, and that anything interesting that you want to do requires abstraction.
• C: similar to the above, but also gets you to understand some of the fundamental aspects of programming languages, mostly memory.
• Perl: if you’re willing to teach python, why not Perl? Less readable, more magic, fun language to play golf with, so tutorial exercises could be fun.

By coincidence, these are the first three languages that I encountered as a CS student with no preexisting knowledge of programming (not in this order).

Anyway, for something approaching a real suggestion: Dart/Flutter could be an interesting choice, for some of the reasons given in the article for HTML. I haven’t given this much thought so this might still be a bad answer. Also this is the language I’m using at work right now.

There is nothing wrong with learning python in general or as a first language. My gripe is more that if you self teach it with no software engineering thought, you end up with some real bad habits that lead to bad code, like:

• not documenting code with comments etc.
• not testing
• not understanding data types
• RE: micropython, and other python wrappers: not understanding the underlying wrapped thing.
• complaining when other languages are as easy or convenient as python

So as long as you avoid that you might be good.

Also specifically with micropython: it’s good to get something working, just don’t expect it to be fast. And if you want it to be fast, you’re going to have to learn C.

I don't think you'll be broken by learning Python, but in my opinion to be a good programmer you need to understand at least one layer of abstraction lower than what you're implementing. So, as an example, once you learn how to code in Python using idk numpy, you absolutely must learn how numpy works under the hood. And that means C, because you cannot escape C.

I teach people Rust and I always say that you kind need to know the nightmare that is C/C++ to be able to fully appreciate what Rust does for you and how it builds a much more sensible programming model on top of the same set of basic concepts we use and have always used to talk to silicone. And then you can write web apps with Rust and never even touch a raw pointer in your life, but it will make you an infinitely better Rust developer if you understand what's going on below you.

This works surprisingly well across the entire SE stack IMO, e.g. if you're using React you should be fully aware of the layer below you - raw JS and HTML. If you're coding in C you should be aware of assembly and memory models. If you're using SQL to query a database you should be aware of logical plans. If you're a project manager you should be aware of what software engineering entails and what people in your team actually do day-to-day.

best advice I'd have for you is continuing with python is fine but

1. find a good mentor
2. read a lot of sourcecode (both good and bad), reason through stuff, try to understand the decisionmaking behind things

on the good, you could read code by people like glyph, hynek, projects like twisted. they have years of experience, high mark of quality, care for their work, and also do a lot of teaching

on the bad, you could read something like the code to home assistant (and/or esphome), or bits of calibre code (and calibre plugin code). I will say that these are not bad intentionally, but bad out of "someone inexperienced trying their best". it ends up creating a very particular kind of other thing.

you can, and should, learn from both

µPython is a bit of a special beast in that it's juuuust close enough (and handy enough) that it can trip you up, because there's some notable significant differences that if you spend all your effort in it first you might pick up bad habits that don't apply elsewhere (off the top of my head, some of the applicable: scoping, some arg-handling semantics, stack stuff)

other bit of advice: remember, it's all just code. especially when you deal with libraries, if some error is coming out of a thing your first instinct may be to try ask the internet but you could also dive into the library - follow the callpath, figure out what's what, see if you can figure the problem out yourself. it's often not too hard, and it gives you some good practice of code reading and reasoning