5 ms·
How is it a "better C" as compared to Go? Genuinely asking.
by knighthack 2y ago
How is it a "better C" as compared to Go? Genuinely asking.
- Bilal_io 2y agoGo is a garbage collected language
- kstrauser 2y agoGo is garbage collected. That's a non-starter for a lot of C use cases.
- adrusi 2y agoGo 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.
- ilrwbwrkhv 2y agoGo 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 https://go.dev/play/p/izcod8xF7ZQ
- koeng 2y agoThat’s not true. Here is a go playground of pretty much that exact code running just fine https://go.dev/play/p/v7OM9s_pRqY https://go.dev/play/p/v7OM9s_pRqY
- deathanatos 2y agoSteelman 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.
- iknowstuff 2y agoWtf? what are you doing? Did the point fly over your head, are you being malicious by removing the star, or?
- koeng 2y agoThey added the star as an edit because of my playground link. So, neither
- matrix87 2y agoCould 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
- ilrwbwrkhv 2y ago> 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".
- archgoon 2y agoI 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.
- burnished 2y agoThat 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.
- deleted 2y ago[deleted]
- ilrwbwrkhv 2y ago> 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 }
- burnished 2y agoI 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).
- 2y ago
- cletus 2y agoLet 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.
- Capricorn2481 2y agoPython 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.
- nkozyra 2y ago> 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.
- orwin 2y agoI 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.
- mikemitchelldev 2y agoDelve is a great debugger for the Go.