7 ms·

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

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.
- reactordev 10mo ago
  I agree 100%. Just pointing out there’s efforts in this area for better or worse. My rant is really about sensible defaults that should enforce security and standards (stdlib after all) instead of having to juggle archaic edge cases from hardware of 30 years ago or adding more keyword sugar to your signature to make it through. Go is fun to write though.
throwaway17_17 10mo ago
What is the proposed replacement for ASM (in particular) and C in the context of the bootstrapping process? Then why lump ELF (unless you don’t mean the executable format) in with the low level language? Historically, pjmlp has pushed very strongly for languages attempting to take the place of C and C++ at the infrastructure layer can not claim to have supplanted those two until their own compiler and related infrastructure is not dependent on C++ (LLVM in particular). I tend to sympathize with this view, it is really hard to take a language’s claim to have supplanted C++ and be the only fit for use language going forward, but then is dependent on millions of lines of the languages they disparage. As a counter however, it’s rather difficult to expect a language to overcome thousands of person-years of work on a compiler like LLVM and tens of thousands of person-years on Linux. The newer languages should be able to make an articulate case that throwing away so much work is not a viable approach and just use what exists now but keep the new languages on all greenfield projects.
- steveklabnik 10mo ago
  As another counter, Rust has never claimed to have "supplanted" C++. So holding it to that standard is holding it to a non-goal for itself in the first place.
  - throwaway17_17 10mo ago
    tl;dr - Rust wants to be a foundational language of the computing stack and holding it to the standard of being bootstrapped, instead of relying on another language, is a reasonable critique. Clearly Rust the language and the associated organization would not make that claim. Particularly where supplanted is a past tense verb and indicates that it is a completed project. However, despite overblown complaints about the RESF, the community both in commentary and in practice has been extremely vocal that any language that does not have Rust’s memory safety model is not suitable for any new project or further use in existing projects. And while the RIIR meme is for the most part a message board strawman, again, the community surrounding Rust is busy reimplementing coreutils in Linux, putting Rust in the kernel, and rewriting the userland executables that most Linux workflows are based around (ripgrep being the most successful in this group). It is clear that Rust, the community of users (if not the language as an independent entity) clearly wants to supplant both C and C++ at all levels of the computing stack. The push for Rust in the Linux kernel is enough evidence to support the concept at the most pervasive level. Continuous references to wide spread adoption and endorsements by ‘big tech’ is used to frame Rust as the only viable option going forward. Blog posts, Reddit threads, and board comments all routinely take the stance that memory-safety (as defined by Rust) is ‘table stakes’ for any development occuring in current year. It feels disingenuous to pretend that Rust is not trying to become the industry standard language in the way C and C++ is today and has been for multiple decades. And given that aim, I think talking about Rust, as the name for both the language and its community of users and supporters, is working to supplant C and C++. Given all that, I find it fair to discuss the fact that while busy trying to maneuver itself into every space in the tech industry (from embedded all the way up to the front end for web web apps) and find some success in doing so Rust is still reliant on C++ infrastructure particularly for compilation. I was responding to a pair of comments about the desire to see languages that want to be the bedrock of the computing stack bootstrapped. I think Rust absolutely wants to be such a bedrock language and as such, I don’t think wanting it to be bootstrapped and not reliant on the C++ it want to replace is an unreasonable standard to hold the language to.

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.
reactordev 10mo ago
I agree 100%. Just pointing out there’s efforts in this area for better or worse. My rant is really about sensible defaults that should enforce security and standards (stdlib after all) instead of having to juggle archaic edge cases from hardware of 30 years ago or adding more keyword sugar to your signature to make it through. Go is fun to write though.

throwaway17_17 10mo ago

What is the proposed replacement for ASM (in particular) and C in the context of the bootstrapping process? Then why lump ELF (unless you don’t mean the executable format) in with the low level language? Historically, pjmlp has pushed very strongly for languages attempting to take the place of C and C++ at the infrastructure layer can not claim to have supplanted those two until their own compiler and related infrastructure is not dependent on C++ (LLVM in particular). I tend to sympathize with this view, it is really hard to take a language’s claim to have supplanted C++ and be the only fit for use language going forward, but then is dependent on millions of lines of the languages they disparage. As a counter however, it’s rather difficult to expect a language to overcome thousands of person-years of work on a compiler like LLVM and tens of thousands of person-years on Linux. The newer languages should be able to make an articulate case that throwing away so much work is not a viable approach and just use what exists now but keep the new languages on all greenfield projects.

steveklabnik 10mo ago
As another counter, Rust has never claimed to have "supplanted" C++. So holding it to that standard is holding it to a non-goal for itself in the first place.
- throwaway17_17 10mo ago
  tl;dr - Rust wants to be a foundational language of the computing stack and holding it to the standard of being bootstrapped, instead of relying on another language, is a reasonable critique. Clearly Rust the language and the associated organization would not make that claim. Particularly where supplanted is a past tense verb and indicates that it is a completed project. However, despite overblown complaints about the RESF, the community both in commentary and in practice has been extremely vocal that any language that does not have Rust’s memory safety model is not suitable for any new project or further use in existing projects. And while the RIIR meme is for the most part a message board strawman, again, the community surrounding Rust is busy reimplementing coreutils in Linux, putting Rust in the kernel, and rewriting the userland executables that most Linux workflows are based around (ripgrep being the most successful in this group). It is clear that Rust, the community of users (if not the language as an independent entity) clearly wants to supplant both C and C++ at all levels of the computing stack. The push for Rust in the Linux kernel is enough evidence to support the concept at the most pervasive level. Continuous references to wide spread adoption and endorsements by ‘big tech’ is used to frame Rust as the only viable option going forward. Blog posts, Reddit threads, and board comments all routinely take the stance that memory-safety (as defined by Rust) is ‘table stakes’ for any development occuring in current year. It feels disingenuous to pretend that Rust is not trying to become the industry standard language in the way C and C++ is today and has been for multiple decades. And given that aim, I think talking about Rust, as the name for both the language and its community of users and supporters, is working to supplant C and C++. Given all that, I find it fair to discuss the fact that while busy trying to maneuver itself into every space in the tech industry (from embedded all the way up to the front end for web web apps) and find some success in doing so Rust is still reliant on C++ infrastructure particularly for compilation. I was responding to a pair of comments about the desire to see languages that want to be the bedrock of the computing stack bootstrapped. I think Rust absolutely wants to be such a bedrock language and as such, I don’t think wanting it to be bootstrapped and not reliant on the C++ it want to replace is an unreasonable standard to hold the language to.