This only applies now because fundamental aspects of a competent modern language are still being added - it was only recent that you could have a const fn at all, async is only coming at the end of the year, there are still no HKTs, etc.

I'd be willing to bet Rust 2021 will be a great place to start at because it will represent 95% of what the language will become having already been put in place. From that point there will certainly be additions to the language in the forms of libraries and features but the mechanisms of how you write code in general will be solidified.

Until then yea, theres a lot of churn along the way to having a "mostly complete" language, especially when the point of the language is to basically be a kitchen sink of everything.

I really think that could go either way. Haskell keeps getting new bells and whistles with no sign of any slow down. Once you get into sophisticated type systems, it's never "done". There's always going to be (semantically) safe code that doesn't type check in safe Rust, and the temptation to extend the type system to rectify that.

But Haskell is intentionally used as a laboratory to experiment with new ideas. That is not Rust's primary goal.

An interesting example is the addition of `{-# LANGUAGE LinearTypes #-}` to GHC. The primary interest for this "experiment" is not from academia but from industry (tweag IO). Another example is `QuantifiedConstraints` which was quickly caught up by practical applications as well. Haskell is not just for academia, it is very much intended for practical use after all.

It is intended by it's creators as a research language. That doesn't mean it isn't suitable for practical use, it just means that you should expect it to continue to gain features and grow in complexity.

It's not C++'s goal either, AFAIK, but major new features keep getting added to the language anyway.

I've already felt the slowdown in changes. I did have a (little) break from Rust and the only things that have changed are ergonomic improvements and the async stuff. This is a predictable outcome given the roadmap for this year was one of stability for the language.

When async/await stabilises, I think it's going to be less about the language changing and more about the ecosystem. I think there is going to be a lot of development on top of async over the next few years and we're going to learn a lot about the right way to structure programs and deliver useful abstractions. This is going to be particularly true in the embedded space I care the most about.

This is the hidden downside of having a good package manager - knowing how to use the ecosystem is as much of a skill in real world programming as knowing how to use the language. To be clear though - that cost is entirely worth it.

It could be. Rust has been stable Real Soon Now for quite some years.

"Stable" is not a binary condition, and Rust has been moving continuously in a 'more stable' direction.

I'm not sure I agree with that. Async/await is a major new feature and is just landing now.

Python is over 20 years old and got async/await only 4 years ago. I think most people would still consider Python a fairly stable language.

Go, for sure.

Python, knowing it since version 1.6, I doubt it very much.

python 3x seems is a milestone, and relatively speaking, python is very readable

Python is very powerful.

Reflection, meta-classes, decorators, comprehensions, slots, operator overloading, multiple inheritance and plenty of other features, some of them with semantics that changed across minor versions.

Python the full language, is at the same capability level as C++.

Many just don't realize it, because it is kind of targeted to teach programming and then people move on.

I'd say that's something Python does well. Many people don't realize because they don't need those features. If you can do with simple code and patterns, go with that. Rust on the other hand, hits you with all the complexity from the start (or a lot of it). I'm not saying this is necessarily bad, or that having a lot of "hidden complexity" is always good, the use-cases are different, but in many cases it's kinda good to not need to know about the things you don't need to use.

And the level of mutation one can inflict upon the runtime is magnificent!

http://farmdev.com/src/secrets/framehack/

https://github.com/lihaoyi/macropy

Right, you can write your own debugger for Python in Python (assuming CPython).

Yeah, and the cool thing about being able to write your own debugger, you can have domain specific debuggers or debuggers that put the application in the debug state and phone home giving the eng a chance to capture the error and handle it.

Lua has a similarly powerful debug hook mechanism. Being able to debug the system from within itself is an amazingly powerful feature.

Same theoretical capability; inferior performance and safety in general. Its versatility in the stack is, in my mind, its defining characteristic - unlike C++, it's a great scripting language that's easy to get started with- maybe the best. Like C++, it's a capable low-level, close-to-the-metal language. But I doubt it's the best choice for those cases. (We know what Linus said about C++ devs working on the kernel ... what would he say about python devs??)

Side bar, I wasn't aware it was a popular educational tool. I was taught type strong languages, and coming into Python felt like writing pseudocode. Too easy, as the Aussies would say!

You are mixing languages with implementations.

If CPython devs would care as much as Common Lisp, Dylan, Scheme, Smalltalk, JavaScript, Julia, it surely wouldn't be as slow.

There are PyPy, TrufflePython and OpenJ9 Python, they all suffer from the stigma of not being CPython.

Is it that readable when the code is making heavy use of advanced features like decorators and magic functions, or the code is deep into the inheritance hierarchy?

This comment is pretty ironic because Python changed so much changed in the past few years.