8 ms·
TLDR: Transition from C to Go. Go was designed by (among others) the father of Unix, Ken Thompson, with an understanding of the mistakes of C and C++. Despite
by bugfix-66 4y ago
TLDR: Transition from C to Go.
Go was designed by (among others) the father of Unix, Ken Thompson, with an understanding of the mistakes of C and C++. Despite getting hilariously little respect here on Hacker News, the language is (for many purposes) an excellent replacement for C.
(Yes, yes, I know you disagree. Tell me more about how C++ is necessary and all the time you spend fighting it is actually a huge win! Please tell me how slow garbage collection is, all evidence to the contrary!)
Go reads from, and writes to, variable-sized blocks of memory through (pointer, length, capacity) triples, known as "slices". A Go slice "[]int" is essentially a C struct like this, passed around in 3 registers:
struct IntSlice {
int* pointer;
ssize_t length;
ssize_t capacity;
};
Bounds checking in Go is easily disabled (pass -B flag to the compiler) but almost nobody does so because the performance benefit is miniscule. With bounds checking and garbage collection, Go avoids almost all memory-related bugs.
You can understand Go as C redesigned for a world where parallel computing (e.g., dozens of CPU cores) is commonplace, and the benefits of safe code outweigh the tiny costs.
We're not using 80286 chips anymore. We can afford safety.
- tsujamin 4y agoI've spent my last few weeks writing a platform in Go. Buffer management/strong typing is definitely an improvement on C. Shame about tall the null-pointer-exceptions though :') In all seriousness though it does seem to mitigate a lot of exploitable memory corruption vulns, perhaps not memory-corruption-caused Denial-of-Service vulnerabilities as well as Rust et all maybe.
- djbusby 4y agoGo gets little respect on HN? We're not reading the same threads.
- bugfix-66 4y agoObviously we aren't!
- djbusby 4y agotouché
- antegamisou 4y agoIt's nowhere nearly as hyped as Rust is here. Which is absurd considering Go is a more appropriate alternative to C. Even K from K&R uses it! https://youtu.be/VVpRj3Po6K4 https://youtu.be/VVpRj3Po6K4
- galangalalgol 4y agoWhy do people select c? I assume it is because it is the only compiler they have for some target hardware, or that they are working in a codebase like the Linux kernel. For the former go won't help. Tinygo may help some day, but for any weird new chip the first thing they make is a c compiler. The linux kernel accepts rust, or will next year. It does not accept go. So Torvalds at least disagrees it fits there. Go has plenty of uses, but writing microcontroller firmware and device drivers are not among them. And why else would you pick c?
- torstenvl 4y agoI default to C. It's fast, runs everywhere, works with everything, and has few surprises. It's standardized and not captured by any individual or organization. I can't think of a language that comes close to any of that.
- pjmlp 4y agoC++
- torstenvl 4y agoIf C++ had no operator overloading, and if it had no exceptions, and if the C++ standard specified name-mangling so FFI could work right, then maybe it would come close.
- pjmlp 4y agoYou are not obliged to use all of that in C++ code. And if lack of standard specified name-mangling disqualifies C++, so it also does to C, because there is no such thing as a C ABI, only OS ABIs that happen to be written in C, and the C compilers of the platform follow the OS ABI, which you can get in C++ with extern "C".
- Tozen 4y agoFrom what I've seen, any language using GC, gets less respect (overall) on HN. Kind of like, "Real men don't use GC." To include even if the GC is optional. But the kind of funny thing about that is the NSA is recommending various GC languages. Go figure.
- kajaktum 4y agoOh yes, the language that STILL have null pointer dereference is a good replacement for C in this day and age. Please. Go feels like a person stuck in the 80s idea of a modern programming language. Oh and the idiom of the language is to treat zero of a value the same as nil. Brilliant, now I have a to litter a bunch of checks that time.Time{} is not a valid time because???
- bugfix-66 4y agoSure: if you don't like C, you won't like Go. Sounds like C is not your thing, and that's ok.
- kajaktum 4y agoIt doesn’t matter if I like it or not my point is that it is not a C replacement. Unless you are talking about personal preference then sure. But I don’t think we as an industry should look to replace C with Go.
- bugfix-66 4y agoIf you don't appreciate, or don't understand, C-style pointers (they're just addresses, where nil is a very useful value) then you won't like C and you won't like Go. Go is an improved C. It's for people who like C but need C's well-understood problems fixed. C-style pointers are not a problem. They don't need to be fixed. They're great, and that's why Go retains them. Here is an example of C-style code making essential use of C-style pointers (especially nil pointers) but it's Go: https://bugfix-66.com/50788214f539d50382528e86242eb3c846b03faa6594ba98f457dfdd5de70e86 https://bugfix-66.com/50788214f539d50382528e86242eb3c846b03f... You need to be able to represent addresses, and you need to be able to say "address of nothing" (i.e., nil pointer).
- pyinstallwoes 4y agoOtherwise you have to assign it a value that represents nothing, right? So it’s basically how you want to represent nil/null?
- yazzku 4y ago> the language is (for many purposes) an excellent replacement for C. No, it's not. The runtime wouldn't even fit on many platforms. GC pauses are similarly not acceptable on soft/real-time systems, etc. Ada/Rust get closer to a replacement.
- greesil 4y agoJust don't generate garbage. You shouldn't be using malloc anyway you silly embedded programmer. Half joking, as a C/C++ programmer here.
- SAI_Peregrinus 4y agomalloc() isn't the issue, free() is. Allocate at init, never free, and you'll still have deterministic behavior and no heap fragmentation!* * Unless you run out of memory, of course. Then you have issues.
- tempodox 4y agomalloc() on an embedded platform can still present pitfalls. This article explains why: https://mcuoneclipse.com/2022/11/06/how-to-make-sure-no-dynamic-memory-is-used/ https://mcuoneclipse.com/2022/11/06/how-to-make-sure-no-dyna...
- SAI_Peregrinus 4y agoYes, you can still run out of memory. But you can't get a fragmented heap if you never free(). And if you allocate only at init, not during the normal operation stage, you can't run out of memory if you manage to start up successfully.
- pjmlp 4y agoThat is a matter of tooling. There are bare metal Go runtimes being shipped in products today, e.g. TamaGo unikernel for firmware. As there are real time Java implementations, there could exist Go ones if the market cared about having them as well.
- pjmlp 4y agoWe could already afford safety coding for 80286 using Turbo Pascal, Turbo Basic, Quick Pascal, Quick Basic, Modula-2, Clipper. Performance stuff was written with inline Assembly, or straight Assembly with nice macro assemblers (TASM, MASM), using C or C++ in detriment of the above selection only helped bringing UNIX stuff into MS-DOS. EDIT: See books like "PC Intern: System Programming : The Encyclopedia of DOS Programming Know How". EDIT2: It is available at archive.org, https://archive.org/details/pcinternsystempr0000tisc/mode/2up https://archive.org/details/pcinternsystempr0000tisc/mode/2u...
- praptak 4y agoPascal was(is?) not memory safe in that it still allows use after free. It was safer than C though thanks to making it more difficult to do weird casts or pointer arithmetic. These were normal in C code, in Pascal rather something you go out of your way to do. Also I think the arrays had bounds checking?
- pjmlp 4y agoThat is the usual excuse to keep writing C code, because alternatives aren't 100% bullet proof, we just keep using the unsafe one. Yes, it suffers from use-after-free, lets ignore everything else that is safer than C. Bounds checking are enabled by default and if one wants to shoot themselves on the foot there is always {$R-}.
- rowanG077 4y agoI think Ken Thompson gets little respect precisely because he designed Go. It's a large stain on his legacy that has single handedly set back the field of Software Development. I think that if Go didn't exist he would be considered "one of the greats".
- kramerger 4y agoBeg to differ. Go is an extremely well designed and balanced language, it is extremely productive while still being easy to maintain and have pretty decent performance.
- rowanG077 4y agoGo is opinionated for sure. And many people think it's the wrong type of direction. Not everyone thinks this, as the poster I replied to likes go. And you do as well. I think that he isn't as respected as other names is because there is a substantial group that feels Go is a step backwards.
- pclmulqdq 4y agoI think go would have gotten a lot more love from C and C++ users if they weren't so resistant to having an optimizing compiler. I'm not referring to removing bounds checks - I'm referring to things like stack-passed function arguments and the normal optimization passes that you get from -O2 in gcc. Sometimes you want a slow compiler that does a lot of heavy lifting. Now, Rust is the new hotness and it doesn't make a lot of sense to use other things if you care about both safety and speed.
- bugfix-66 4y agoWell, to begin with, Go passes function arguments in registers since 1.17 Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. Benchmarks for a representative set of Go packages and programs show performance improvements of about 5%, and a typical reduction in binary size of about 2%. (https://go.dev/doc/go1.17 https://go.dev/doc/go1.17) I think the basic problem here is that you don't know the facts.
- pclmulqdq 4y agoI think you misunderstand my point: The problem is that it took until around 2020 for this work to start. Around 2015, a lot of would-be adopters from C and C++ didn't jump on the Go bandwagon because of the perf gap. I use Go a lot today, as a former user of both C and C++, but Rust is probably better as a C/C++ replacement.
- zozbot234 4y agoNote that Go is not memory safe for concurrent programs. Memory safety is ensured for sequential code only.
- pjmlp 4y agoNeither is Rust if the memory segment is accessed via OS IPC instead of threads in the same program, there is nothing that Sync and Send can do to help there. This is a quite common memory access pattern in HPC.
- tialaramex 4y agoDo you have some examples of this "common memory access pattern in HPC" ?
- pjmlp 4y agoSure, here goes one example, "A Case Study and Characterization of a Many-socket, Multi-tier NUMA HPC Platform" https://ieeexplore.ieee.org/document/9306956 https://ieeexplore.ieee.org/document/9306956 Or for something with FPGAs and other cool stuff in-between, "The ATLAS Data Acquisition and High Level Trigger system" https://iopscience.iop.org/article/10.1088/1748-0221/11/06/P06008/pdf https://iopscience.iop.org/article/10.1088/1748-0221/11/06/P...
- eternityforest 4y agoI say we jump straight to Rust. Rust goes farther in terms of stopping bugs even beyond memory safety issues.