61–70 of 106 posts
> Go can be a viable alternative to C as a systems programming language Stop this nonsense please. This does not show anything even remotely close to systems programming capability of Go. Write a device driver in Go that performs without lagging, benchmark it and then come back.
https://news.ycombinator.com/item?id=18399389 . It's been done. Performs well.
How many times have the tests been run? Once? First for C, then for Go? What about disk caching then? What I can see there is that for the same algorithm, the Go version was not so fast. It was comparable. The memory overhead could be caused by the size of the program, as wc has more functionalities. Then there is compared a totally different algorithm with a false claim "this way a go implementation is faster than a…
Being a garbage collected language with a runtime, Go certainly cannot match the performance of C, and it was never my point to prove otherwise - obviously, for the same algorithm, the C implementation would be faster. Instead, I was exploring Go to highlight how simple it is to write safe, concurrent code in it.
What about power consumption?
I'm really surprised by how much memory this task needs. Using a 16KB buffer and incrementing an integer needs multiple MB. I guess that's the size of the executable after it's been loaded into RAM that's so large?
Earlier quoted context omitted.
I actually disagree. If you look at the code written in the article, it's hardly unreadable or very code golf-y as you suggest. I think the author is really just trying to say that programmers shouldn't dismiss Go as a possible systems language in favor of C just because C has a reputation of being faster in all cases.
Are we really saying a garbage collected language should be considered for a systems language? I know the GC is fast but surely memory managed languages are going to have less issues with pausing during execution, no?
Regarding using Go as a real systems language (in the same meaning as C):
- gVisor hypervisor on Google Cloud and Linux sandbox on Chromebooks
- Android GPGPU debugger
- Fuchsia TCP/IP stack and volume management
- Baremetal TinyGo on Arduino Nano33 IoT, Adafruit Circuit Playground Express, BBC micro:bit among many others
- Coreboot firmware
Alternatively, here's my entry for "Beating C with 40 lines of C": https://pastebin.com/JzFfE5GB $ time wc -w 100m 2266395 100m real 0m4.568s $ cc -o wc wc.c $ time ./wc 100m 2343390 100m real 0m0.511s Of course, it disagrees on the answer, because I just used 100M of random data and it doesn't care about wide characters. It gives the same answer as GNU on plain ASCII text. It's not faster because it's better, it's f…
I can't recall who said it, but this reminds me of this idea: If you don't care about correctness then I can make it as fast as you like.
Yeah, let me just multithread and hand-optimize the piss out of this Go program until it's marginally faster than it would have been in C. Reminds me of the argument that venison tastes better than beef. The argument roughly being, "If you shoot the deer right, drag it home right, gut it right, skin it right, tenderize it right and cook it _just_ right, it'll be _almost_ as good as store-bought frozen beef"
Funny how times change.
> Go can be a viable alternative to C as a systems programming language Stop this nonsense please. This does not show anything even remotely close to systems programming capability of Go. Write a device driver in Go that performs without lagging, benchmark it and then come back.
- gVisor hypervisor on Google Cloud and Linux sandbox on Chromebooks
- Android GPGPU debugger
- Fuchsia TCP/IP stack and volume management
- Baremetal TinyGo on Arduino Nano33 IoT, Adafruit Circuit Playground Express, BBC micro:bit among many others
- Coreboot firmware
- Biscuit POSIX like OS
> I hope it demonstrates that Go can be a viable alternative to C as a systems programming language. Are you kidding me? This is nothing close to a systems programming language. This isn't much of a comparison at all. wc is a very simple case that doesn't match the complexity of real-world programs. Go comes close here because you're not using the high-level abstractions and that make it useful in the real world. GNU…
- gVisor hypervisor on Google Cloud and Linux sandbox on Chromebooks
- Android GPGPU debugger
- Fuchsia TCP/IP stack and volume management
- Baremetal TinyGo on Arduino Nano33 IoT, Adafruit Circuit Playground Express, BBC micro:bit among many others
- Coreboot firmware
- Biscuit POSIX like OS
ISO C does not support AVX-512, and plenty of languages do as language extension.
Earlier quoted context omitted.
Furthermore this isn't "system programming", he just replaced a "user land" program with another. But I blame the Go team for turning "system programming" and "realtime programming" into useless buzzwords to promote their language.
Yeah when I first looked at go that was the first 'no fu' for me. Go isn't a systems or real time programming language. It's a managed language with training wheels. Which is okay by me. Lying about it though is not okay. The second FU is they claim that decisions they made based on personal preferences were technical ones. That's a very insidious lie that programmers make all the time. Insidious because it destroys…
- gVisor hypervisor on Google Cloud and Linux sandbox on Chromebooks
- Android GPGPU debugger
- Fuchsia TCP/IP stack and volume management
- Baremetal TinyGo on Arduino Nano33 IoT, Adafruit Circuit Playground Express, BBC micro:bit among many others
- Coreboot firmware
- Biscuit POSIX like OS
But whatever, the GC-FUD is strong among C devotees.