Hacker News Reader

Comment by cletus | Hacker News Reader

I have no issue with the author's points but I just don't see these two as solving the same problem.

Zig, to me, is a better C (as the author notes). It seems like it's designed so you can combine easily with a C code base and incrementally migrate it. That's a great application. I'm not expert enough to speak on the merits of comptime (which the author talks about). But isn't comptime somewhat equivalent to constexpr and similar compile-time constructs?

Rust, to me, fills a niche as a better C++. Macros are better templates. Compile-time ownership checking is better than a C++ runtime smart pointer. There is legacy in C++ that you can never escape eg someone just calling .get() on your smart pointer and doing God knows what with it.

Rust treats memory safety as being of paramount importance and aims to do that with zero runtime cost. That's a great goal but it's also fundamentally different to Zig's goals.

View on HN

I'm not sure Rust is in the same space as C++, so I'm not sure I'd call it a better C++.

I use C++ because I want performance without all the accounting operations that have to happen in C. I try to write my code in a safe way, but language safety just isn't a priority for me. I guess that's why I'm not using Rust. Fighting the borrow checker doesn't seem worth it to me to gain something that's just not that much of a priority. But I'm not writing an OS or a server.

I'd think of Rust more like a better Ada or some language where safety is first priority

Story time: Chrome is a Frankenstein of C and C++ code (both directly and through called libraries, static or dynamic). Now C++ has `std::string` obviously. C of course has `const char *`. To facilitate interoperability C++ has various methods to implicitly or explicitly convert between the two.

At one point it was found these every keypress on the OmniBar resulted in 25,000 string copies.

So my point is that you can write C++ as carefully as you can but on any sufficiently complex code base you'll going to need a pointer to something and then you've really lost all control and safety so the safety in C++ is a bit of an illusion.

Well, that's horrifying. Presumably the value is being copied whenever it is converted from a const char * to a std::string?

The right thing (TM) would probably be to refactor some of the std::string's into std::string_view's, for instance by adding overloads where it makes sense. I doubt you could avoid all the copies, but I think you could cut it down substantially if you collected metrics and focused on the most egregious cases.

Of course, I do not envy the person who is tasked with doing that, and I could be wrong for any number of arcane technical reasons.

I can only imagine that using std::string_view in a massive, complex application would be horrifying.

The borrow checker is one of the benefits of Rust in that case, simply because you can avoid copies while actually being able to trust that you're not opening the door to security & maintenance hell in the process.

a lot of the copies might be bits of code defensively copying the string because they don't want to deal with working out lifetime safety.

Fun fact: this happened during the standardization of std::string_view, which ended up landing in C++17, a few years after this was fixed. Not that there weren't non-standard versions that existed.

In the end they did a number of things to fix this, the patches are linked in the story I linked above.

std::string_view has seemed, to this relative outsider, to be semi-controversial. It makes it pretty easy to introduce use after frees, that it's not null terminated can be easy to forget, and isn't bounds checked. So while it helps with some issues, it can create others, meaning it's not always a clear win.

HN thread on this story: https://news.ycombinator.com/item?id=8704318

Fair but I never said it was safe, just that perfect safety isnt of interest to me

I don't really see the distinction you're making. C++ will still be around for legacy projects that don't want to switch, but I can't think of a new project that would benefit from picking C++ over Rust, apart from needing to integrate with the C++ ecosystem beyond what bindgen offers.

You get to write code that's just as or more performant, and you get to jettison the decades of bad language design that is C++, which is win/win to me.

The pool of C++ engineers is much bigger, and like it or not its a very proven solution. Rust still seems to have a lot of areas where its immature (gui toolkits for example)

Maybe because Rust is not a language made to make GUI applications? For GUI applications you are better of with a higher level language.

Don't you think that's a weird limitation though? Nobody says C++ isn't a language made to make GUI applications. If you're going to replace C++ you should probably be able to do the same things at least as well.

It's not actually a limitation, the ecosystem is just young:

https://github.com/iced-rs/iced

My general point though is that there's still some ecosystem/legacy reasons to stick with C++, but Rust very much fills the same niches as C++.

It's not "language safety", it's memory safety. You're saying that memory safety isn't a priority?

When you run Coverity or other static analyzer on your code, how many violations do you find? How many were unexpected?

The borrow checker is always being run - the difference is whether its in the compiler (Rust) or you in your head (C++). And I trust the compiler much more than I trust myself...

For what I use C++ for (game development and embedded systems), smart pointers are "good enough". Especially single player games, worst you run into is a crash, or my arduino code writes past a buffer.

I see Rust as neither a C nor C++ replacement, it feels more like a much less limited version of Java. Zig, on the other hand, feels more like a highly evolved C.

As a pretty hardcore systems programmer, there are three things that modern C++ has first-class support for that are difficult to live without: metaprogramming, handling cases where ownership is unknowable at compile-time, handling cases where lifetimes are unknowable at compile-time. Rust is still significantly more limited than C++ in what it can express effectively. There are very few features in C++ that are not critical and routinely used in some application domain.

