5 ms·

I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no s

by dvt 7y ago

I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no small part because it wants to be backwards compatible with C (the reasoning is unconvincing -- why not just use C++?). In the age of Go and Rust, which already have a hard time finding niches, I don't really think there's any room for a language like this. And on the other hand, from a research standpoint, it's probably a lot more interesting to build a new language from the ground up.

gambiting 7y ago
I don't know, I work in the games industry and we're currently building a small project that's probably 95% C(the only C++ we have is for one library that has to have a C++ wrapper). It's just.....we don't need the C++ features, the compilation times are instant(last project I worked on was a large AAA game in C++ and compiling it from scratch was about 40-50 minutes on a single workstation), and pretty much all libs are C anyway. I'm not going to make the performance argument since it's mostly irrelevant nowadays, but I just don't see us using C as anything out of ordinary.
- jbverschoor 7y ago
  Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.
  - kgabis 7y ago
    I'm yet to see a C++ project that compiles as fast as a C one.
    - dTal 7y ago
      About a decade ago I used a Zipit Z2 as my primary machine, as a fun experiment. It had 32 megabytes of RAM. Back then, that meant you could just about run Debian (who needs X11 anyway). Believe it or not, I often compiled software on this thing, and I quickly noticed that projects written in C would generally compile, while C++ builds would invariably choke from memory exhaustion. This was actually the first time I became aware of any difference between the two. A very educational experience!
    - rleigh 7y ago
      groff does, but it restricts itself to C headers only.
  - drainyard 7y ago
    I used to agree with this, but having spent a while in a very good C++ project (by C++ standards), even if we try to always forward declare and not include any unnecessary headers in headers, we still have a clean debug build time of 30-40 minutes. Even changing a single line in a cpp file, will still take around 30-40 seconds at best with incremental builds. I think long compile times are in the eye of the beholder, but often it feels like people have just gotten used to unnecessarily long compile times because they've forgotten how fast computers are and how fast a compiler should be for most of the work except for maybe some of the more complex optimizations in -O3. It kills productivity, and should really be a much larger focus than it sometimes seems to be.
    - hohenheim 7y ago
      Well said, I could not have said it better. Just to add, the productivity boost you get from short build times, in a long run, think of a project you work on for years, will out perform ANY gain you get from using a library, templates, and the like that kills your build time.
    - magicalhippo 7y ago
      We use Delphi at work, just did a full rebuild of our core product, 978015 LOC compiled and linked in 22 seconds on my aging i7 4790k.
    - jbverschoor 7y ago
      If it’s just a single line at a leaf in the deptree, it should only be taking time to link everything together. Still, long compile cycles are my kryptonite... 0 productivity. Horrible. Back when I was doing java, I patched hibernate to serialize and deserialize the generated code, so startuptimes would be lowered with about 80%. My setup back then used hot code replacement, but so many people would just simply wait 1-3minutes for every single change...
  - flohofwoe 7y ago
    As soon as you include C++ stdlib headers (even only for the stdlib features you're actually using), you have tens- to hundreds-of-thousands of lines of complex template code in front of your own code, and this in each compilation unit. In the end your own code is maybe one percent of all the code the C++ compiler needs to work through each time something is compiled (depending on how many source files you have, this is also why unity builds - merging all source files into one - are so much faster in C++). In comparison, CRT headers (when compiled as C, not as C++, as in that case additional C++ bloat is added) are usually a few dozen to a few hundred lines of simple declaration code. Compared to C++, it's very hard to make a C project compile slowly.
  - LessDmesg 7y ago
    "Bad use of header files" is the fault of C++, not the developers. Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.
    - AlexeyBrin 7y ago
      > Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development. C++ does not have a BDFL like other languages, C++ evolution is governed by a committee. In other words, Stroustrup himself needs to submit any changes he wants to the committee and there is a vote ... C++20 modules should partially solve the header processing problem, but it will take years until it will become widespread in big companies.
- crazypython 7y ago
  Y'all should try D! D compiles really fast-- the D reference compiler can compile itself, the standard library, and the codegen backend in less than 5 seconds, on a single laptop core. It uses a streaming architecture to achieve this. It runs fast because it is supported by both GCC and LLVM. One of its guiding principles is the thing that looks like C works like C-- all members of a file public by default, for example. Some experimental compiler builds (Calypso) can compile D for use with C++ libraries as complex as Qt. You can start porting your D project to C by using DPP- it allows you to #include C headers within D- and use macros. Putting "extern(C):" at the top of your file let's you interoperate between C and D. Andrei Alexandrescu wrote Modern C++ Design, and is the co-captain of D. The captain of D created the first end-to-end C++ compiler.
maeln 7y ago
I remember seeing people from INRIA talking about CompCert (a formally verified C compiler http://compcert.inria.fr http://compcert.inria.fr) and the main idea was that C was still the main language used in some critical application like aviation and military equipment. This is why it was not rare to see defense company or Airbus financing those research.
parkovski 7y ago
It's very confusing, they start off saying C++ is too complicated and then go basically reinventing C++ with (IMO) absolutely awful syntax. I think they're missing the point of why people use C - there's no magic. It's pretty much the wysiwyg of high level -> asm. If you want a systems language with magic there's C++. If you want a safe one there's Rust. Personally if I were going to make C better, I'd add a better macro/template feature so you don't have to write generic code as a define block with slashes all over, something like Go's defer, and some low level stack unwinding support. Maybe tuples as struts with numbered fields, but no magic syntax sugar. And that's it. No crazy operators, type theory things, or anything that doesn't do exactly what the code says. Because then it's not C. But what do I know?
- ernst_klim 7y ago
  > C - there's no magic Strict aliasing and weak typing say hello. > wysiwyg of high level -> asm Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.
  - madmax96 7y ago
    How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represent floating point numbers, etc. so how can the standard impose a requirement on what happens when you, say, access a double as an int? What do you mean by weak typing? That can you cast away basically anything? >It's easier to predict OCaml assembly output than the GCC's one Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks? IMO GCC's output isn't even a little surprising, esp. once you've gained experience with its favorite optimizations.
    - wwright 7y ago
      Not only can you cast away anything, but: - casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism - basically anything involving numerics has a good chance of happily casting for you without asking you or telling you
nirui 7y ago
> In the age of Go and Rust, which already have a hard time finding niches To make the time even harder, in that niche space, you already have decent enough languages like Nim and Zig etc. So yeah, the market is really pretty saturated, I don't even have time and project idea to try them all, let alone bring them to work.

by dvt 7y ago

gambiting 7y ago

I don't know, I work in the games industry and we're currently building a small project that's probably 95% C(the only C++ we have is for one library that has to have a C++ wrapper). It's just.....we don't need the C++ features, the compilation times are instant(last project I worked on was a large AAA game in C++ and compiling it from scratch was about 40-50 minutes on a single workstation), and pretty much all libs are C anyway. I'm not going to make the performance argument since it's mostly irrelevant nowadays, but I just don't see us using C as anything out of ordinary.

jbverschoor 7y ago
Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.
- kgabis 7y ago
  I'm yet to see a C++ project that compiles as fast as a C one.
  - dTal 7y ago
    About a decade ago I used a Zipit Z2 as my primary machine, as a fun experiment. It had 32 megabytes of RAM. Back then, that meant you could just about run Debian (who needs X11 anyway). Believe it or not, I often compiled software on this thing, and I quickly noticed that projects written in C would generally compile, while C++ builds would invariably choke from memory exhaustion. This was actually the first time I became aware of any difference between the two. A very educational experience!
  - rleigh 7y ago
    groff does, but it restricts itself to C headers only.
- drainyard 7y ago
  I used to agree with this, but having spent a while in a very good C++ project (by C++ standards), even if we try to always forward declare and not include any unnecessary headers in headers, we still have a clean debug build time of 30-40 minutes. Even changing a single line in a cpp file, will still take around 30-40 seconds at best with incremental builds. I think long compile times are in the eye of the beholder, but often it feels like people have just gotten used to unnecessarily long compile times because they've forgotten how fast computers are and how fast a compiler should be for most of the work except for maybe some of the more complex optimizations in -O3. It kills productivity, and should really be a much larger focus than it sometimes seems to be.
  - hohenheim 7y ago
    Well said, I could not have said it better. Just to add, the productivity boost you get from short build times, in a long run, think of a project you work on for years, will out perform ANY gain you get from using a library, templates, and the like that kills your build time.
  - magicalhippo 7y ago
    We use Delphi at work, just did a full rebuild of our core product, 978015 LOC compiled and linked in 22 seconds on my aging i7 4790k.
  - jbverschoor 7y ago
    If it’s just a single line at a leaf in the deptree, it should only be taking time to link everything together. Still, long compile cycles are my kryptonite... 0 productivity. Horrible. Back when I was doing java, I patched hibernate to serialize and deserialize the generated code, so startuptimes would be lowered with about 80%. My setup back then used hot code replacement, but so many people would just simply wait 1-3minutes for every single change...
- flohofwoe 7y ago
  As soon as you include C++ stdlib headers (even only for the stdlib features you're actually using), you have tens- to hundreds-of-thousands of lines of complex template code in front of your own code, and this in each compilation unit. In the end your own code is maybe one percent of all the code the C++ compiler needs to work through each time something is compiled (depending on how many source files you have, this is also why unity builds - merging all source files into one - are so much faster in C++). In comparison, CRT headers (when compiled as C, not as C++, as in that case additional C++ bloat is added) are usually a few dozen to a few hundred lines of simple declaration code. Compared to C++, it's very hard to make a C project compile slowly.
- LessDmesg 7y ago
  "Bad use of header files" is the fault of C++, not the developers. Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.
  - AlexeyBrin 7y ago
    > Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development. C++ does not have a BDFL like other languages, C++ evolution is governed by a committee. In other words, Stroustrup himself needs to submit any changes he wants to the committee and there is a vote ... C++20 modules should partially solve the header processing problem, but it will take years until it will become widespread in big companies.
crazypython 7y ago
Y'all should try D! D compiles really fast-- the D reference compiler can compile itself, the standard library, and the codegen backend in less than 5 seconds, on a single laptop core. It uses a streaming architecture to achieve this. It runs fast because it is supported by both GCC and LLVM. One of its guiding principles is the thing that looks like C works like C-- all members of a file public by default, for example. Some experimental compiler builds (Calypso) can compile D for use with C++ libraries as complex as Qt. You can start porting your D project to C by using DPP- it allows you to #include C headers within D- and use macros. Putting "extern(C):" at the top of your file let's you interoperate between C and D. Andrei Alexandrescu wrote Modern C++ Design, and is the co-captain of D. The captain of D created the first end-to-end C++ compiler.

maeln 7y ago

I remember seeing people from INRIA talking about CompCert (a formally verified C compiler http://compcert.inria.fr http://compcert.inria.fr) and the main idea was that C was still the main language used in some critical application like aviation and military equipment. This is why it was not rare to see defense company or Airbus financing those research.

parkovski 7y ago

It's very confusing, they start off saying C++ is too complicated and then go basically reinventing C++ with (IMO) absolutely awful syntax. I think they're missing the point of why people use C - there's no magic. It's pretty much the wysiwyg of high level -> asm. If you want a systems language with magic there's C++. If you want a safe one there's Rust. Personally if I were going to make C better, I'd add a better macro/template feature so you don't have to write generic code as a define block with slashes all over, something like Go's defer, and some low level stack unwinding support. Maybe tuples as struts with numbered fields, but no magic syntax sugar. And that's it. No crazy operators, type theory things, or anything that doesn't do exactly what the code says. Because then it's not C. But what do I know?

ernst_klim 7y ago
> C - there's no magic Strict aliasing and weak typing say hello. > wysiwyg of high level -> asm Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.
- madmax96 7y ago
  How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represent floating point numbers, etc. so how can the standard impose a requirement on what happens when you, say, access a double as an int? What do you mean by weak typing? That can you cast away basically anything? >It's easier to predict OCaml assembly output than the GCC's one Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks? IMO GCC's output isn't even a little surprising, esp. once you've gained experience with its favorite optimizations.
  - wwright 7y ago
    Not only can you cast away anything, but: - casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism - basically anything involving numerics has a good chance of happily casting for you without asking you or telling you

nirui 7y ago

> In the age of Go and Rust, which already have a hard time finding niches To make the time even harder, in that niche space, you already have decent enough languages like Nim and Zig etc. So yeah, the market is really pretty saturated, I don't even have time and project idea to try them all, let alone bring them to work.