11 ms·

C was invented in 1972 and became one of the most widely used languages in the world with "the compiler is the specification" - and there were many different co

C was invented in 1972 and became one of the most widely used languages in the world with "the compiler is the specification" - and there were many different compiler implementations too. It wasn't standardized until 1989 - 17 years later! I think Rust will do just fine, and the compiler error message is (IMO) the best of any language, making adhoc exploration possible. Can you imagine trying to explore C from ad-hoc alone based on its compiler errors?!

jjtheblunt 4y ago
There was the original K&R Book on C, though, the one which was about 100 pages, was super clear, and i believe gave compilers a common idea of what is normal. I wish i still had my late 80s copy.
- tialaramex 4y ago
  The first edition of K&R is 221 pages, so roughly double what you remember.
  - jjtheblunt 4y ago
    Same in big-O though! And man I'm jealous you have one!
lelanthran 4y ago
> C was invented in 1972 and became one of the most widely used languages in the world with "the compiler is the specification" - and there were many different compiler implementations too. > It wasn't standardized until 1989 - 17 years later! > I think Rust will do just fine, Not based on the example you gave - using the behaviour of a single C compiler as a specification for the language implemented by that fairly easy due to how small C is. Rust is very much larger than C. > and the compiler error message is (IMO) the best of any language, making adhoc exploration possible. > Can you imagine trying to explore C from ad-hoc alone based on its compiler errors?! Not much different from Rust: Gcc and clang C compiler errors are exceptionally good, and I miss them terribly when programming in some other language (like C++, or Javascript).
202206241203 4y ago
> I think Rust will do just fine Not mainstream language 'fine', but fine.
- IshKebab 4y ago
  Rust is already a mainstream language, unless you have a weirdly restrictive definition of mainstream.
  - replygirl 4y ago
    > belonging to or characteristic of the ideas, attitudes, or activities that are regarded as normal or conventional, or the dominant trend in opinion, fashion, or the arts by dictionary definition, rust is not mainstream. it's not normal (common, typical, customary) for an engineer to interact with rust
    - IshKebab 4y ago
      I would consider it perfectly normal to discover something in my company or on Github was written in Rust. It's the 12th most popular language on Github by PRs according to this: https://madnight.github.io/githut/#/pull_requests/2022/1 https://madnight.github.io/githut/#/pull_requests/2022/1 (Shell and Nix don't count). It's only 3 times less popular than C. As I said, very weird definition of mainstream.
      - cmrdporcupine 4y ago
        The measure of "mainstream" should not be "projects on github" but: code deployed (or actively deploying) in production. GitHub is full of personal interest and research and unfinished projects. It will come. It's not there yet. I still argue it's not the language best suited for what a lot of people are trying to use it for. It has a niche, one that I like, but I fail to understand why it's being deployed for web services type applications. IMHO it's not a good fit.
        4y ago
samwillis 4y ago
Sometimes doing a formal standardisation process too early can result in stifling innovation. I’m too young (at 36) to have insight in to the C development processes, but I suspect that having competing compilers trying out different things will have resulted in a better language in the long run. It’s in many ways similar to the way the early web was developed, different browsers tried out many different additions, copied the better ones and improved them. The standardisation process we now have didn’t exist back then, and has been through a number of iterations itself since (the “xml every thing” process that ended with xhtml had a questionable outcome at best). Some may argue that a formal standardisation process should have started earlier, before IE became too dominant. But I’m not too sure, IE was incredibly innovative and introduced some important technologies and apis, before stagnating. In fact the “modern” html/css/js standardisation process is specifically lead by individual browsers implementing and trying out new additions, with formal acceptance dependent on other browsers also implementing it. It’s inherently a implementation lead standardisation process, not necessarily committee led.
- ralfj 4y ago
  The early web with every browser doing something else was terrible for website authors. A lot of the innovation in the web started when there finally was standardization so that these fancy features could actually be used reliably across browsers. You are representing that history in a completely wrong light here.
  - deleted 4y ago
    [deleted]
  - 3836293648 4y ago
    The web is a completely different beast though. You can reasonably target only one compiler, even if you lose some platform support. You cannot reasonably support only one browser.
    - Ygg2 4y ago
      > You cannot reasonably support only one browser. *Looks at works best in Chrome sites.* You sure about that?
