4 ms·
As much as I've cursed the lack of generics and the limited expressiveness of Go's type system, it's hard for me to reconcile these proposals with what I know o
by hackyhacky 6y ago
As much as I've cursed the lack of generics and the limited expressiveness of Go's type system, it's hard for me to reconcile these proposals with what I know of Go. Go was conceived as a small language, a successor to C, and purposely eschewed "new-fangled" features of modern languages. Whether the result is good is a matter of taste, but I feel that retroactively bolting on a modern type system will simultaneously (a) undercut the simplicity of the core language and (b) produce a language that is not as clean as those conceived with generics from the beginning.
- dgb23 6y agoOne could argue that parametric polymorphism is a form of simplicity, because it disentangles algorithms from concrete types.
- kitkat_new 6y agoThe lack of generics makes it only more complex. Simplicity: yes, but in a senseful manner. Omitting generics is not senseful to me.
- hackyhacky 6y agoI agree. But if you like generics, why not use a language that already has them, e.g. Rust, Haskell, etc.
- mrnothing_123 6y agomaybe you already use go-lang, and want generics.
- DaiPlusPlus 6y agoAny successor to C needs to be type-safe. Generics make that easier.
- hackyhacky 6y agoWhy? C isn't type-safe.
- DaiPlusPlus 6y agoC doesn’t lack safety by-design - it’s hobbled by its history and constraints imposed by its userbase - otherwise C would have major breaking changes more often.
- hackyhacky 6y agoC absolutely lacks type-safety by design. Otherwise what would malloc return, besides void*? How would you implement generic containers in C, without using macros or void*? Edit: formatting
- DaiPlusPlus 6y ago* malloc would accept a typename argument T and return T* * calloc would a;so accept a typename T and count and return T[count]* * Generic containers could be implemented as something closer to C++ templates (or preprocessor macros on steroids, like T4, as you suggest).
- hackyhacky 6y agoThere is no typename in C.
- a1369209993 6y ago> Otherwise what would malloc return, besides void* IIRC, historically void* didn't exist, and it used char*. It added void as a unit type, and absent historical baggage could add... let's call it "noreturn" as a bottom type: #define NULL ((noreturn*)0) noreturn* malloc(size_t); void free(void*); noreturn exit(int); // never returns int main() { // where (T)... is any expression of type T void x = (T)...; // throw away the value T y = (noreturn)...; // a nonterminating expression void* p = (T*)...; // pointers convertible *to* void* T* q = (noreturn*)...; // pointers convertible *from* noreturn* *(noreturn*)...; // notionally, this should always fault *(void*)...; // read zero bytes, so always fine }
- nine_k 6y agoA successor to C with mandatory garbage collection? Sorry, it's a wrong ballpark.
- throwaway894345 6y agoOnce upon a time, C was a general purpose programming language--it wasn't always exclusively performance critical systems programming. Anyway, in practice you can use arenas or other techniques to alleviate GC pressure. In my experience, the GC isn't a big performance issue; rather, the Go compiler doesn't optimize as aggressively as the C compiler.
- nine_k 6y agoUnless you need the precise memory and hardware control that C gives you, why lower your productivity by using such a low-level language?
- throwaway894345 6y agoBack in the day it was simply the best option available. Java and Python only came out in the mid-90s and would take some time to catch on, develop a useful ecosystem, etc. And if you wanted to interact with system APIs, everything was in C. Nowadays there are much better options for a huge swath of applications. I would argue that--every bit as important as the language issues itself--one of the biggest reasons to avoid C is that all of its popular build system options are terrible. You're just expected to have the right dependencies installed on your system at the right versions and in the right locations (okay, some tools will try and find the location for various dependencies, but this is a pretty poor substitute for proper dependency management). And that's merely scratching the surface of the issues with C/C++ build tooling.
- esarbe 6y agoI don't think that Go ever was a very good successor to C. Go might have been conceived as a systems language, but simply because of the GC it can never ever fill that niche. Go is a perfectly fine middleware language, but no C replacement. (Rust does much better in that regard).