A low-key strength of C++ is that it is not overfitted to any particular assumptions about application domain. This adds complexity (aside from complexity introduced by legacy and age) but with the benefit that there is a subset of C++ that is highly specialized for the requirements of almost any application domain.

Well said. Though it'd be sorta neat IMO if we could use just one language here, and the memory unsafe aspect could somehow be toggled off or on, gaining all the pros or cons of Zig vs Rust as needed.

Are you thinking of something different than Rust's `unsafe`?

What you're talking about here is disabling runtime assertions, which is a common practice in C/C++ (using #define macros). Runtime assertions are strictly inferior to Rust's compile-time assertions because Rust allows you to do a subset of what you can do in C/C++ but it verifies that the memory ownership is correct without a runtime cost, unsafe code notwithstanding).

There simply is no way you could do that in C/C++ (and, by extension, Zig) because of the legacy support.

I'm fine with having multiple languages. One language to rule them all just tends to mean something is mediocre at everything.

How is it a "better C" as compared to Go? Genuinely asking.

Go is a garbage collected language

Go is garbage collected. That's a non-starter for a lot of C use cases.

Go would be amazing if it didn't allow dumb mistakes such as:

    type Human struct {
        Name string
        MaybeHasCat *Cat
    }

    type Cat struct {
        Name string
    }

    func main() {
        h := Human{}
        h.MaybeHasCat.Name = "Taffy" 
    }

And boom. Null pointer exception because MaybeHasCat is null. The fact that go doesn't let you define an optional type is such a pain. A lot of newcomers while getting trained up fall for this bug.

edit: updating to add the pointer i missed. also adding a playground link: https://go.dev/play/p/izcod8xF7ZQ

That’s not true. Here is a go playground of pretty much that exact code running just fine

https://go.dev/play/p/v7OM9s_pRqY

Steelman their example. Given that they named the member "MaybeHasCat", it's pretty clearly meant to analogue an Option<Cat>; if you correct the small typo then (make the type of "MaybeHasCat" a pointer, so that it can store nil for the other half of the Maybe), the example behaves exactly as they describe.

Wtf? what are you doing? Did the point fly over your head, are you being malicious by removing the star, or?

They added the star as an edit because of my playground link. So, neither

Could just do null -> none, nonnull -> some, optional doesn't introduce anything new here. Either you null check or you optional check

Optionals are just another outlet for "best practice" bullshittery and not much else. If go doesn't have, sounds like they're following YAGNI principle

> Could just do null -> none, nonnull -> some, optional doesn't introduce anything new here. Either you null check or you optional check

I am not sure what you mean by the first point but what I am saying is that the compiler doesn't stop you from having a basic runtime null pointer exception because of "simplicity" and "yagni".

I think you meant

  type Human struct {
     Name string
     MaybeHasCat *Cat
  }

As you have written (not making MaybeHasCat a pointer), go will correctly initialize (at least as of go1.20.5) the nested Cat structure and allow for direct assignment.

Having a null pointer exception for a null pointer is a behavior I would expect. Having one for a non-pointer structure would be surprising.

That would work. It would need to be a pointer to get a nil pointer exception, or an interface (obv function call to trigger instead of field access), but there are some simple and common patterns you would follow to prevent that.

Edit: should do more than just suggest the fix is easy

So for pointer types you have two options IMO: nil checks, or getters that do the nil check for you.

I think a map type instead of a string would also make your point more strongly because your zero value will fail on access. Which yeah that sucks to run into, and I'd agree actually that a lot of Go painpoints pop up early. I appreciate that now, because most of my foe stubbing was done inside the first few weeks, but it is undeniable imo.

> nil checks, or getters that do the nil check for you

Yes I agree there are patterns to solve for this but it is just strange that the compiler doesn't stop you from making these errors. I mean even Typescript has:

  interface Human {
    name: string
    cat?: Cat
  }

I don't know what 'even typescript' is supposed to mean. Are you saying that typescript is the natural bar for comparison here? That doesn't seem correct, isn't typescript a project that tries to correct javascript's lack of typing?

Since it isn't an error to have a nillable type, and it isn't an error to access a field, it makes sense that the compiler doesn't error when you do that thing. If you want a warning when doing something silly then you can setup a linter.

If your first thought is that is not very beginner friendly then I agree with you - I edited my original response. But otherwise there are solutions to these problems.

If that doesn't suit you and Go isn't sweet enough for you, well, fair. Its rather austere. I don't think it is a categorical error for the project (though there are features I would also like for asking).

My point is nillable values by default is a strange choice and throws out 50 years of computing history. It has been clearly established that it leads to null pointer exceptions. The fact that a modern language lets you do it is a bit strange.

Oh I didn't really get that from what you had been saying.

Sure, I'd agree it feels like a whoopsie, I dislike nil values because they are a common source of faults.

