5 ms·

> In the long run, unsafe programming languages will not be used by mainstream developers, but rather reserved for situations where high performance and a low r

by zer8k 3y ago

> In the long run, unsafe programming languages will not be used by mainstream developers, but rather reserved for situations where high performance and a low resource footprint are critical. I see no world where so-called "unsafe" languages would not be used. Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. This is not a footnote. This fact alone means that for any given piece of hardware you're more likely to find a random C compiler you can use than anything else. Rust, being the most likely contender to replace it, still cannot self-host and the grammar is exponentially more complicated than C. It is more like C + <whatever> will co-exist peacefully than something like C being replaced (even ignoring the millions of lines of code that already exist). Not for performance reasons but more that you can churn out a C compiler quickly for almost anything given a spec of the hardware. On topic, I find a desk reference for this is very useful. The CERT C standard is pretty good to thumb through even if you don't adhere to every suggestion.

dale_glass 3y ago
I don't see how that reasoning is supposed to work in modern times. Who out there is seriously using a compiler churned out in a weekend? The fact that you can do it doesn't mean anybody seriously would use that. We're also not really creating architectures anymore. There's RISC-V, and Rust already supports that.
- zer8k 3y ago
  > Who out there is seriously using a compiler churned out in a weekend? Someone at a chip manufacturer writing something for a brand new chipset, for example. It takes a long time to get stuff shoved into GCC. It's only in recent history has life settled on one or two "big" compilers. There are still plenty of other places where you will find bespoke compilers. Perhaps not commonly, but they do exist (especially in embedded).
  - tempest_ 3y ago
    Are they actually bespoke compilers, or just some decade old fork of gcc that works for that chipset and is never updated again? ( I am not being facetious )
    - sigsev_251 3y ago
      From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./<compiler> --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it. [1]: https://compcert.org/ https://compcert.org/
  - marcosdumay 3y ago
    Well, nowadays you are supposed to port a backend, and not write an entire compiler.
ladberg 3y ago
Eh, I don't disagree that unsafe languages will continue to be used, but I disagree with ease of compiler design as the reason. You are comparing one of the easier languages to write a compiler for (C) with one of the hardest (Rust), and that's not due to UB but due to other facets of the languages. I could make up a new language that's equivalent to C in every way except replace all UB with defined behavior and it wouldn't make the naive compiler any different. Additionally, writing a compiler for a language should really be a thing that happens only a handful of times while executing the code happens trillions of times so I hope we don't sacrifice safety to save compiler authors some work.
- jenadine 3y ago
  > except replace all UB with defined behavior and it wouldn't make the naive compiler any different. I wonder how you will define use after free
  - adgjlsfhk1 3y ago
    returns a random value or errors. the main problem with UB isn't that it has unpredictable behavior, it's that it also inserts an unreachable that allows the compiler to assume it doesn't happen.
    - colejohnson66 3y ago
      Clarifying UB as “inserting a ‘__builtin_unreachable()’” actually just cleared up a lot of confusions I’ve had!
dralley 3y ago
> Rust, being the most likely contender to replace it, still cannot self-host What do you mean, "still cannot self-host?" You say that like it's a critical failure of the Rust project that they need and are attempting to address rather than a trivia item. Rust is perfectly happy relying on LLVM just like (checks notes) half the other languages in existence. Libraries like LLVM are precisely what the comment you quote is talking about. I'm not even sure that's true, anyway, with the cranelift backend. Someone can chime in on whether it's good enough for bootstrapping.
- merlincorey 3y ago
  Self Hosting your own compiler traditionally was the "end-game" of making a compile-able language. It's a sort of proof of fitness that the language can literally stand on its own. This article about Zig achieving self-hosted status in 2022[0] points out that they gained many advantages at the cost of a lot of time and effort through this process. Incidentally, they decided to self-host while also supporting LLVM because of deficiencies in LLVM (mainly speed and target limitations). This flexibility includes a separate "C" backend to compile Zig to C in order to target for example game consoles that require a specific C compiler be used. > You say that like it's a critical goal of the Rust project rather than a trivia item. In my opinion, you are overly minimizing the potential benefits to Rust and the Rust community for Rust to be self-hosted. Of course, practically, right now it doesn't matter because most people are more than happy to use the already working system. [0] https://kristoff.it/blog/zig-self-hosted-now-what/ https://kristoff.it/blog/zig-self-hosted-now-what/
  - dralley 3y ago
    As I said, the cranelift backend exists, and it provides many of the same benefits such as improved compilation speed. And it's written in Rust. But it still feels like a trivia item. C compilers written in C exist, but almost nobody actually uses them. They use GCC, Clang, and MSVC, written in C++. Everybody knows that it's possible to self-host C, so the benefit of actually doing so in practice is minimal. It's obviously possible to write a Rust compiler in Rust end-to-end. Acting like it's a second tier language because actively doing so not a top focus of the community is gatekeep-y and ridiculous.
