Hacker News Reader

Comment by bigato | Hacker News Reader

Yeah, there is. It is called Go.

Well, while my answer is not meant to be serious, Go started as "C with some improvements", and the three person team who first wrote it had among them Ken Thompson, one of the first users of C. Because it is garbage collected, it mostly abstracts away the memory allocation from the programmer. There's penalty in performance, though. It's a trade-off that allows the programmer to not think much about it. Go favors simplicity over speed while Rust tries to have speed as a main goal, and sometimes the tradeoff is more complexity.

View on HN

Go is not "memory safe C".

Go has garbage collector and that is not zero cost.

Rust has zero cost abstractions, so Rust is sort-of "memory safe C".

However, Rust is notoriously hard to learn, read and write in. So that sort of shows you that desugning low-level, zero-cost language is HARD

The OP didn't ask for zero cost abstractions. Furthermore, maybe "zero-cost" is not the best way to describe Rust abstraction; they may be zero cost for the machine at runtime, in exchange for a bigger mental burden on the programmer, thus being better labeled as a trade-off in more speed in exchange for more complexity. Whether this trade-off is worth it, will depend on some factors like the use case and the programmers involved. And the OP was actually complaining about the added complexity, thus my answer being Go.

> Furthermore, maybe "zero-cost" is not the best way to describe Rust abstraction
"Zero-cost" has always been about runtime cost. Other costs are not part of the slogan. Everything always has a cost!

And notably, Rust didn't start the "zero-cost abstraction" meme, C++ did.

Yup!

> bigger mental burden on the programmer
Only sometimes. For complex enough problems I think mental burden of writing and maintaining software in less complex language will become more burdensome than the intrinsic burden that comes with more complex language.

> Rust is notoriously hard to … read
I've seen this argument a number of times before, but always discarded it as something that only people not familiar with post-1.0 syntax could bring (cause all those ~@[Omg]s really were hard to read). Do people really still struggle with its syntax, and if so, why?
Coincidentally I personally really seem to struggle with reading sources in Go, although I'm yet to figure out why exactly it is the case and why I'm not as slow when reading sources in e.g. Perl.

Really? Because I find
let x = ~"blah";
to be more readable than
let x = String::from("blah");

Rust zealots: please read your documentation about unsafe memory. And while you are there also about deadlocks.
The best safe C derivate is D, but there are also some minor offsprings, like safe-C or mscc or the popular cfi option, the Intel bounds-checking library or safeclib. Most C compilers let you track the buffer bounds nowadays, but rarely someone uses it.

> It is called Go.
I'd argue it's called D. Go and C are two quite different languages. Whereas if you've been coding in C you can easily switch to D and benefit from safer constructs instantly, almost without feeling a difference.

I don't know much about D to know whether this is true, but you definitely can switch easily from C to Go.

Can you use existing C binary libraries directly from Go?

Yes, you can https://golang.org/cmd/cgo/

Seems a bit more convoluted than in D.

Go will never be nearly as ubiquitous as C. It's plug-ins API is terrible. Rust users definitely don't want a GC language to replace C.

I didn't say it will, nor did OP say that he wanted the alternative to be as ubiquitous as C.
When you refer to Go plug-ins API, do you mean this[1]? Because I wrote a fair amount of Go and wasn't even aware of this package. And while I don't know whether it is terrible or not, I'm pretty sure this package in particular is not relevant for most Go applications. So maybe you meant something else?
I didn't say Rust users want a GC language to replace C, I don't know where this is coming from.
[1] https://golang.org/pkg/plugin/

Suggesting another language implies that language is essentially just a variant of C and can be used in any situation as C. The OP was asking why there is no (mainstream?) variant of C with built-in memory safety. Suggesting Go implies Go is a direct replacement for C in most cases, which it is not.
Regarding plugins, yes that is the package I am referring to. The idea of dynamic loading is completely ignored in the Go programming language but it is used in many, many other languages (i.e. Java, Python, Lua). Go's support for this feature is lacking and should be fixed for it to interact with other languages.

Reply on news.ycombinator.com