Go has a heavy runtime, including both a garbage collector and a userland scheduler. Those features both make it inappropriate for some applications where you would use c, and also make calling (and especially being called from) foreign code problematic. You effectively cant implement a library in go and then call it from another language, not without considerable ffi overhead at the very least.

Let me preface this by saying I like Go. I do. But as much respect as I have for Rob Pike (which, again, I do), he doesn't understand the systems programming space. Go was originally pitched as a systems programming language, a better C, like you said.

But it isn't. It is, however, a better Python (IMHO).

The reason it's not a better C is that it's a garbage-collected language and it has a runtime overhead. As such, Go doesn't really have predcitable performance. It's easy to blow up memory usage (as it is on any GC language) eg goroutines.

So Go just doesn't suit a typical systems or embedded application. Yes, you can use a subset of Go to avoid dynamic allocation and GC in general but really, what's the point in that?

Why it's a better Python (again, IMHO) is that Python has all the same negatives but has a few more, most notably that it is dynamically typed or, as I like to put it, you need to write unit tests for spelling mistakes. I've come to abhor dynamic typing as a truly horrendous false economy. Go doesn't have that problem. Go does need to be compiled but it's a simple language and that compilation is incredibly fast.

My one criticism is that I find Go's unbuffed channels to be a less elegant coordination mechanism to cooperative async/await in other langauges. But YMMV.

Some evidence to back this up is that, at least while I was still at Google, Go projects on google3 were cannibzlizing Python projects and nothing else really.

Python also has some positives that Go doesn't have, like iterators without the community freaking out about them. It's obviously way more ergonomic to use Python, and if you want types, Pyright works very well.

My issue with Go is that it's not low level enough to be good for systems programming but it's not high level enough to avoid boilerplate.

> My issue with Go is that it's not low level enough to be good for systems programming but it's not high level enough to avoid boilerplate.

That's really interesting because in general I find Go faster to work in than Python. Python has great flexibility but even production code I read is littered with noise that I don't see with Go applications. Other than error propagation - which is more a style choice than boilerplate - I find doing something in Go results in fewer lines of code and less spaghetti logic.

I'm a bit too dug in on Rust to spend a ton of time replacing it with Zig and my use cases frankly could be handled by a Go app without much worry about performance. But one thing Rust has is boilerplate out the wazoo.

I have heard this anecdote a few times but I don't understand it. Even ignoring error handling in Go, I feel like everything is noticeably more verbose and noisy than something like Python. A language that prioritizes readability is intriguing to me, but I just haven't experienced that with Go.

Not that I haven't seen messy Python code (I sure have). The best Go code is gonna look better than the worst Python. But on average, it seems like complicated flows can be written very elegantly and readably in Python and look ugly in Go.

Go isn't pretty to look at, but I feel so much more confident in a successful Go build than starting up Python–not knowing when exceptions will throw or crash until it's run is frustrating.

I'm sure Rust folks feel exponentially more safety than Go at compile time, but the jump from Python to Go is dramatic for me.

As someone who used to write a lot of Ruby and now has started to write some Go, I feel like you nailed it.

Go is compiled language for people coming from dynamic languages. The type inference is good enough and the compilation types are also quite fast.

> Go was originally pitched as a systems programming language, a better C, like you said.

I've always understood this claim as a particular (rather restricted) interpretation of "systems" code - meaning network servers, basically (maybe also CLI applications?)

I'd always thought of "systems" as including things like writing standard libraries, kernels and embedded code. But I guess there is a decent slice of other systemsy stuff that Go is good for.

Whereas something like Zig feels like it could really be a better systems programming language in general that C, in all of its different application areas.

> I've always understood this claim as a particular (rather restricted) interpretation of "systems" code

This is basically the retcon that the golang community has settled on but it's frankly not true.

When go was originally being promoted it was heavily advertised as a systems language suitable for writing low-level programs. Nowhere was it caveated that "systems language" means something different from what everyone understood a "systems language" to be at the time. Only when it more or less failed to gain traction in that space did this get redefined to mean "network servers that mostly just shuffle bytes around and CLI applications".

I dubbed Go 'C+-' the first time I used it, and it was on a program that made heavy use of threading and used a producer-consumer workflow, so I don't think I could have used a better program to test it (and I think Go was the best language for my program).

It probably has changed since, it has been 10 years now, but my feelings were at first 'wow! This is easy' during the prototyping phase, then 'ugh, i'm so limited' during the finalization (and at random points in the middle too probably, but I was fanboying at the time so I didn't really notice). One of the worst thing is the debugger imho. I _get_ gdb. I haven't written a line of C in years, you put me in an interactive gdb, I'm home. Go, I didn't understand how to debug, I had to use my 1rst year technique of printing everywhere, except I never managed to make use of %p, so I was even less effective than that.

Delve is a great debugger for the Go.

Bear in mind this was 10 years ago hopefully Go have a debugger now, but still, it won't be gdb.

Go's debugger has worked just fine for years. What do you prefer about gdb (which also seems to support Go)?

Reply on news.ycombinator.com