4 ms·

So, isn't this a strong argument against Go? At the point that you need to start devising clever workarounds to stop bad behavior from your runtime, it's time t

So, isn't this a strong argument against Go? At the point that you need to start devising clever workarounds to stop bad behavior from your runtime, it's time to find a new language.

wrs 7y ago
If you know of a language that has absolutely no unexpected behavior in its runtime under any workload, please let us know what it is!
- BubRoss 7y ago
  Modern C++, since there is no 'runtime' (and don't say linked in functions are a 'runtime'). If you have an example of where you think this breaks down I'll be happy to come up with a solution.
  - jchw 7y ago
    So when you throw an exception in C++, and the stack is being unwound, it is not being unwound by your C++ runtime? And the C++ standard library, specified in the same standard as the language, that you have, that has code present at runtime, is not part of the runtime? Someone should let Microsoft know they need to rename their “C++ Runtime Library” package.
    - Const-me 7y ago
      They all optional. Don't throw exceptions and they won't unwind. Standard library is optional, there're good alternatives like ATL and EASTL. Microsoft's package is optional, change a compiler switch and your binary will stop using or requiring that package. However, manual memory management makes development more expensive. Especially if you don't crunch numbers but parse strings. C++ probably ain't a good replacement for Go. For the last decades people and whole industries have been migrating the other way, from C++ to higher level memory safe languages, initially Java and C# then others followed.
      - jchw 7y ago
        Sigh. I avoided mentioning that the C++ runtime was optional because I was trying not to be pedantic and I assumed in context it would be understood that this was irrelevant. I think I should’ve just made my point earlier, but: - This all started with someone mentioning that C++ doesn’t have ‘bad runtime behavior’ because it doesn’t have a runtime, but this is false. It has a runtime, or to be exact, a specification for one, and I think it is safe to say a vast, perhaps extreme, majority of C++ developers are using it. - If you opt to not use the runtime, then your runtime behavior is dictated somewhere else, but runtime behaviors don’t go away. In freestanding, you may be your own runtime, but then your runtime behavior is defined by the machine you’re running on. You just get to choose what layer of abstraction you are sitting on. - edit: And also, as a point I forgot to mention initially, I don’t really feel like freestanding C++ vs standard Go is an apples-to-apples comparison. I think the point was that the C++ has less runtime behavior, since it doesn’t have a scheduler or garbage collector, but extrapolating that to no runtime is wrong even if the runtime is optional.
        Const-me 7y ago
        As far as I understood the context, it was about language runtimes. Underneath all languages, there’re usually OS kernel, drivers and hardware. They all have non-trivial amount of unexpected behavior, especially under load. But these apply to code written in all languages, almost equally. BTW, C++ does have a scheduler. Optional like the rest of the runtime, but it’s 1 line of code away in all modern compilers, that line starts with #pragma omp.
        jchw 7y ago
        Yes, that seems about right. There’s always behavior at runtime, and your language shields it away from you to varying degrees. It is the same for all languages, which is exactly what I am trying to drive home. However, even if you go to the extreme of not using any features that require runtime support, if you are using hosted C++, in practice you still have one bit of runtime: the entrypoint. Technically, an operating system could implement the bits that call main, but to the best of my knowledge none of them ever have. So every compiled binary from every hosted C++ implementation begins at the runtime library. (Admittedly, normally the C runtime library, since C++ doesn’t differ here, but that is just another layer deep of pedantics. In practice, everyone has a runtime.) Nitpick: As far as I am aware OpenMP is not part of the language itself but an extension. But yeah, you could argue that is runtime scheduling in C++, I think.
  - Gupie 7y ago
    There is heap defragmentation.
- ummonk 7y ago
  Baremetal assembly
  - presumably 7y ago
    Counterexample: https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug
    - saagarjha 7y ago
      Bugs are unintentional and can (and are) fixed.
  - johncolanduoni 7y ago
    Yeah, the book on performance concerns for assembly on Intel CPUs is pretty brief, only a few hundred pages: https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-optimization-reference-manual https://software.intel.com/en-us/download/intel-64-and-ia-32...
- Dylan16807 7y ago
  The problem isn't the unexpected behavior, it's needing "clever workarounds" to fix it. And they don't even have a workaround for the GC assist being way too aggressive, they're just sucking it up and letting the latency exist.
acrispino 7y ago
It's hacky but also simple to implement. Should the go gc improve to the point that it's unnecessary, it seems simple to remove as well. Wouldn't bother me much.
codegladiator 7y ago
> Strong argument against Go No Weak argument against Go ? No Let me know which language was perfect That there is a proposal to work this out and relevant people are working on this makes a strong argument for go IMO. https://github.com/golang/go/issues/23044 https://github.com/golang/go/issues/23044
JulianMorrison 7y ago
About all it implies about Go is that the language as an integrated system isn't yet fully polished. There is a corner case of strange behaviour due to aggressive GC when the absolute memory requirements of the program aren't large. It can be worked around by making them larger by a ballast allocation. This is not "time to find a new language", it's a small issue with a known fix and there's a proposal to repair it at source in the pipeline.
kitd 7y ago
A weak argument, maybe. The algorithm the pacer used seems reasonable in 99% of cases. Here's a fairly extreme case where it didn't. But further, it seems fairly easy to fix and indeed it looks like the Go team are doing just that.

So, isn't this a strong argument against Go? At the point that you need to start devising clever workarounds to stop bad behavior from your runtime, it's time to find a new language.

wrs 7y ago

If you know of a language that has absolutely no unexpected behavior in its runtime under any workload, please let us know what it is!

BubRoss 7y ago
Modern C++, since there is no 'runtime' (and don't say linked in functions are a 'runtime'). If you have an example of where you think this breaks down I'll be happy to come up with a solution.
- jchw 7y ago
  So when you throw an exception in C++, and the stack is being unwound, it is not being unwound by your C++ runtime? And the C++ standard library, specified in the same standard as the language, that you have, that has code present at runtime, is not part of the runtime? Someone should let Microsoft know they need to rename their “C++ Runtime Library” package.
  - Const-me 7y ago
    They all optional. Don't throw exceptions and they won't unwind. Standard library is optional, there're good alternatives like ATL and EASTL. Microsoft's package is optional, change a compiler switch and your binary will stop using or requiring that package. However, manual memory management makes development more expensive. Especially if you don't crunch numbers but parse strings. C++ probably ain't a good replacement for Go. For the last decades people and whole industries have been migrating the other way, from C++ to higher level memory safe languages, initially Java and C# then others followed.
    - jchw 7y ago
      Sigh. I avoided mentioning that the C++ runtime was optional because I was trying not to be pedantic and I assumed in context it would be understood that this was irrelevant. I think I should’ve just made my point earlier, but: - This all started with someone mentioning that C++ doesn’t have ‘bad runtime behavior’ because it doesn’t have a runtime, but this is false. It has a runtime, or to be exact, a specification for one, and I think it is safe to say a vast, perhaps extreme, majority of C++ developers are using it. - If you opt to not use the runtime, then your runtime behavior is dictated somewhere else, but runtime behaviors don’t go away. In freestanding, you may be your own runtime, but then your runtime behavior is defined by the machine you’re running on. You just get to choose what layer of abstraction you are sitting on. - edit: And also, as a point I forgot to mention initially, I don’t really feel like freestanding C++ vs standard Go is an apples-to-apples comparison. I think the point was that the C++ has less runtime behavior, since it doesn’t have a scheduler or garbage collector, but extrapolating that to no runtime is wrong even if the runtime is optional.
      - Const-me 7y ago
        As far as I understood the context, it was about language runtimes. Underneath all languages, there’re usually OS kernel, drivers and hardware. They all have non-trivial amount of unexpected behavior, especially under load. But these apply to code written in all languages, almost equally. BTW, C++ does have a scheduler. Optional like the rest of the runtime, but it’s 1 line of code away in all modern compilers, that line starts with #pragma omp.
        jchw 7y ago
        Yes, that seems about right. There’s always behavior at runtime, and your language shields it away from you to varying degrees. It is the same for all languages, which is exactly what I am trying to drive home. However, even if you go to the extreme of not using any features that require runtime support, if you are using hosted C++, in practice you still have one bit of runtime: the entrypoint. Technically, an operating system could implement the bits that call main, but to the best of my knowledge none of them ever have. So every compiled binary from every hosted C++ implementation begins at the runtime library. (Admittedly, normally the C runtime library, since C++ doesn’t differ here, but that is just another layer deep of pedantics. In practice, everyone has a runtime.) Nitpick: As far as I am aware OpenMP is not part of the language itself but an extension. But yeah, you could argue that is runtime scheduling in C++, I think.
- Gupie 7y ago
  There is heap defragmentation.
ummonk 7y ago
Baremetal assembly
- presumably 7y ago
  Counterexample: https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug
  - saagarjha 7y ago
    Bugs are unintentional and can (and are) fixed.
- johncolanduoni 7y ago
  Yeah, the book on performance concerns for assembly on Intel CPUs is pretty brief, only a few hundred pages: https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-optimization-reference-manual https://software.intel.com/en-us/download/intel-64-and-ia-32...
Dylan16807 7y ago
The problem isn't the unexpected behavior, it's needing "clever workarounds" to fix it. And they don't even have a workaround for the GC assist being way too aggressive, they're just sucking it up and letting the latency exist.

acrispino 7y ago

It's hacky but also simple to implement. Should the go gc improve to the point that it's unnecessary, it seems simple to remove as well. Wouldn't bother me much.

codegladiator 7y ago

> Strong argument against Go No Weak argument against Go ? No Let me know which language was perfect That there is a proposal to work this out and relevant people are working on this makes a strong argument for go IMO. https://github.com/golang/go/issues/23044 https://github.com/golang/go/issues/23044

JulianMorrison 7y ago

About all it implies about Go is that the language as an integrated system isn't yet fully polished. There is a corner case of strange behaviour due to aggressive GC when the absolute memory requirements of the program aren't large. It can be worked around by making them larger by a ballast allocation. This is not "time to find a new language", it's a small issue with a known fix and there's a proposal to repair it at source in the pipeline.

kitd 7y ago

A weak argument, maybe. The algorithm the pacer used seems reasonable in 99% of cases. Here's a fairly extreme case where it didn't. But further, it seems fairly easy to fix and indeed it looks like the Go team are doing just that.