Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on July 14, 2021 5:57 am wrote:

> I can relate to that, Rust is fundamentally different then C/C++ while Go is not. And over time Rust
> has grown more and more distant from other system languages so when you switch over you need to embrace
> new concepts. Five years ago I would have said that Rust's learning curve was steep - and it was - now
> it's not anymore, unless you're coming from years of work on traditional system languages. That's to
> say a kid these days can pick up Rust pretty easily as his/her first system language - just like I did
> with C many moons ago - but expert programmers have a harder time due to the fundamentally different
> approach. Learning Rust is easy, learning idiomatic Rust is still hard and requires some time to un-learn
> old behaviors (e.g. it is very unlikely for me to write a loop in Rust code, but learning the language
> won't make it immediately apparent until you familiarize yourself with the standard library).
>
> I'd recommend reading some of Amos Wegner's excellent blog posts for a through description
> of how Rust and C/Go differ WRT abstractions, types and API design. Some of his posts are
> very long as he spends a significant amount of time going over the reasoning behind every
> design decision, but I think they're worth your time. Here's my recommendations:
>
>

>
• I want off Mr. Golang's Wild Ride

>
• Working with strings in Rust

>
• Abstracting away correctness

>

I'd also recommend the equally long and extremely thorough Rust is
> for Professionals from Gregory Szorc, another former mozillian.
>
> Though even that post misses some aspects that make Rust a joy to use. One being portability. After
> having learned how to deal with native paths in Rust going back to other languages is a chore.

I'd take them differently.

To me, all these language is similar in the sense of low-level semantics, i.e. the abstraction machine semantics. Such approach is compatible to most languages which have "variables" and "functions". Languages like Brainfuck and Unlambda are a few exceptions (due to lack of function abstractions with bound variables), but I don't treat such languages practical.

Some examples:

* Hygienic macros can be reduced to functions (as traditional LISP's FEXPR with lexical scoping support).
* Typing can be reduced by some type annotation metadata decorated on the programs, plus typechecking.
* Static typechecking can be reduced by some typechecker implemented in the untyped base language. (This is roughly like JavaScript->TypeScript, Racket->TypedRacket, etc. For a static language this may require some metaprogramming magics.)
* Dynamic typechecking can be reduced to some branches and exceptional handling.
* Classes and records can be reduced to closures with some (optionally) explicit captures, which are (possibly stateful) objects reifying functions.
* Exceptions are reduce to delimited controls. (Well, most people will fail here for lack of the familiarity to first-class continuations.)

NOTE: The efficiency of this approach strongly relies on the locality and semantic composablity. As a result, I can't simulate the global GC for arbitrary programs in my brain efficiently, due to resource limitation. This is why I'm strongly against global GC not able to be opt-out: it makes the operational semantics of programs not analyzable by myself. It is still methodologically simple to replace a GC instance to a global object pool as the root owner, and there are other workarounds.

This approach resembles a CEK machine + some private resource slots (thus, not a CEKS one) in my mind. It is no doubtfully far more powerful than a toy model of "a global array" for old-time C learners, or any old-time "system programmers". (Yep, being focus on system programming is not an excuse to keep your mind simple.)

So, to me, there is nothing really new in the language semantic design because every new feature can reduce to the derivation of quite a few existing ones, and ... most of the useful combinations are already experimented in my brain.

Even the ideas themselves are not radically new:

Lambda-expressions are new? No, they are just a refresh of lambda abstractions in the lambda calculi since 1930s, first adopted by LISP in PLs since 1950s.
The core idea of borrow checking is new? No, it is sourced from the work of substrctural logic since 1940s.

You know, all roads lead to Rome. Sane language designs will share reasonably many core features essentially the same, or at least similar enough. It is very, very difficult to carry out something really new in the domain of (practical) PL.

The additional learning efforts to me, except to the concrete syntaxes, are the purposes to introduce the "new" features. But there is also no news beyond my engineering experience.

Well, Rome wasn't built in a day. I find teaching this approach to others quite difficult (for educational reasons), so I give up. (So what is idiomatic way? Do in Rome as Rome does.) Yet I don't think most programmer should be PL experts to make it really "easy" like in my mind. Just take it easy. Don't be too worry before your tech leader do anything crazy. (... If you are the leader, you'd better be smarter and more responsible for your decision.)

The remaining part is about social effects. How to make a language attractive? How to make a language "powerful"? Is a language worth learning? Is a language worth using in the specific project? There are many such interesting questions for a "new" language, but answering them are like... gambling games.