Hacker News Reader

Comment by hackyhacky | Hacker News Reader

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.

View on HN

One could argue that parametric polymorphism is a form of simplicity, because it disentangles algorithms from concrete types.

I 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).

Any successor to C needs to be type-safe. Generics make that easier.

Why? C isn't type-safe.

C 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.

C 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

* 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).

There is no typename in C.

> 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
    }

And that's (part of) why C needs to go.

Sure. But why not replace it with something that is type-safe AND already has generics, like Rust? Why are we trying to get a do-over on Go?

At this point it’s history: Go and Rust both got started around the same time - one by Mozilla and the other by Google. They’ve both reached critical-mass over the past ~10 years - so expecting one of them to disappear is like expecting Autodesk to choose between 3ds and Maya...

Rust and Go both aim to create safe, performant, modern languages suitable for use from the systems layer up, differing in some of their primary goals:

Rust is a sane C++: Zero-overhead abstractions, not afraid of language complexity.

Go is a modern C: Simplicity, stability.

They have some overlap in what they're best at, but they both take on unique and important missions that both need to be targeted, in our rapidly expanding universe of software engineering.

(edit: formatting)

I think that's the point, the argument is that a "new" language needs (at least) type safety to successfully dethrone C

The lack of generics makes it only more complex.

Simplicity: yes, but in a senseful manner. Omitting generics is not senseful to me.

I agree. But if you like generics, why not use a language that already has them, e.g. Rust, Haskell, etc.

maybe you already use go-lang, and want generics.

A successor to C with mandatory garbage collection? Sorry, it's a wrong ballpark.

Once 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.

Unless you need the precise memory and hardware control that C gives you, why lower your productivity by using such a low-level language?

Back 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.

Reply on news.ycombinator.com