j-pb 4y ago
The major difference between Rust and [Zig, C] is that the latter are essentially "cocky macro assemblers". They derive their semantics from the semantics of the underlying assembly. Take https://github.com/ziglang/zig/issues/12251 https://github.com/ziglang/zig/issues/12251 as an example. Several people from the Rust and Haskell community slacked off on twitter about how awful of a language design this is. However, when you think about what the language actually compiles to it makes perfect sense, and is pretty straightforward. Rust has the goal of putting as much smartness between what you type and what the compiler produces, which is a perfectly fine goal, but without a specification for the input semantics it's a pretty wobbly thing, especially for a systems programming language. A lot of bit packing code is simply not writable in rust today without immediately invoking UB, that works for now but might break with every bugfix release.
- eptcyka 4y ago
  Rust has no explicit goal to introduce magic - instead the goal is to be safe and sound. I'd argue the code very often compiles to what one might expect it to compile to, its certainly better than C++ when it comes to magic in terms of how useful and transparent said magic is.
  - j-pb 4y ago
    C++ is arguably the most complex programming language ever. There is not much to be gained by comparing against the supremum. Take a look at the languages that rust was influenced by (https://en.wikipedia.org/wiki/Rust_(programming_language) https://en.wikipedia.org/wiki/Rust_(programming_language)) those aren't languages with straightforward compilation semantics. There is a reason why rust has a datalog engine build into the compiler (https://github.com/rust-lang/datafrog https://github.com/rust-lang/datafrog). Which is imho totally rad and awesome, but really hard to fully form a mental model of without a spec.
    - Rusky 4y ago
      This is pretty vague reasoning. Rust draws inspiration from each of those languages for something but that doesn't mean they affect its operational semantics, which are quite similar to C's. The fact that you point to datafrog is illustrative: while it is not actually built into the compiler today, the use case for it is borrow checking, which famously does not impact the language's operational behavior at all! It is purely a compile-time analysis that does not influence code generation. (For example, consider that mrustc and the GCC frontend are both able to omit borrow checking entirely and yet still produce runnable binaries!) Of course, the borrow checker is still something that you need to build a mental model for, but by design it is okay for you to get that wrong occasionally, because the result can only ever be "your program still does what you thought, but the analysis proved that in a way you did not expect" or "your program does not compile."
fanf2 4y ago
C had a Reference Manual (e.g. https://archive.org/details/crefman/cman74/ https://archive.org/details/crefman/cman74/ and https://www.bell-labs.com/usr/dmr/www/cman.pdf https://www.bell-labs.com/usr/dmr/www/cman.pdf) which was included as an appendix in the 1st edition of K&R. That was effectively the specification through the 1980s. At about the time K&R1 was published, the Ritchie's original C compiler was being replaced by pcc, and `lint` was another early (diagnostics-only) implementation. The K&R1 reference manual includes a few mentions of features that were deprecated by pcc, or new in pcc. So I think C was more mature than "the compiler is the specification" by the end of the 1970s.
- tialaramex 4y ago
  I would say that, on the whole, doc.rust-lang.org serves a similar purpose to K&R. It's a comprehensive tutorial, a good guide for the standard library, and a good start for a reference but not strictly a complete definition of the language. K&R is remarkable for fitting all that into one slim book, and Rust's documentation rightly doesn't try. Rust's documentation also has some considerable advantages from its modernity. That library documentation gets to link to the actual source code which can answer tricky questions you'd never cover in a book, yet in many cases that source is very readable, its examples are something you can try for yourself with one click, instead of one of the very best human compiled indices of any book it has text search and hyperlinks.
  - ralfj 4y ago
    Beware of reading the library sources though, they can change any time without warning. Only the docs are guarantees that remain stable as Rust gets updated.
pjmlp 4y ago
And we had lots of "fun" porting C code, including micro dialects like Small-C and RatC.

jjtheblunt 4y ago

There was the original K&R Book on C, though, the one which was about 100 pages, was super clear, and i believe gave compilers a common idea of what is normal. I wish i still had my late 80s copy.

tialaramex 4y ago
The first edition of K&R is 221 pages, so roughly double what you remember.
- jjtheblunt 4y ago
  Same in big-O though! And man I'm jealous you have one!

lelanthran 4y ago

> C was invented in 1972 and became one of the most widely used languages in the world with "the compiler is the specification" - and there were many different compiler implementations too. > It wasn't standardized until 1989 - 17 years later! > I think Rust will do just fine, Not based on the example you gave - using the behaviour of a single C compiler as a specification for the language implemented by that fairly easy due to how small C is. Rust is very much larger than C. > and the compiler error message is (IMO) the best of any language, making adhoc exploration possible. > Can you imagine trying to explore C from ad-hoc alone based on its compiler errors?! Not much different from Rust: Gcc and clang C compiler errors are exceptionally good, and I miss them terribly when programming in some other language (like C++, or Javascript).

202206241203 4y ago

> I think Rust will do just fine Not mainstream language 'fine', but fine.

IshKebab 4y ago
Rust is already a mainstream language, unless you have a weirdly restrictive definition of mainstream.
- replygirl 4y ago
  > belonging to or characteristic of the ideas, attitudes, or activities that are regarded as normal or conventional, or the dominant trend in opinion, fashion, or the arts by dictionary definition, rust is not mainstream. it's not normal (common, typical, customary) for an engineer to interact with rust
  - IshKebab 4y ago
    I would consider it perfectly normal to discover something in my company or on Github was written in Rust. It's the 12th most popular language on Github by PRs according to this: https://madnight.github.io/githut/#/pull_requests/2022/1 https://madnight.github.io/githut/#/pull_requests/2022/1 (Shell and Nix don't count). It's only 3 times less popular than C. As I said, very weird definition of mainstream.
    - cmrdporcupine 4y ago
      The measure of "mainstream" should not be "projects on github" but: code deployed (or actively deploying) in production. GitHub is full of personal interest and research and unfinished projects. It will come. It's not there yet. I still argue it's not the language best suited for what a lot of people are trying to use it for. It has a niche, one that I like, but I fail to understand why it's being deployed for web services type applications. IMHO it's not a good fit.
      - 4y ago

samwillis 4y ago

Sometimes doing a formal standardisation process too early can result in stifling innovation. I’m too young (at 36) to have insight in to the C development processes, but I suspect that having competing compilers trying out different things will have resulted in a better language in the long run. It’s in many ways similar to the way the early web was developed, different browsers tried out many different additions, copied the better ones and improved them. The standardisation process we now have didn’t exist back then, and has been through a number of iterations itself since (the “xml every thing” process that ended with xhtml had a questionable outcome at best). Some may argue that a formal standardisation process should have started earlier, before IE became too dominant. But I’m not too sure, IE was incredibly innovative and introduced some important technologies and apis, before stagnating. In fact the “modern” html/css/js standardisation process is specifically lead by individual browsers implementing and trying out new additions, with formal acceptance dependent on other browsers also implementing it. It’s inherently a implementation lead standardisation process, not necessarily committee led.

ralfj 4y ago
The early web with every browser doing something else was terrible for website authors. A lot of the innovation in the web started when there finally was standardization so that these fancy features could actually be used reliably across browsers. You are representing that history in a completely wrong light here.
- deleted 4y ago
  [deleted]
- 3836293648 4y ago
  The web is a completely different beast though. You can reasonably target only one compiler, even if you lose some platform support. You cannot reasonably support only one browser.
  - Ygg2 4y ago
    > You cannot reasonably support only one browser. *Looks at works best in Chrome sites.* You sure about that?

j-pb 4y ago

The major difference between Rust and [Zig, C] is that the latter are essentially "cocky macro assemblers". They derive their semantics from the semantics of the underlying assembly. Take https://github.com/ziglang/zig/issues/12251 https://github.com/ziglang/zig/issues/12251 as an example. Several people from the Rust and Haskell community slacked off on twitter about how awful of a language design this is. However, when you think about what the language actually compiles to it makes perfect sense, and is pretty straightforward. Rust has the goal of putting as much smartness between what you type and what the compiler produces, which is a perfectly fine goal, but without a specification for the input semantics it's a pretty wobbly thing, especially for a systems programming language. A lot of bit packing code is simply not writable in rust today without immediately invoking UB, that works for now but might break with every bugfix release.

eptcyka 4y ago
Rust has no explicit goal to introduce magic - instead the goal is to be safe and sound. I'd argue the code very often compiles to what one might expect it to compile to, its certainly better than C++ when it comes to magic in terms of how useful and transparent said magic is.
- j-pb 4y ago
  C++ is arguably the most complex programming language ever. There is not much to be gained by comparing against the supremum. Take a look at the languages that rust was influenced by (https://en.wikipedia.org/wiki/Rust_(programming_language) https://en.wikipedia.org/wiki/Rust_(programming_language)) those aren't languages with straightforward compilation semantics. There is a reason why rust has a datalog engine build into the compiler (https://github.com/rust-lang/datafrog https://github.com/rust-lang/datafrog). Which is imho totally rad and awesome, but really hard to fully form a mental model of without a spec.
  - Rusky 4y ago
    This is pretty vague reasoning. Rust draws inspiration from each of those languages for something but that doesn't mean they affect its operational semantics, which are quite similar to C's. The fact that you point to datafrog is illustrative: while it is not actually built into the compiler today, the use case for it is borrow checking, which famously does not impact the language's operational behavior at all! It is purely a compile-time analysis that does not influence code generation. (For example, consider that mrustc and the GCC frontend are both able to omit borrow checking entirely and yet still produce runnable binaries!) Of course, the borrow checker is still something that you need to build a mental model for, but by design it is okay for you to get that wrong occasionally, because the result can only ever be "your program still does what you thought, but the analysis proved that in a way you did not expect" or "your program does not compile."

fanf2 4y ago

C had a Reference Manual (e.g. https://archive.org/details/crefman/cman74/ https://archive.org/details/crefman/cman74/ and https://www.bell-labs.com/usr/dmr/www/cman.pdf https://www.bell-labs.com/usr/dmr/www/cman.pdf) which was included as an appendix in the 1st edition of K&R. That was effectively the specification through the 1980s. At about the time K&R1 was published, the Ritchie's original C compiler was being replaced by pcc, and `lint` was another early (diagnostics-only) implementation. The K&R1 reference manual includes a few mentions of features that were deprecated by pcc, or new in pcc. So I think C was more mature than "the compiler is the specification" by the end of the 1970s.

tialaramex 4y ago
I would say that, on the whole, doc.rust-lang.org serves a similar purpose to K&R. It's a comprehensive tutorial, a good guide for the standard library, and a good start for a reference but not strictly a complete definition of the language. K&R is remarkable for fitting all that into one slim book, and Rust's documentation rightly doesn't try. Rust's documentation also has some considerable advantages from its modernity. That library documentation gets to link to the actual source code which can answer tricky questions you'd never cover in a book, yet in many cases that source is very readable, its examples are something you can try for yourself with one click, instead of one of the very best human compiled indices of any book it has text search and hyperlinks.
- ralfj 4y ago
  Beware of reading the library sources though, they can change any time without warning. Only the docs are guarantees that remain stable as Rust gets updated.

pjmlp 4y ago

And we had lots of "fun" porting C code, including micro dialects like Small-C and RatC.