6 ms·

> If everyone followed this approach, we would never have ended up with amazing languages like Rust. What approach would that be? > Why try to improve C++ if

> If everyone followed this approach, we would never have ended up with amazing languages like Rust. What approach would that be? > Why try to improve C++ if you can build cool stuff with it, right? Go improves on C++ in at least one regard, compile time. And there they succeeded spectacularly. While I like Rust, imagine how great it would be with Go's compile speed..

Cyph0n 8y ago
> What approach would that be? Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. > Go improves on C++ in at least one regard Go is a GCed language, so you can't really compare it to C++.
- mswift42 8y ago
  > Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. > Go is a GCed language, so you can't really compare it to C++. That's a very strange thing to say.
  - Cyph0n 8y ago
    > GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. And I don't, so let's just agree to disagree on that. > That's a very strange thing to say. Does this (or any other) advantage of Go help people who are writing software that cannot have a GC in the loop? No, it does not, so it's really not a valid comparison imo. Could Rust and C++ have better compile times? Maybe. I'll defer judgement to the actual compiler experts though.
    - mswift42 8y ago
      it is my understanding that the bad C++ compilation speed is one of the reasons behind Go's inception. Go has a GC because its creators thought they needed one to support concurrency.
    - weberc2 8y ago
      > Does this (or any other) advantage of Go help people who are writing software that cannot have a GC in the loop? No, it does not, so it's really not a valid comparison imo. This is also a very strange rationale, for several reasons. 1. You can program in Go without a GC 2. There are no applications that prohibit GCs; there are _some_ which prohibit long and/or nondeterministic pause times 3. Even if you were right about 1 and 2, these still wouldn't be reasons for not comparing Go and C++. In particular, your argument is in the form: "You can't compare Go and C++ because {comparison between Go and C++}".
      - Cyph0n 8y ago
        > 1. You can program in Go without a GC But Go was designed to be used with a GC, no? I see the same argument used with D, even though a lot of the stdlib relies on a GC :P > 2. There are no applications that prohibit GCs You are making a very strong statement here. Since we're on HN, I'll give you the benefit of the doubt. I am not a GC expert, so I have a follow-up question: does a deterministic GC exist? If so, what kind of pause time bounds (error/variance) are we talking about? Depending on the answer to this, I could probably list several areas where the bounds are unacceptable. > 3. Even if you were right about 1 and 2, these still wouldn't be reasons for not comparing Go and C++. Of course you can compare the two languages, but my argument is that it's essentially a useless comparison.
        weberc2 8y ago
        > But Go was designed to be used with a GC, no? I'm not sure this question makes sense. It was designed for easy memory management for the default case by way of GC, but it was also designed to allow users to opt into their own memory management schemes for niche cases. In any case, this seems even less relevant than your original claim. > You are making a very strong statement here. Since we're on HN, I'll give you the benefit of the doubt. It's a strong statement in that it uses absolutes, but it's pretty obvious. "No GC" is not a requirement, it's an implementation decision that assumes GCs are incompatible with the actual requirements (usually something like, 'there may not be unexpected, long pauses' for some values of 'long' and 'unexpected'). In many such cases (for example, game development), Go's low-latency GC is perfectly suitable. In other cases, you can just mind your allocations. > Of course you can compare the two languages, but my argument is that it's essentially a useless comparison. I disagree. To pick a language to use for a new project, you're best served by comparing the candidate languages (as opposed to picking one at random).
- weberc2 8y ago
  > Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. I can't tell if you're arguing that all Turing complete languages are equally useful, or that "utility" is a bad metric for evaluating programming languages. In the first case, of course this is false or Docker would be written in BrainFuck. In the second case, you've given no alternative (maybe you rank languages by the coolness of the type system?) nor given any justification for why 'utility' is a bad metric.
  - Cyph0n 8y ago
    > I can't tell if you're arguing that all Turing complete languages are equally useful, or that "utility" is a bad metric for evaluating programming languages. I'm not sure why you think my argument is constrained to these two choices? I never said utility is bad. My argument is that critique of a language can be constructive even if the language has utility. In other words, I am against dismissing critique of a language simply because the language has utility.
    - weberc2 8y ago
      Well, no one was dismissing critique of a language _simply because the language has utility_, so I was giving you the benefit of the doubt that you weren't strawmanning or otherwise introducing an entirely unrelated topic. The OP said he didn't weight intellectual criticisms more highly than observations, which is a pretty reasonable position. I'll go a bit further and say that criticisms based on theories aren't worth very much when the belying theories do a bad job of predicting the observations. For example, if the theory is "Powerful type systems predict language utility" and the observation is "Very little software is built with languages with powerful type systems, especially very little _important_ software", then criticisms based on that theory aren't worth very much.
      - Cyph0n 8y ago
        > otherwise introducing an entirely unrelated topic. Are you even reading my comments? > I'll go a bit further and say that criticisms based on theories aren't worth very much when the belying theories do a bad job of predicting the observations. True, but only if the observations you make include both direct and indirect impacts. Following your example, it is true that very little software uses type system-oriented languages, but you are ignoring the impact such languages have made on other languages, tools, frameworks, and libraries. For instance, Haskell is not a widely used language, but some of its ideas have impacted other languages and domains in various ways.