badsectoracula 3y ago
> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. This is not a footnote. This fact alone means that for any given piece of hardware you're more likely to find a random C compiler you can use than anything else. I think C being a (relatively) very simple is indeed a feature it has - however not so much because you can make a compiler for it easily (not that it isn't a pro, but it isn't that important in practice) but because it means it is easier to learn and easier to write tools for.
- glouwbug 3y ago
  Took me 6 years to implement my own in C. It ended up being python with braces. Recursive descent parser are incredibly brittle and take extreme concentration and patience
pjmlp 3y ago
Just wait until CVE become a liability like handling hazardous chemicals.
patrec 3y ago
> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. Where "most" of course means < 0.1%.
- TillE 3y ago
  Two weekends is ludicrously optimistic even if you're leaning heavily on existing parser libraries, but if you've taken a programming languages class, you can write a simple compiler for a large subset of C.
titzer 3y ago
> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. I see you have not met most graduates of Computer Science programs. > for any given piece of hardware you're more likely to find a random C compiler This might have been true 10 or 20 years ago, but these days, C has grown so complex that the random C compiler is likely gcc or LLVM with not much else. > you can churn out a C compiler quickly for almost anything given a spec of the hardware. Who is doing this? There aren't a lot of new ISAs coming out now, and when they do come out, they usually put effort into porting either LLVM or gcc.
deaddodo 3y ago
> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. Probably not. Compiler design (lexical+syntactical analysis and code generation) isn't covered by most basic CS bachelor's programs. Theoretically, a CompSci graduate should be able to reference the necessary materials, ingest the theory and make a basic multipass, non-optimizing C compiler. But I would still be skeptical of a good chunk of recent (as in, lack of experience; not year of graduation) graduates; and would assume that it would take >4 days ("two weekends").
- armchairhacker 3y ago
  I took a compilers class in undergraduate. We read Appel's Modern Compiler Implementation in ML (https://www.cs.princeton.edu/~appel/modern/ml/ https://www.cs.princeton.edu/~appel/modern/ml/) and built a compiler for the Tiger language (basically https://github.com/FlexW/tiger-compiler https://github.com/FlexW/tiger-compiler but in SML). We covered the main chapters but not the advanced topics. If you look at the TOC (https://www.cs.princeton.edu/~appel/modern/toc.html https://www.cs.princeton.edu/~appel/modern/toc.html) you can get an idea of the necessary steps: - Lexing - Parsing - Symbol table generation - Type checking - IR - Some static analyses (e.g. liveness) - Some optimizations (e.g. constant folding) - Assembly generation - Register allocation Me and my 1 group-mate had a working compiler at the end. It took a whole semester, sure I was taking other classes and doing other things, but it certainly took more than 2 weekends worth of work (maybe if you count raw hours, 96 in total...).
duped 3y ago
C++ shares ubiquity with C and it's not because it's easy to parse. The reason is the same though: ISA authors know how to write backends for GCC, which is what they've done for 30 years when they want to get people to use their chip.

by zer8k 3y ago

dale_glass 3y ago

I don't see how that reasoning is supposed to work in modern times. Who out there is seriously using a compiler churned out in a weekend? The fact that you can do it doesn't mean anybody seriously would use that. We're also not really creating architectures anymore. There's RISC-V, and Rust already supports that.

zer8k 3y ago
> Who out there is seriously using a compiler churned out in a weekend? Someone at a chip manufacturer writing something for a brand new chipset, for example. It takes a long time to get stuff shoved into GCC. It's only in recent history has life settled on one or two "big" compilers. There are still plenty of other places where you will find bespoke compilers. Perhaps not commonly, but they do exist (especially in embedded).
- tempest_ 3y ago
  Are they actually bespoke compilers, or just some decade old fork of gcc that works for that chipset and is never updated again? ( I am not being facetious )
  - sigsev_251 3y ago
    From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./<compiler> --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it. [1]: https://compcert.org/ https://compcert.org/
- marcosdumay 3y ago
  Well, nowadays you are supposed to port a backend, and not write an entire compiler.

ladberg 3y ago

Eh, I don't disagree that unsafe languages will continue to be used, but I disagree with ease of compiler design as the reason. You are comparing one of the easier languages to write a compiler for (C) with one of the hardest (Rust), and that's not due to UB but due to other facets of the languages. I could make up a new language that's equivalent to C in every way except replace all UB with defined behavior and it wouldn't make the naive compiler any different. Additionally, writing a compiler for a language should really be a thing that happens only a handful of times while executing the code happens trillions of times so I hope we don't sacrifice safety to save compiler authors some work.

jenadine 3y ago
> except replace all UB with defined behavior and it wouldn't make the naive compiler any different. I wonder how you will define use after free
- adgjlsfhk1 3y ago
  returns a random value or errors. the main problem with UB isn't that it has unpredictable behavior, it's that it also inserts an unreachable that allows the compiler to assume it doesn't happen.
  - colejohnson66 3y ago
    Clarifying UB as “inserting a ‘__builtin_unreachable()’” actually just cleared up a lot of confusions I’ve had!

