Hacker News new | ask | show | jobs
by bjornjajayaja 1857 days ago
I think the broader problem is that: one _cannot_ just arbitrarily “go” from a higher level language to a systems language.

Folks really ought to read the C/C++ literature to understand why Rust evolved in a unique direction. That gives better compare/contrast.

Also, a lot of Python idioms are actually from C++ (e.g. mixins, iterators, operator overloads, etc).

Anyway, to reiterate: folks interested in systems languages should read the C/C++ literature and actually become a systems engineer first.

5 comments

>Folks really ought to read the C/C++ literature to understand why Rust evolved in a unique direction. That gives better compare/contrast.

Sounds like a good idea for the post-singularity age of infinite lifespans, but what folks really need to do is learn what they need to learn as best they can when they need it.

Maybe if one just wants to scrape by. I wouldn’t want systems code from those folks to be honest... Maybe that’s fine up the layers but the whole point of Rust is correctness and stability—to get the that point, maybe invest a month hitting the books?
> Folks really ought to read the C/C++ literature to understand why Rust evolved in a unique direction. That gives better compare/contrast.

Unfortunately the C/C++ literature is dense and not at all approachable. The Rust literature is much, much better for newcomers to systems programming (partly because it doesn't have to cover a load of weird failure cases that simply don't exist in Rust).

> one _cannot_ just arbitrarily “go” from a higher level language to a systems language.

I mean, it's like learning anything new. You have to do a bit of unlearning, and grasp the core concepts. I don't think there is anything especially difficult about systems languages. I had a background of JavaScript and PHP, and I was able to pick up Rust well enough to use it in my day job in a couple of weeks.

C/C++ has been around for a while and there is gobs of literature. For this I’m guessing you mean “the website literature.”

Many developers these days scarcely read books on subject matter. But if they did read books, they would find there’s actually more C/C++ literature and established best practices than there is for Rust (naturally).

The effective C++ series comes to mind as something not just approachable, but enjoyable and largely insightful.

The truth is... systems engineering is a discipline which requires an understanding of historical context. You get that with the C/C++ books! I highly recommend reading on it to better appreciate Rust.

Whenever I see the word "pythonic" I am cautious. Not all languages are Python, nor should they all become Python, nor are they worse for _not being Python_.
Python has a reputation as "executable pseudocode", a language that makes it easy to express the essence of what you're actually doing without clutter or ceremony. That's a worthy design goal for every language IMO.
> a worthy design goal for every language

I suspect that every language in the world can be clear and direct. I am sure that some people can write unintelligible pseudocode.

We don't expect speakers of other languages to write more Englishonic phrases, although of course that does happen. (English speakers often criticise people for not speaking good English.)

Every language is readable by and intelligible to people who know the language.

Pseudocode is a useful concept. There is no "correct" pseudocode because it is meant as a DSL for _thinking_. Any non-trivial implementation of thinking will quickly become more detailed and more subtle in notation than a shopping list (for example). Opinions about the subtlety of notation abound.

I am not aware of any high-level language that makes a shopping list hard to understand. Above that, we are deeply into opinion about what defines "clutter", "ceremony", and effective notation.

We pretend all human languages are equal for political reasons, not because it's reality. I would hope that programming language preference is still neutral enough that we can talk about what things different languages do better or worse. There are plenty of things wrong with the Python ecosystem, but the language syntax is widely known as a success.
> We pretend all human languages are equal for political reasons, not because it's reality.

Hmm, what is the "non-political" reality in the question of equality of languages?

> the [Python] language syntax is widely known as a success.

There are other successful languages, too.

> Hmm, what is the "non-political" reality in the question of equality of languages?

Human languages aren't equal; plenty of languages have problems either in specific areas or just generally, and any academic linguist can tell you (off the record) which.

> There are other successful languages, too.

Python is probably the most successful teaching language; I can't think of another language with a better reputation syntax-wise. (And if another language has such a reputation, it's probably because that language is also "Pythonic").

Python developers try to write idiomatic Python in whichever language they use.

Learning the idioms and conforming to a new language are hard, especially at the beginning, and people are lazy.

Much of Python's influence is actually from Modula-3, not C++. The only reason C++ is similar is because C++ also borrowed liberally from Modula-3.

In particular, Python's import, exception handling, and object systems are based on Modula-3's (though IIRC it did also borrow some C++ innovations for the object system).

(Modula-3 is the Velvet Underground of programming languages: your average programmer/listener has never heard of it, but it influenced so many languages/musicians you have heard of)

>Anyway, to reiterate: folks interested in systems languages should read the C/C++ literature and actually become a systems engineer first.

This is an extremely weird take. So before I can code some rust I should first get a new career and master C/C++? Talk about barriers of entry and gatekeeping. I think I may have toyed around a bit with rust - because its fun, and as I am not a systems engineer (just an other type of engineer) I am deeply sorry.