Mostly agree. My go to language is python. Used c# in last job and it improved much over past few years.
When I need blinding speed I can use nuitka to compile python scripts.
On the rare occasions needing speed and cross platform coupled with my lessons to avoid wasted effort I turn to Lazarus/fpc because code is simple and Lazarus takes care of the target platform stuff so I don't have to.
For IOT bare-metal stuff you can't go past C. It just works and after learning it's quirks you will see how other IOT tools are largely hacks or compromises to avoid learning C.
<rant>
I think you're right that there's no viable alternative to C for IOT right now. However, I also think we need to collectively move past C in this space. The compile, run, debug cycle in embedded electronics is just too slow. I don't really mind the language, just the painfully slow development (and lack of package management). uPython and similar are a move in the right direction, but I think we need a minimalist crossplatform bytecode runtime to become standard on every popular embedded platform. This runtime needs frictionless c FFI (with the ability to seemlessly drop into c at any point, though it may require a recompile), and to be designed with embedded in mind. Actors and RPC should be first class citizens, as should remote inspection of systems over the wire, hotswapping running code, and the security needed to do those things safely (easy to get started with automatic self signed encryption). I think that every attempt at doing this so far is focusing on creating hobbyist boards for people who don't want to learn c instead of creating this ideal runtime with seemless c ffi (allowing easy adoption on new platforms), or is not lightweight enough to run on $4 chips like the ESP32. I think that most likely this platform will need to be written in c, and provide simple hooks for tying the networking libraries for individual boards together.
I was looking into building this for something my company needs, but then a Taiwanese company approached me about a low cost industrial modular linux device with hotswappable i/o they're developing. At this point I just shrugged and figured that seemed a lot easier than building a better wheel.
The thing is, I can use a $400 modular linux device because my market can bear it, but I was looking at developing the other set of features for inexpensive micros. Virtually every market can bear the cost of a $4 chip.
</rant>
I apologize for the rant, it just physically pains me that this doesn't exist, and that embedded development is so primitive.
Nerves is too resource intensive, but that's the right idea. AtomVM is closer to what I'm thinking, except ideally I want static typing that's interoperable with C, and the readme for the project would be something like: Here is a bunch of C code with some functions you need to fill in. Compile these two files for your device, and fill in all of the second file's function bodies. We maintain versions of the second file for common boards. If you add a c function to the second file, our tooling allows you to call it from the runtime.
C FFI is really critical, as that allows you to use all the existing libraries on a given platform.
So, a runtime language with elixir/erlang features, but with the C FFI of Nim. But Nim is compiled, and we need bytecode for rapid iteration.
The challenge is that what is nearly universal right now is a c compiler, but the board is always different. S7 scheme has the right idea with a single c file, but is too resource intensive and wasn't built for embedded electronics.
There is definitely an unfilled niche for rapid embedded application development. We're either going to get a $4 RPi in a chip someday, or the platform I'm describing needs to be created. Those are the routes I see to embedded RAD.
Coding in Ruby is annoying because it makes me go "why didn't you use Python for this? You guys just had to be different, didn't you? For no other reason to feel special." I have similar feelings for the other D-tier and F-tier. There's better options available. Whereas when I see someone doing something in Prolog or Assembly, it's probably because they actually needed to do it in Prolog or Assembly and they have a damned good reason. They're good for what they do. Ruby is... it just exists for no particular reason, and it's existence is annoying to me.
I spent 3 years programming in Ruby, and then 3 years in Python.
I could write a huge post about the differences between the two languages and pros and cons, but you could easily find those lists by googling.
My biggest thing that I love about Ruby is how predictable and just... beautiful it is. I love how everything chains in a predictable manner. If you say `2.days.ago`, you literally get a DateTime object back. Oh, and guess what? You can just keep on chaining! Things make sense!
Python is so caught up on being explicit and having rules that it often misses the whole point of being pleasant.
Yeah it's funny how people really entrenched in the Python world can't see how inconsistent and frustrating it is. Half object oriented (x.split()) half functional (map(.....)) half full of inbetween list comprehensions, it's a beautiful looking incomprehensible mess.
I like Groovy for the same reasons you like Ruby (but am too entrenched in the JVM ecosystem to switch to anything else).
Python I think needs a distinction. It’s an A for small projects that can be owned by a single person. But a C for projects large enough to warrant multiple developers. Dynamic languages don’t scale without a huge amount of extra tooling.
I tried to only put stuff in there that I've actually programmed with, and I just haven't done anything with JavaScript. My impression is bad, but I had a bad impression of C# and it's just okay, neither good nor bad.
Deploying a Python application can be a headache, but it's a good replacement for Bash and in DevOpsy scenarios where you're packaging Python along with an entire containerized OS and interacting with the web, Python works well. I find it pretty easy to prototype a webservice with Python, or to build tools for networking engineers. The fact that it's relatively easy to learn, yet readable, also makes it a good language to connect to people with. I can't always sell people on a strongly type functional programming paradigm, but it seems every reasonably young person knows Python these days.
But you're right, Python is a bit annoying at times, even though I like it's terseness and intuitiveness.
Python can easily get a B for large projects if you use something like mypy. However sure, where the language really shines is as a substitute for scripts, so smallish pieces of code.
And environment... It is complicated. It is not that it is that bad, however it sure lacks some polish. The solution is not easy either since even if you solved the problem today (like using poetry), there is still the whole backwards compatibility problem.
There is various hacks to make things easier, however in the end the problem is still more complicated than it should.
> Python can easily get a B for large projects if you use something like mypy
I'm curious if that's actually true - my actual experience is that it actually suffers horribly in large projects because as the size and complexity goes up it's just harder and harder for its heuristics to not produce false positive typing errors. It worked great on a small library where it could see the whole source and everything was well annotated ... but that's sort of the context where it is least needed in the first place ...
Well, Instagram [1] and Dropbox [2] are probably the biggest Python projects in the whole world, and they both are using mypy and seem to be successful.
And my particular experience with it is very positive, even if my project that is using it is still small (it is getting bigger though, and mypy is really helping me to refactor it when I needed).
Most of the "false positives" that mypy reports to me end up being code that is overly cleverly, and rewriting it to make mypy happy also improves the code quality.
Nice list, I enjoyed it, and agreed on C#. I'm over my Python phase, I wouldn't use it for anything today for many reasons. Also agreed on Rust, the way I put it is that it's the "best programming language that I'll never use".
I haven't met a programming language that I hated, and find them all pretty similar. My ranking criteria is different as a result. Top metric is "keeping the lights on", then my second metric is what it enables me to (easily) do. My main technical requirement is that it has good tooling, well-supported (no breaking versions), and is fast, because software always gets extended and ends up longer lived than first intending.
I'm originally from a small city, and may one day return. C#/Java let me keep the lights on for decades going forward in any locale. I also don't have any complaints with those languages and their chosen abstraction layer, which I think Java nailed for most business applications in the 90s and the target hasn't been better hit since.
It's still a thing for the (loud) few who couldn't manage to move to 3 after 10 years. The rest just went on. The ecosystem is on 3 [0] and it has been for years now.
> The insane packaging situation. Packaging a Python app is a nightmare.
The packaging story in Python is in the middle of a big transformation from legacy tools to modern npm/yarn/cargo-like tools. pipenv [1] and poetry [2] are the most popular contenders. It will take a while until the community settles on this, but both tools work already.
Python 3.5 introduced type annotations. It is now possible to write statically typed code in Python via mypy [3], which from my experience works similar well as TypeScript works for JavaScript.
I am the same, but with Python and C# flipped, as my projects usually grow waaay beyond what can be comfortably sustained with Python. IMHO, refactoring tools are nice to have for anything beyond 1,000 lines, and a must for anything beyond 10,000.
When I need blinding speed I can use nuitka to compile python scripts.
On the rare occasions needing speed and cross platform coupled with my lessons to avoid wasted effort I turn to Lazarus/fpc because code is simple and Lazarus takes care of the target platform stuff so I don't have to.
For IOT bare-metal stuff you can't go past C. It just works and after learning it's quirks you will see how other IOT tools are largely hacks or compromises to avoid learning C.