7 ms·

My pet peeve with c++ is exactly this. Either it’s not wise to call release, or it is (under circumstances) and yet the developer has no idea whether their scen

My pet peeve with c++ is exactly this. Either it’s not wise to call release, or it is (under circumstances) and yet the developer has no idea whether their scenario applies (tip: it doesn’t, 90% of the time). The stdlib is so bloated with these “Looks good, but wait” logic bombs. I wish someone would just draw a line in the sand and say “No, from here on out, this is how this works and there are no other scenarios in which there needs a work around”. This is why other systems languages are taking off (besides the expressiveness or memory safety bandwagon) is because there are clear instructions in the docs on what this does with examples of how to use it properly. Most c++ codebases I’ve seen the last 10 years are decent (a few are superb) and I get that there’s old code out there but at what point do we let old dogs die?

GuB-42 10mo ago
C++ has always been a "kitchen sink" language, it is used in many different ways and drawing any line may alienate an entire industry. > This is why other systems languages are taking off Great! It is not a competition. If you think that Rust is a better choice, use Rust, don't make C++ into Rust. Or maybe try Carbon, it looks like it is the language you want. But if you have some old dogs you want to keep alive, then use C++, that's what it is for.
- reactordev 10mo ago
  I get it, I do. There’s a lot of old code out there. My point wasn’t that old dogs are bad. My point was about changing how we care for them. If you have old code that you want to compile, use -c98 or whatever to peg it to that. Leave the rest of us alone to introduce more modern ways of things. I’d even be happy to see removal of things.
pjmlp 10mo ago
> This is why other systems languages are taking off For the time being that are still being written with C++ infrastructure though. It would be great if those wannabe C++ replacements were fully bootstraped.
- reactordev 10mo ago
  Go compiles go, not sure what you mean by wannabe c++. There’s a frontend to gcc for go and working on rust. Is it the use of gcc you dislike? You’re going to have to explain some more. We’re stuck on ASM/ELF. We’re stuck on C of some kind. Maybe in the future LLMs can help us write low-level / high expressiveness code but until we get rid of 1970s “personal computer” decisions in silicon, we’re stuck with it.
  - pjmlp 10mo ago
    Go is not a wannabe C++ replacement. It could be, but its designers aren't keen in modern language design. First it needs to fulfill more use cases than Docker and Kubernetes ecosystem. And while TinyGO and TamaGo exist, they require custom runtimes, and Assembly tricks that C++ supports at the language level, or even Rust does better than Go. It is better than using Oberon-07 minimalist design, though.
    - throwaway17_17 10mo ago
      Can you expand on Oberon-07 minimalism in the context of bootstrapping or working at the lowest level of abstractions? Your posts about the Wirth tradition languages and their implementations are typically well founded and I haven’t read much on this aspect. If you just have a reference you’d suggest that would be more than enough (if you don’t want to take time explaining what has been written elsewhere).
      - pjmlp 10mo ago
        Hanspeter Mössenböck created Oberon-2 with feedback from Niklaus Wirth, and later went on to focus on .NET and Java instead, several of his studends have contributed to MaximeVM and later GraalVM research. Meanwhile the Oberon community diverged into Active Oberon, Zonnon, Component Pascal. However for Niklaus Wirth those were distractions, and he looked into how to take further features away from Oberon, which was already less feature rich than Modula-2. There were a few revisions from Oberon-07 between 2008 and 2016, each removing even more language features, before his retirement from computing world. "Differences between Revised Oberon and Oberon" https://people.inf.ethz.ch/wirth/Oberon/Oberon07.pdf https://people.inf.ethz.ch/wirth/Oberon/Oberon07.pdf "Porting the Oberon Compiler from Oberon to Oberon-07" The latest revision being, https://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf https://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf Niklaus Wirth goal became how to remove "needless fluff" out of Oberon, and still get enough features to have a systems programming language with a GC.
feelamee 10mo ago
> This is why other systems languages are taking off (besides the expressiveness or memory safety bandwagon) is because there are clear instructions in the docs on what this does with examples of how to use it properly. I have never seen better documentation for programming languages than cppreference. Can you list such docs?

GuB-42 10mo ago

C++ has always been a "kitchen sink" language, it is used in many different ways and drawing any line may alienate an entire industry. > This is why other systems languages are taking off Great! It is not a competition. If you think that Rust is a better choice, use Rust, don't make C++ into Rust. Or maybe try Carbon, it looks like it is the language you want. But if you have some old dogs you want to keep alive, then use C++, that's what it is for.

reactordev 10mo ago
I get it, I do. There’s a lot of old code out there. My point wasn’t that old dogs are bad. My point was about changing how we care for them. If you have old code that you want to compile, use -c98 or whatever to peg it to that. Leave the rest of us alone to introduce more modern ways of things. I’d even be happy to see removal of things.

pjmlp 10mo ago

> This is why other systems languages are taking off For the time being that are still being written with C++ infrastructure though. It would be great if those wannabe C++ replacements were fully bootstraped.

reactordev 10mo ago
Go compiles go, not sure what you mean by wannabe c++. There’s a frontend to gcc for go and working on rust. Is it the use of gcc you dislike? You’re going to have to explain some more. We’re stuck on ASM/ELF. We’re stuck on C of some kind. Maybe in the future LLMs can help us write low-level / high expressiveness code but until we get rid of 1970s “personal computer” decisions in silicon, we’re stuck with it.
- pjmlp 10mo ago
  Go is not a wannabe C++ replacement. It could be, but its designers aren't keen in modern language design. First it needs to fulfill more use cases than Docker and Kubernetes ecosystem. And while TinyGO and TamaGo exist, they require custom runtimes, and Assembly tricks that C++ supports at the language level, or even Rust does better than Go. It is better than using Oberon-07 minimalist design, though.
  - throwaway17_17 10mo ago
    Can you expand on Oberon-07 minimalism in the context of bootstrapping or working at the lowest level of abstractions? Your posts about the Wirth tradition languages and their implementations are typically well founded and I haven’t read much on this aspect. If you just have a reference you’d suggest that would be more than enough (if you don’t want to take time explaining what has been written elsewhere).
    - pjmlp 10mo ago
      Hanspeter Mössenböck created Oberon-2 with feedback from Niklaus Wirth, and later went on to focus on .NET and Java instead, several of his studends have contributed to MaximeVM and later GraalVM research. Meanwhile the Oberon community diverged into Active Oberon, Zonnon, Component Pascal. However for Niklaus Wirth those were distractions, and he looked into how to take further features away from Oberon, which was already less feature rich than Modula-2. There were a few revisions from Oberon-07 between 2008 and 2016, each removing even more language features, before his retirement from computing world. "Differences between Revised Oberon and Oberon" https://people.inf.ethz.ch/wirth/Oberon/Oberon07.pdf https://people.inf.ethz.ch/wirth/Oberon/Oberon07.pdf "Porting the Oberon Compiler from Oberon to Oberon-07" The latest revision being, https://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf https://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf Niklaus Wirth goal became how to remove "needless fluff" out of Oberon, and still get enough features to have a systems programming language with a GC.

feelamee 10mo ago

> This is why other systems languages are taking off (besides the expressiveness or memory safety bandwagon) is because there are clear instructions in the docs on what this does with examples of how to use it properly. I have never seen better documentation for programming languages than cppreference. Can you list such docs?