__sr__ 8y ago
I’d rather have my compiler and tools spend the time doing their job well instead of me spending ages because my language doesn’t provide the right abstractions and forces me to build everything from scratch.
pjmlp 8y ago
Go's compile speed might be impressive over C++, but it is hardly so when compared against many compilers from the 90's, before C and C++'s massive adoption. When C++ modules finally get integrated in C++20, that advantage will fade away.

Cyph0n 8y ago

> What approach would that be? Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. > Go improves on C++ in at least one regard Go is a GCed language, so you can't really compare it to C++.

mswift42 8y ago
> Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. > Go is a GCed language, so you can't really compare it to C++. That's a very strange thing to say.
- Cyph0n 8y ago
  > GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. And I don't, so let's just agree to disagree on that. > That's a very strange thing to say. Does this (or any other) advantage of Go help people who are writing software that cannot have a GC in the loop? No, it does not, so it's really not a valid comparison imo. Could Rust and C++ have better compile times? Maybe. I'll defer judgement to the actual compiler experts though.
  - mswift42 8y ago
    it is my understanding that the bad C++ compilation speed is one of the reasons behind Go's inception. Go has a GC because its creators thought they needed one to support concurrency.
  - weberc2 8y ago
    > Does this (or any other) advantage of Go help people who are writing software that cannot have a GC in the loop? No, it does not, so it's really not a valid comparison imo. This is also a very strange rationale, for several reasons. 1. You can program in Go without a GC 2. There are no applications that prohibit GCs; there are _some_ which prohibit long and/or nondeterministic pause times 3. Even if you were right about 1 and 2, these still wouldn't be reasons for not comparing Go and C++. In particular, your argument is in the form: "You can't compare Go and C++ because {comparison between Go and C++}".
    - Cyph0n 8y ago
      > 1. You can program in Go without a GC But Go was designed to be used with a GC, no? I see the same argument used with D, even though a lot of the stdlib relies on a GC :P > 2. There are no applications that prohibit GCs You are making a very strong statement here. Since we're on HN, I'll give you the benefit of the doubt. I am not a GC expert, so I have a follow-up question: does a deterministic GC exist? If so, what kind of pause time bounds (error/variance) are we talking about? Depending on the answer to this, I could probably list several areas where the bounds are unacceptable. > 3. Even if you were right about 1 and 2, these still wouldn't be reasons for not comparing Go and C++. Of course you can compare the two languages, but my argument is that it's essentially a useless comparison.
      - weberc2 8y ago
        > But Go was designed to be used with a GC, no? I'm not sure this question makes sense. It was designed for easy memory management for the default case by way of GC, but it was also designed to allow users to opt into their own memory management schemes for niche cases. In any case, this seems even less relevant than your original claim. > You are making a very strong statement here. Since we're on HN, I'll give you the benefit of the doubt. It's a strong statement in that it uses absolutes, but it's pretty obvious. "No GC" is not a requirement, it's an implementation decision that assumes GCs are incompatible with the actual requirements (usually something like, 'there may not be unexpected, long pauses' for some values of 'long' and 'unexpected'). In many such cases (for example, game development), Go's low-latency GC is perfectly suitable. In other cases, you can just mind your allocations. > Of course you can compare the two languages, but my argument is that it's essentially a useless comparison. I disagree. To pick a language to use for a new project, you're best served by comparing the candidate languages (as opposed to picking one at random).
weberc2 8y ago
> Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. I can't tell if you're arguing that all Turing complete languages are equally useful, or that "utility" is a bad metric for evaluating programming languages. In the first case, of course this is false or Docker would be written in BrainFuck. In the second case, you've given no alternative (maybe you rank languages by the coolness of the type system?) nor given any justification for why 'utility' is a bad metric.
- Cyph0n 8y ago
  > I can't tell if you're arguing that all Turing complete languages are equally useful, or that "utility" is a bad metric for evaluating programming languages. I'm not sure why you think my argument is constrained to these two choices? I never said utility is bad. My argument is that critique of a language can be constructive even if the language has utility. In other words, I am against dismissing critique of a language simply because the language has utility.
  - weberc2 8y ago
    Well, no one was dismissing critique of a language _simply because the language has utility_, so I was giving you the benefit of the doubt that you weren't strawmanning or otherwise introducing an entirely unrelated topic. The OP said he didn't weight intellectual criticisms more highly than observations, which is a pretty reasonable position. I'll go a bit further and say that criticisms based on theories aren't worth very much when the belying theories do a bad job of predicting the observations. For example, if the theory is "Powerful type systems predict language utility" and the observation is "Very little software is built with languages with powerful type systems, especially very little _important_ software", then criticisms based on that theory aren't worth very much.
    - Cyph0n 8y ago
      > otherwise introducing an entirely unrelated topic. Are you even reading my comments? > I'll go a bit further and say that criticisms based on theories aren't worth very much when the belying theories do a bad job of predicting the observations. True, but only if the observations you make include both direct and indirect impacts. Following your example, it is true that very little software uses type system-oriented languages, but you are ignoring the impact such languages have made on other languages, tools, frameworks, and libraries. For instance, Haskell is not a widely used language, but some of its ideas have impacted other languages and domains in various ways.

__sr__ 8y ago

I’d rather have my compiler and tools spend the time doing their job well instead of me spending ages because my language doesn’t provide the right abstractions and forces me to build everything from scratch.

pjmlp 8y ago

Go's compile speed might be impressive over C++, but it is hardly so when compared against many compilers from the 90's, before C and C++'s massive adoption. When C++ modules finally get integrated in C++20, that advantage will fade away.