16 ms·

Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at wri

Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at writing high performance servers that have to scale really big not only in terms of performance but software complexity, size and contributions. So Go is a better C++ or Java for writing servers according to its creators.

pjmlp 2mo ago
A better C++ is by definition a better C, no one should be using C in 21st century beyond UNIX clones, and embedded devs that are religiously against C++, even all modern C compilers are written in C++ nowadays. Anything you can think C is better, it isn't ISO C, rather non standard C compiler specific extensions, which can language can also be. Just do like in K&R C days, use Assembly for what language isn't directly capable of, and it is right there as part of a regular Go toolchain installation.
- loup-vaillant 2mo ago
  > A better C++ is by definition a better C The definition is wrong, then. I wrote C++ for most of my career. And as of late, I found myself avoiding more and more features from it. The STL is mostly trash, not worth the increase in compilation times. Templates are good for containers, but that’s about it. Inheritance and polymorphism are circumstantial enough that I’m not sure they’re worth adding to the language: in the rare cases I do need them, I can always write my v-table by hand. The more I write C++, the more I find C is not that far from that "much smaller and cleaner language struggling to get out". And I say that fully aware of the many egregious faults still present in C. There are two features from C++ I would really miss in a big C project: generics (templates), and destructors. But then we can always write a lightweight pre-processor to add those generics and a `defer` statement. Even if it requires a full parser, C parsers are pretty easy to write.
  - pjmlp 2mo ago
    I see it differently, given how C with Classes came to be, a Typescript for C in 1989.
    - doodpants 2mo ago
      The origin of a thing does not forever define what that thing is and always will be. C++ has evolved far beyond C with Classes.
    - loup-vaillant 2mo ago
      You know, I’m actually tempted right now to do my own "C with <my-features>". Except I wouldn’t make the same choices as Stroustrup did. For one, I wouldn’t aim for popularity. I’d want something that works for me, and I’d consider it a success even if I’m the sole user. Source compatibility would not be a goal, and I’d most probably skip classes entirely. The way C++ was first implemented was a good idea. It’s everything else I disagree with.
  - convivialdingo 2mo ago
    I've been toying with a better C... https://github.com/panaflexx/classyc https://github.com/panaflexx/classyc Started with the excellent MIR compiler, and I wrote much of the class/string/json/dict, exceptions and AI made the generics,ownership tracking, and safety checks/traps. Added some go The memory model is mixed, I ended up using arenas for dictionaries and adding a full ownership checking / safety checking compiler stage. It's purely for the joy of making something interesting.
    - derekbsnider 2mo ago
      Oh wow, interesting project... I've also been working on a "better c" for a few years, and while it was originally a JIT language (using jitasm), I recently switch to MIR, but since I already had my own lexer/parser/etc stack, I ended up changing it to basically lower everything into a node_t compatible AST tree and handing that off directly to c2mir, bypassing its parser. Maybe you're interested in collaborating? :) https://github.com/derekbsnider/madc https://github.com/derekbsnider/madc
      - convivialdingo 1mo ago
        That's incredible! I see you ran into many of the same MIR issues and limitations I did. I pulled several fork patches and wrote a thread local stack extension. I'll definitely check it out and see what I could do. I added two compiler stages - a decent memory ptr ownership tracker and midopt compiler optimizer you could likely use without many changes that improved performance 35% over c2mir.
win311fwg 2mo ago
> Yeah but they were so that intentionally trying to build a better C++/Java They were trying to build a faster Python, thinking that would appeal to C++ developers. The theory was that developers were using C++ at Google because they had to, not because they wanted to, and would choose something like Python instead if it were up to the performance task. Although it turned out in the end that C++ developers actually wanted to use C++.
- pjmlp 2mo ago
  No they weren't, in fact they were very surprised by the adoption from Python folks. "I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care." https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
  - win311fwg 2mo ago
    > No they weren't Indeed they were. Your quote even says so — seeking out to solve the problems C++ was thought to have, which is that it didn't have the ergonomics of languages like Python, as explained in the original public Go announcement. To "feel like a dynamically-typed language" was a primary motivation. That was clearly told. You can certainly hold the view that a better C++ and a fast Python are one and the same, but I suspect the HN crowd will vehemently disagree with you. Conflating the two would not serve to communicate much here. > were very surprised by the adoption from Python folks. Quite naturally. Python users were already using Python. One would be inclined to think that they didn't need another Python. Except it turns out they did, because it was actually they who needed a faster Python.
  - mpyne 2mo ago
    > No they weren't, in fact they were very surprised by the adoption from Python folks I'm kind of surprised that the Go creators were surprised by this. Like I know they didn't like C++, but Go is by no means a replacement for C++ despite whatever was said about "building a better C++/Java". It took so long to pick up generics that Rust was already around and the logical next step for C++ developers by the time that happened. And that's only scratching the surface of why people choose C++. On the other hand, having a more performant "simple" language that directly supports concurrency and lets you compile to native code without a ton of ceremony could be very helpful indeed if you're a Python dev who need to take an app to the next level without having to learn intricacies of C FFI or the GIL.