dralley 3y ago

> Rust, being the most likely contender to replace it, still cannot self-host What do you mean, "still cannot self-host?" You say that like it's a critical failure of the Rust project that they need and are attempting to address rather than a trivia item. Rust is perfectly happy relying on LLVM just like (checks notes) half the other languages in existence. Libraries like LLVM are precisely what the comment you quote is talking about. I'm not even sure that's true, anyway, with the cranelift backend. Someone can chime in on whether it's good enough for bootstrapping.

merlincorey 3y ago
Self Hosting your own compiler traditionally was the "end-game" of making a compile-able language. It's a sort of proof of fitness that the language can literally stand on its own. This article about Zig achieving self-hosted status in 2022[0] points out that they gained many advantages at the cost of a lot of time and effort through this process. Incidentally, they decided to self-host while also supporting LLVM because of deficiencies in LLVM (mainly speed and target limitations). This flexibility includes a separate "C" backend to compile Zig to C in order to target for example game consoles that require a specific C compiler be used. > You say that like it's a critical goal of the Rust project rather than a trivia item. In my opinion, you are overly minimizing the potential benefits to Rust and the Rust community for Rust to be self-hosted. Of course, practically, right now it doesn't matter because most people are more than happy to use the already working system. [0] https://kristoff.it/blog/zig-self-hosted-now-what/ https://kristoff.it/blog/zig-self-hosted-now-what/
- dralley 3y ago
  As I said, the cranelift backend exists, and it provides many of the same benefits such as improved compilation speed. And it's written in Rust. But it still feels like a trivia item. C compilers written in C exist, but almost nobody actually uses them. They use GCC, Clang, and MSVC, written in C++. Everybody knows that it's possible to self-host C, so the benefit of actually doing so in practice is minimal. It's obviously possible to write a Rust compiler in Rust end-to-end. Acting like it's a second tier language because actively doing so not a top focus of the community is gatekeep-y and ridiculous.

badsectoracula 3y ago

> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. This is not a footnote. This fact alone means that for any given piece of hardware you're more likely to find a random C compiler you can use than anything else. I think C being a (relatively) very simple is indeed a feature it has - however not so much because you can make a compiler for it easily (not that it isn't a pro, but it isn't that important in practice) but because it means it is easier to learn and easier to write tools for.

glouwbug 3y ago
Took me 6 years to implement my own in C. It ended up being python with braces. Recursive descent parser are incredibly brittle and take extreme concentration and patience

pjmlp 3y ago

Just wait until CVE become a liability like handling hazardous chemicals.

patrec 3y ago

> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. Where "most" of course means < 0.1%.

TillE 3y ago
Two weekends is ludicrously optimistic even if you're leaning heavily on existing parser libraries, but if you've taken a programming languages class, you can write a simple compiler for a large subset of C.

titzer 3y ago

> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. I see you have not met most graduates of Computer Science programs. > for any given piece of hardware you're more likely to find a random C compiler This might have been true 10 or 20 years ago, but these days, C has grown so complex that the random C compiler is likely gcc or LLVM with not much else. > you can churn out a C compiler quickly for almost anything given a spec of the hardware. Who is doing this? There aren't a lot of new ISAs coming out now, and when they do come out, they usually put effort into porting either LLVM or gcc.

deaddodo 3y ago

> Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. Probably not. Compiler design (lexical+syntactical analysis and code generation) isn't covered by most basic CS bachelor's programs. Theoretically, a CompSci graduate should be able to reference the necessary materials, ingest the theory and make a basic multipass, non-optimizing C compiler. But I would still be skeptical of a good chunk of recent (as in, lack of experience; not year of graduation) graduates; and would assume that it would take >4 days ("two weekends").

armchairhacker 3y ago
I took a compilers class in undergraduate. We read Appel's Modern Compiler Implementation in ML (https://www.cs.princeton.edu/~appel/modern/ml/ https://www.cs.princeton.edu/~appel/modern/ml/) and built a compiler for the Tiger language (basically https://github.com/FlexW/tiger-compiler https://github.com/FlexW/tiger-compiler but in SML). We covered the main chapters but not the advanced topics. If you look at the TOC (https://www.cs.princeton.edu/~appel/modern/toc.html https://www.cs.princeton.edu/~appel/modern/toc.html) you can get an idea of the necessary steps: - Lexing - Parsing - Symbol table generation - Type checking - IR - Some static analyses (e.g. liveness) - Some optimizations (e.g. constant folding) - Assembly generation - Register allocation Me and my 1 group-mate had a working compiler at the end. It took a whole semester, sure I was taking other classes and doing other things, but it certainly took more than 2 weekends worth of work (maybe if you count raw hours, 96 in total...).

duped 3y ago

C++ shares ubiquity with C and it's not because it's easy to parse. The reason is the same though: ISA authors know how to write backends for GCC, which is what they've done for 30 years when they want to get people to use their chip.