10 ms·

> 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

by Cyph0n 9y 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 9y 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 9y 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 9y 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 9y 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).
    - Cyph0n 9y ago
      Is this[1] what you call "memory management"? > It's a strong statement in that it uses absolutes, but it's pretty obvious. Two can play at that game. You are completely wrong. If your best example of an environment where a GC might not be a good fit is game development, then you are in no position to use such absolute statements. Personally, I tend to add "I think" or "I believe" whenever I am making statements that are outside of my realm of expertise. This prevents me from making a fool of myself ;) > In other cases, you can just mind your allocations. Good luck getting Go to run efficiently on a microcontroller without a ton of weird hacks. Whether you like it or not, there are areas where Go will simply never be able to compete with proper systems languages like C or C++. This is by design: Go simply has different goals. > as opposed to picking one at random ? [1] https://stackoverflow.com/questions/19848413/can-you-deallocate-memory-with-go-garbage-collection-disabled https://stackoverflow.com/questions/19848413/can-you-dealloc...
      - weberc2 9y ago
        > Is this[1] what you call "memory management"? Strictly speaking, it's one option; no worse than C. That said, I'd probably just manage my own arenas and avoid dynamic allocation. > Two can play at that game. You are completely wrong. If your best example of an environment where a GC might not be a good fit is game development, then you are in no position to use such absolute statements No need to get combative. I was quite clear--there are many systems that are frequently described as "not-GC friendly" (like games) for which Go's GC is suitable. These are soft real time systems. There are other hard real time systems for which Go's GC is not suitable, like the automotive systems I worked on in my last job. Go can serve hard realtime systems too (just use it like you would use C), but it's often not the best tool for that job. > Personally, I tend to add "I think" or "I believe" whenever I am making statements that are outside of my realm of expertise. I was an embedded engineer for a critical hard real time system in a previous life. This _is_ my area of expertise. > This prevents me from making a fool of myself If you say so. ;) > Good luck getting Go to run efficiently on a microcontroller without a ton of weird hacks. Granted, but this has nothing to do with GC. > ? Picking at random is an alternative to choosing a language by comparing candidate languages.

by Cyph0n 9y ago

mswift42 9y 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 9y 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 9y 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 9y 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).
  - Cyph0n 9y ago
    Is this[1] what you call "memory management"? > It's a strong statement in that it uses absolutes, but it's pretty obvious. Two can play at that game. You are completely wrong. If your best example of an environment where a GC might not be a good fit is game development, then you are in no position to use such absolute statements. Personally, I tend to add "I think" or "I believe" whenever I am making statements that are outside of my realm of expertise. This prevents me from making a fool of myself ;) > In other cases, you can just mind your allocations. Good luck getting Go to run efficiently on a microcontroller without a ton of weird hacks. Whether you like it or not, there are areas where Go will simply never be able to compete with proper systems languages like C or C++. This is by design: Go simply has different goals. > as opposed to picking one at random ? [1] https://stackoverflow.com/questions/19848413/can-you-deallocate-memory-with-go-garbage-collection-disabled https://stackoverflow.com/questions/19848413/can-you-dealloc...
    - weberc2 9y ago
      > Is this[1] what you call "memory management"? Strictly speaking, it's one option; no worse than C. That said, I'd probably just manage my own arenas and avoid dynamic allocation. > Two can play at that game. You are completely wrong. If your best example of an environment where a GC might not be a good fit is game development, then you are in no position to use such absolute statements No need to get combative. I was quite clear--there are many systems that are frequently described as "not-GC friendly" (like games) for which Go's GC is suitable. These are soft real time systems. There are other hard real time systems for which Go's GC is not suitable, like the automotive systems I worked on in my last job. Go can serve hard realtime systems too (just use it like you would use C), but it's often not the best tool for that job. > Personally, I tend to add "I think" or "I believe" whenever I am making statements that are outside of my realm of expertise. I was an embedded engineer for a critical hard real time system in a previous life. This _is_ my area of expertise. > This prevents me from making a fool of myself If you say so. ;) > Good luck getting Go to run efficiently on a microcontroller without a ton of weird hacks. Granted, but this has nothing to do with GC. > ? Picking at random is an alternative to choosing a language by comparing candidate languages.