pjmlp 2mo ago

A better C++ is by definition a better C, no one should be using C in 21st century beyond UNIX clones, and embedded devs that are religiously against C++, even all modern C compilers are written in C++ nowadays. Anything you can think C is better, it isn't ISO C, rather non standard C compiler specific extensions, which can language can also be. Just do like in K&R C days, use Assembly for what language isn't directly capable of, and it is right there as part of a regular Go toolchain installation.

loup-vaillant 2mo ago
> A better C++ is by definition a better C The definition is wrong, then. I wrote C++ for most of my career. And as of late, I found myself avoiding more and more features from it. The STL is mostly trash, not worth the increase in compilation times. Templates are good for containers, but that’s about it. Inheritance and polymorphism are circumstantial enough that I’m not sure they’re worth adding to the language: in the rare cases I do need them, I can always write my v-table by hand. The more I write C++, the more I find C is not that far from that "much smaller and cleaner language struggling to get out". And I say that fully aware of the many egregious faults still present in C. There are two features from C++ I would really miss in a big C project: generics (templates), and destructors. But then we can always write a lightweight pre-processor to add those generics and a `defer` statement. Even if it requires a full parser, C parsers are pretty easy to write.
- pjmlp 2mo ago
  I see it differently, given how C with Classes came to be, a Typescript for C in 1989.
  - doodpants 2mo ago
    The origin of a thing does not forever define what that thing is and always will be. C++ has evolved far beyond C with Classes.
  - loup-vaillant 2mo ago
    You know, I’m actually tempted right now to do my own "C with <my-features>". Except I wouldn’t make the same choices as Stroustrup did. For one, I wouldn’t aim for popularity. I’d want something that works for me, and I’d consider it a success even if I’m the sole user. Source compatibility would not be a goal, and I’d most probably skip classes entirely. The way C++ was first implemented was a good idea. It’s everything else I disagree with.
- convivialdingo 2mo ago
  I've been toying with a better C... https://github.com/panaflexx/classyc https://github.com/panaflexx/classyc Started with the excellent MIR compiler, and I wrote much of the class/string/json/dict, exceptions and AI made the generics,ownership tracking, and safety checks/traps. Added some go The memory model is mixed, I ended up using arenas for dictionaries and adding a full ownership checking / safety checking compiler stage. It's purely for the joy of making something interesting.
  - derekbsnider 2mo ago
    Oh wow, interesting project... I've also been working on a "better c" for a few years, and while it was originally a JIT language (using jitasm), I recently switch to MIR, but since I already had my own lexer/parser/etc stack, I ended up changing it to basically lower everything into a node_t compatible AST tree and handing that off directly to c2mir, bypassing its parser. Maybe you're interested in collaborating? :) https://github.com/derekbsnider/madc https://github.com/derekbsnider/madc
    - convivialdingo 1mo ago
      That's incredible! I see you ran into many of the same MIR issues and limitations I did. I pulled several fork patches and wrote a thread local stack extension. I'll definitely check it out and see what I could do. I added two compiler stages - a decent memory ptr ownership tracker and midopt compiler optimizer you could likely use without many changes that improved performance 35% over c2mir.

win311fwg 2mo ago

> Yeah but they were so that intentionally trying to build a better C++/Java They were trying to build a faster Python, thinking that would appeal to C++ developers. The theory was that developers were using C++ at Google because they had to, not because they wanted to, and would choose something like Python instead if it were up to the performance task. Although it turned out in the end that C++ developers actually wanted to use C++.

pjmlp 2mo ago
No they weren't, in fact they were very surprised by the adoption from Python folks. "I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care." https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
- win311fwg 2mo ago
  > No they weren't Indeed they were. Your quote even says so — seeking out to solve the problems C++ was thought to have, which is that it didn't have the ergonomics of languages like Python, as explained in the original public Go announcement. To "feel like a dynamically-typed language" was a primary motivation. That was clearly told. You can certainly hold the view that a better C++ and a fast Python are one and the same, but I suspect the HN crowd will vehemently disagree with you. Conflating the two would not serve to communicate much here. > were very surprised by the adoption from Python folks. Quite naturally. Python users were already using Python. One would be inclined to think that they didn't need another Python. Except it turns out they did, because it was actually they who needed a faster Python.
- mpyne 2mo ago
  > No they weren't, in fact they were very surprised by the adoption from Python folks I'm kind of surprised that the Go creators were surprised by this. Like I know they didn't like C++, but Go is by no means a replacement for C++ despite whatever was said about "building a better C++/Java". It took so long to pick up generics that Rust was already around and the logical next step for C++ developers by the time that happened. And that's only scratching the surface of why people choose C++. On the other hand, having a more performant "simple" language that directly supports concurrency and lets you compile to native code without a ton of ceremony could be very helpful indeed if you're a Python dev who need to take an app to the next level without having to learn intricacies of C FFI or the GIL.