Hacker News Reader

Comment by dman | Hacker News Reader

Disclaimer: Am a C++ programmer

Watching from a distance I have to concede that from a safety, dynamism of the community and package management using cargo Rust has improved upon C++ in meaningful and measurable way.

However on the complexity of the language front, I wonder if Rust will also join C++ in the realms of "too complex" 10 years from now. Would love to get some Rust experts to weigh in here on their thoughts about managing complexity of the language long term and whether being a simple systems programming language is an end goal.

View on HN

Rust is certainly not the "end of history" for programming languages. But, taking on that task is for future generations of language devs; it's an open research question today. I can only hope so!

I wrote some thoughts about "complexity" and language design here: http://words.steveklabnik.com/the-language-strangeness-budge...

I also think the difference between incidental and inherent complexity is important...

One question I had after reading your post is - We currently build languages with purely additive models, ie features can be added to a language over time. Overtime the interaction between features creates "incidental complexity". Was wondering if you know of any languages that have been able to drop old features / ideas in a controlled manner.

Lua has been known to remove things. The language still remains small and clean after over 20 years. The creator has given some talks about how breaking compatibility (e.g removing features) requires its own thought process. There are different types of changes. The easiest to change are the ones that can be detected immediately in existing real world programs whereas the hard changes are the kinds that could go silently undetected by users until it is too late.

Ruby 1.8 -> 1.9 was quite successful; it was painful at the time, but eventually worked out. Contrast with Python 2 -> 3 or Perl 5 -> 6.

It's a goal of Rust to be simple--one look at the RFC repo is enough to see how important that is in the language design--but there are other goals too. In particular, nobody has successfully proposed any alternative to memory safety without GC that doesn't involve lifetimes and borrowing (and reference counting is just a form of GC).

My hope is that, over time, we figure out simpler ways to achieve the safety goals that Rust is pioneering right now, and so there will be simpler/easier alternatives that do the same.

If in ten or twenty years we can't do better than now, we've failed to make progress.

So yes, in the future we will hopefully consider Rust "too complex".

(Disclaimer: I don't have much experience with Rust, speaking as an outside observer).

Safety can be established in three ways:

(0) Automatically and statically, in which case there is an unavoidable tradeoff between the simplicity and the power of the static analyses. Example: non-lexical lifetimes.

(1) Automatically and dynamically, in which case you need performance-draining checks. Example: slice indexing.

(2) Manually, i.e., leave it as an exercise for the programmer, in which case you need a language with a formal semantics, because how else are you supposed to prove anything? Example: none that I know of in Rust or any other similar language.

There are no other options, although you can take a pick and choose approach for different use cases. IMO (2) has not been given the attention it deserves.

---

So, do you have any concrete idea regarding what could be made simpler?

Reply on news.ycombinator.com