8 ms·

Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection G

Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.) Go puts essential C idioms directly into the language (pointer/length is formalized as slices, packages are part of the language instead of just being naming convention, etc.) Go is mature, stable, widely-used, well-supported, and well-understood. C++ is a clumsy mess, but C is quite elegant and Go is a continuation/modernization/enhancement of that If you like C, you will love Go

Lariscus 6y ago
I like C but strongly dislike Go. They share nothing other than having a small(ish) feature set.
- BoorishBears 6y ago
  I agree. Go feels like it's aimed at creating applications that run at a level above where C traditionally runs while keeping the pared down feature set of C, and it just doesn't work well imo. I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names. It's like the simplicity gets in the way of itself. - My take is, use Go for a bit, take the "less is more" mentality with you to a language more suited for real work. ps: I'm not saying you can't use Go for real work before someone flies at me. I'm just saying that Go's strength is the mentality people have when using it, as a language it's not particularly enabling, and that's by design if anything...
  - bak3y 6y ago
    Meanwhile the place I work writes all microservices in go and all of my team's (DevOps) tools are also written in go...
    - BoorishBears 6y ago
      I explicitly added the "ps" to avoid the situation where all the replies are fairly empty comment saying "Well we use it!" I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages. That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional effort it took to deal with what was missing There's an implicit ymmv here of course, because I'm not saying no one can find Go useful, I can see how in certain worlds with certain teams with certain priorities it'd all work out. It's just not for me.
      - murukesh_s 6y ago
        I have used Go in production. I found it roughly takes 2-3x additional time it takes to develop the same functionality in Node.js (with typescript). But it runs faster. If you want to write code that is probably not going to be thrown away it may be wise to invest the additional time in Go. However can't recommend that for building experimental code/APIs etc which are time bound and may/can get replaced (or split into micro services) in future if it becomes massively successful..
        AlchemistCamp 6y ago
        And that's saying something give that neither Node nor TypeScript have ever had productivity as a main selling point! Imagine evaluating the time to market for an experimental back-end written in Rails, Laravel, Phoenix, etc vs Go! The difference is staggering.
        konart 6y ago
        >Rails, Laravel, Phoenix, etc vs Go! Comparing frameworks and a language, really?
        AlchemistCamp 6y ago
        Absolutely! There are obvious productivity differences between the languages themselves and frameworks can make it even more apparent. Different languages make writing the DSLs used in Rails-like frameworks easy, difficult or impossible. Much of my professional career was spent working on Node back-ends with a variety of frameworks and none of them were even close in terms of succinctness or productivity.
  - Thaxll 6y ago
    The last couple of years are showing that Go delivers, it's pretty easy to find dozen of "real" software written in Go that are weidly used.
    - BoorishBears 6y ago
      Sometimes I don't know why I bother talking about Go. It's proponents are so quick to go defensive that no one is capable of reading any complaint in an even mildly charitable light. I mean I shouldn't literally have to say "I'm not saying you can't use Go for real work before someone flies at me." When talking about a language as widely used as Go right? Like that's common sense! And yet of course I'm getting replies that do exactly that because of how darn defensive people need to be about it.
      - Thaxll 6y ago
        Maybe don't use things like " to a language more suited for real work."
        BoorishBears 6y ago
        There is a literal full paragraph dedicated to explaining it, maybe don't ignore the oodles of context I left to avoid exactly what you did. Saying other languages are more suited to real work doesn't mean Go isn't suited at all, it literally means other languages are more angled towards the "end product" or the "real meat and potatoes" of just making a thing work than Go. It's literally a strength of Go. Go doesn't want to include the kitchen sink or even confine you to having a kitchen at all and I respect that. But I'm saying that other languages that include more in the way of affordances can help one be more productive, and I believe combining a language that includes more, with the mindset of not abusing the buffet is a winning combination. Ymmv, I'm not an oracle, I just expect people to read things in a reasonably charitable way which usually works fine as long as they're not being defensive.
  - steve_adams_86 6y ago
    I agree about becoming okay with bad code. But I think if you understand and embrace that, there’s a place for it and it can be quite powerful and easy to use at times. It’s a trade off that makes sense sometimes. I think the problem appears when people treat Go like it doesn’t have any problems. All languages do. As I’ve mentioned recently though, I don’t think I’d ever want to use Go as a forever solution to a complex problem. I’m sure some people could do it and do a great job, but I’m not one of those people. I need the ability to abstract and ensure more safety, or I’ll never feel secure with what I’m building.
  - blablabla123 6y ago
    > I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names. Not well or hastily written Go is easily like that. I can only guess why you point out the repetition but when you look at well written Go code like in the Go std library, there isn't much repetition happening and it looks rather elegant. At the same time it can be quite some effort to create such code and might take several iterations. Documentation-wise I like the official documentation, it gives a lot of pointers why Go is how it is. Also obviously it's not for every use-case. Where it works really well IMHO is where error handling is a vital part of the application. (And of course anything concurrent is quite a breeze)
    - BoorishBears 6y ago
      Not having generics, by definition, invites a lot of repetition and boiler plate. I know generics are overrated and coming soon, but right off the bat that stuck out. I recall a point where I had written a function that needed to return a channel, but of course had to forgo types due to the lack of generics. The end result was having to wrap that channel in another channel that added typing at each call site. I asked around in go circles if that made sense, and called out how bad the felt but the answer was "no that's great! channels are cheap! the repetition is good because it's simple!" - The error handling has some sore points to that end too, and the implicit shadowing with shorthand assignments on one hand makes it easier to deal with multiple errors, but on the other hand introduced subtle logic bugs on one than more occasion where "err" was silently shadowed, which I greatly disliked. I'm actually suprised Go didn't forgo shadowing for the shorthand operator and force people to label their errors when dealing with multiple, it seems very "in brand", but I guess even Go draws the line somewhere lol - Then there's the whole stack trace situation. Which after plenty of reading still just wasn't making sense. I mean the idea of logging a stack of wrapped messages sounds very nice, but man proper stack traces not being the first class citizen of error handling just did not make sense to me in a language I hear referenced for systems work so much (and I realize they can be had) I saw proposals to rework Go's error handling, I don't know if any progress has been made to that end, but it's another example where simplicity can get in the way of itself - And I'll balance this all out by saying it was still fun to write, I don't want to seem like I'm just shitting on Go for existing. It's just these little warts that I kept getting over with just a little bit of "idiomatic Go" which I often found was just writing a little bit more code than you're used to, started to add up. And eventually I realized I was creating something that, while very easy to reason about, had a lot more to reason about than it needed to. That's where I kind of petered out in my personal usage.
  - skrtskrt 6y ago
    I will take sometimes-tedious boilerplate over many-many-layered abstractions. You can write any language any which way, but some languages just have a culture of boilerplate vs abstractions. The most popular Python and Java libraries seem to love endless layers of indirection, and when it doesn't fit exactly what you need, you bang your head against the wall monkeypatching it to make it work since your whole app is already written in X mega library. Go culture seems to be quite a bit more boilerplate-y and uses smaller more composable libraries. It's just refreshing. Really I just need to buckle down on Rust, but I think it's a fair bet that teams and shops that bring in a lot of young programmers and want to ramp them up fast may cringe a bit at the learning curve of Rust. That's why for now in terms of a bet on employability, I am prioritizing experience with Go.
- 37ef_ced3 6y ago
  Take Go's slices, for example Realize a Go []int ("slice of int") is just a C struct like this, passed by value: struct intSlice { int* addr; int len; int cap; }; The memory at addr is not owned by the slice. All the slice operations are simply notation for manipulating the struct. Go's garbage collection makes the whole thing work well This can be confusing if you're used to C++'s std::vector (which owns the memory) or Python's slices. Go's slices are a shallow pointer/length system exactly like is used in C all the time. For example: void sort(int* addr, int len); becomes func sort(a []int) A Go slice is just a formalization of C's pointer/length idiom, with terse notation for manipulation
  - traes 6y ago
    I'm not really sure saying that features in Go can be modeled in C really suggests that they are similar as languages. Syntax is very important.
  - nyanpasu64 6y ago
    Go's slices don't act like what I thought were called "non-owning references"(Rust's &/&mut [T] or C++'s std::span<T/T const>), which reference memory whose lifetime is bounded by something else (like a vector or array or shared pointer). Instead it's "shared ownership" where memory is referenced by one or more slices (and no single owner) which can reference and mutate the slice simultaneously, and it's freed by the GC sometime after all the slices are gone. This reminds me of Numpy's ndarrays, which act more like "owning containers" (which may sometimes share ownership and alias) than "non-owning references".
    - erik_seaberg 6y ago
      Slices are kind of a mess. They should either be uniqueness types or passed by reference (the way maps and channels are, and NIO buffers from Java). Instead they’re passed by value so multiple copies exist whose sizes and sometimes contents aren’t in sync.
  - mhh__ 6y ago
    Slices should be the absolute bare minimum for a modern systems language, it's not really a reason to switch in my case If I want to write flat/simple code I'll just C, Go doesn't really offer anything to me because I want to be relatively low-level and able to make the compiler save my time.
alpaca128 6y ago
I'm not a C fan but isn't Zig much closer to C's philosophy while fixing bad parts than Go? Especially due to the garbage collection, at which point Go suddenly competes with many more simple languages.
- jerf 6y ago
  It depends on your definition of "C's philosophy", no sarcasm, and no implied preference by me for any particular definition, as I believe many have merit. Language philosophies evolve, and C, being so many decades old, has evolved a lot. The original philosophy is probably little more than a seed crystal at this point for the several philosophies that have been loaded on to it over the years. It is probably reasonable to say that Zig is closer to C's current philosophy in practice, which encompasses many additional developments over the decades to deal with various aspects of C and programming real machines that have arisen as both have changes, and Go closer to C's original philosophy of simplicity and relative ease of use. (In modern times, C is not one of the easier languages to use any more, due to significant advancements in the field of making easy-to-use languages. But it was originally intended to be an advancement there itself.) By similar logic, I can say with a straight face that all of Go, C++, Zig, Rust, and Swift (and more) are "evolutions in general-purpose programming languages like C", despite their wild differences, because the world has gotten larger, and there is room for a lot of variations like that, each addressing different aspects of the newer, larger world.
Jnr 6y ago
If I would have to replace C with anything, I would choose Rust and not Go.
- simias 6y ago
  To me Rust is more like "C++ done right". It's massively bigger, more complicated and slower to compile than C. The C ABI is also the de-facto lingua franca for language interop, something that's not easily achievable with Rust or C++ (or Go, for that matter).
  - Jnr 6y ago
    Have you tried Rust? The ABI in Rust is doable: https://people.gnome.org/~federico/blog/rust-stable-abi.html https://people.gnome.org/~federico/blog/rust-stable-abi.html And it doesn't feel like C++ when writing it. The syntax and language features are nice and feel modern. It does require more attention because of what it compiles down to, but the compiler is there to help with it. I haven't been excited about any programming languages in years, but Rust has certainly taken my attention lately.
    - simias 6y ago
      I love Rust so dearly that I wish I could marry it, but I still feel that it's a massively more complicated language than C.
deleted 6y ago
[deleted]
cute_boi 6y ago
I like C but I would prefer Rust over Go. Go may be simple but I really hate using conventions like init(), comments working like syntax, captial letter means published etc.
- steve_adams_86 6y ago
  Do Go comments work like syntax? Do you mean that they need to be formatted a certain way like they’re language syntax?
  - grey-area 6y ago
    The Go authors have (ab)used comments to extend the language in experimental ways for code generation, build pragmas and recently file embedding. They’ve done this to avoid breaking the language stability guarantee, not sure if there were other reasons. I think it’s a mistake personally to create this sort of metalanguage in comments (now you have two problems!) but it’s easy to avoid using this most of the time as the uses are pretty esoteric.
    - skrtskrt 6y ago
      File embedding is a common enough use case (HTML templates, config files) that it really makes me cringe that it's being done with comments.
      - grey-area 6y ago
        I just keep my templates and config in separate files. There are good reasons to keep them separate anyway (allows config without recompile for example) and for the apps I work on distribution isn’t a problem. So I haven’t really had to use comments as code in 7-8 years of go. Perhaps it’ll become more common with the embed stuff. But then I don’t use struct tags either so I guess I’d prefer Go to be even simpler.
  - _ph_ 6y ago
    No, Go comments are just comments. They have been used though to add meta-information to special tools. So unless you use those tools and require to add the specific meta-information, you can treat comments as plain comments. Hiding certain meta-information, like exporting a function with a C-compatible signature when building a shared library is not a great way of doing things, but on the other side, it is a special usage which isn't part of the language itself, so not part of its syntax.
simias 6y ago
My main small day-to-day usability gripes with C are lack of type inference, lack of destructors and terrible ergonomics for error handling. Go solves two out of three, but it really dropped the ball hard on error handling which is very disappointing IMO. Things like generics and garbage collection involve some deep tradeoffs, so I get Go's take on them, even if I don't necessarily agree with it. On the other hand IMHO Go's crappy error handling boilerplate is not something I find acceptable in a modern programming language.
- enw 6y ago
  How would you design the error handling? Personally I'm glad Go has stayed out of exceptions (panics don't count), at scale it's so much easier to reason about flow.
  - bmn__ 6y ago
    Monadic error handling like in ML work-alikes, Rust etc. would be a good start. Adopt: • https://github.com/rebeccaskinner/gofpher https://github.com/rebeccaskinner/gofpher • https://speakerdeck.com/rebeccaskinner/monadic-error-handling-in-go https://speakerdeck.com/rebeccaskinner/monadic-error-handlin... I've been talking to the local Go user group. No one even knows about that concept. This continues a pattern of general ignorance/lack of looking beyond one's horizon I've noticed.
- steve_adams_86 6y ago
  The error handling feels deeply wrong to me too. I love the explicitness and how hard it is to ignore errors - all languages should make it so easy to expect and handle potential errors - but other features (or lack thereof) of the language make it so you can’t handle any of it in concise or sane ways. Code is plastered with the same boilerplate, everywhere, always. It makes up a significant mount of all Go code.
- autarch 6y ago
  I agree that the error handling is terrible, but I'm not sure how much better it could be without generics. For me, the gold standard in error handling is Rust, where the type system simply does not allow you to ignore errors. This means that the existence of error handling is checked at compile time. Of course, this doesn't mean your error handling is _good_, but I think that's beyond any language design to enforce. But the Rust system is entirely built around a generic Result type, where both the non-error result (an int, string, struct, etc.) _and_ the error type itself are both generic.
xscott 6y ago
> Go fixes C's well-understood flaws (declaration resembling use This seems to be a common belief, but since Go kept pointer syntax as prefix, you're still stuck needing parens in some unfortunate cases: https://blog.golang.org/declaration-syntax https://blog.golang.org/declaration-syntax (see the part about pointers near the bottom) As Rob Pike writes in that link, they could've fixed it and still had declaration resembling use if they had chosen a suffix operator for pointers. He notes that Pascal uses ^, but it seems like @ might be a better choice: int foo // an integer int foo@ // pointer to int int foo[10]@ // 10 pointers int foo@[10] // pointer to array int foo()[10]@ // function that returns an array of 10 pointers In my opinion, they almost fixed it and then punted. As such, it's just different, but not really better.
burnthrow 6y ago
I thought this sounded familiar https://news.ycombinator.com/item?id=25622389 https://news.ycombinator.com/item?id=25622389 https://news.ycombinator.com/item?id=25555457 https://news.ycombinator.com/item?id=25555457 https://news.ycombinator.com/item?id=25531118 https://news.ycombinator.com/item?id=25531118
- booleandilemma 6y ago
  So the account was created 34 days ago and he's posted that same message 4 times already.
dpryden 6y ago
I'd like to chime in and say that I also like C but really dislike Go. C is simple, to what today is nearly an absurd degree, but it at least integrates well with an enormous ecosystem of existing tooling and libraries. Go, by contrast, feels the need to re-invent every possible wheel, often with a seemingly intentional effort to be different just because. C ABIs are rock solid on every platform. Any language or tooling in the world can load functions from a C library. By contrast, try calling Go from another language. You will quickly give up and use network protocols or subprocesses instead. The converse is true too: on major platforms, the C library defines the operating system more than the kernel does. (I mean, in a Unix sytem, the entire libc is documented in the man pages. Documentation for writing C is literally built into the operating system.) By contrast, Go decides to avoid the standard platform ways of calling every operating system function, and instead implements syscalls directly into the kernel, basically just because Go hates interoperating with anything that's not Go. C is a good language not because it is a good language, but because it is a good ecosystem. Unix and C are closely intertwined. (Even Win32 and C are pretty closely intertwined!) I could imagine a Go-based Plan9-like system -- if that existed, and had decades of engineering behind it, I could see the argument being made that Go's ecosystem compares to C's. But while Go may aspire to that, it isn't anywhere near there yet. And when you start comparing Go with other languages on the basis of language features, I think Go fails laughably more often than not. (I'll give you "C++ is a clumsy mess", though.) But compare Go with Rust, with C#, with Haskell -- for that matter, compare Go with Java and I think Go is a less powerful, less useful language to write real code in. If I want a lightweight, quick-and-dirty program, I'll use Python. If I want to write a reusable library that gets plugged into other software, I'd go with C (or at least write the interop layer in C). If I want a high-performance server, these days I would probably go with Rust. If I want a pragmatic, well-rounded language to write a large project in, I think C# would probably be my first choice. What space does that leave for Go? Outside of microservices (where I contend that Rust is a much better choice, and there are lots of other options), Go's niche seems to be command-line tools. I sort of understand that, because Go's static linking makes redistributing binaries relatively easy (although Go by no means has a monopoly on that). But in the space of command-line tools, Go's argument handling is frankly bizarre: it looks at decades of precedent about what users expect from argument syntax and behavior and decides to throw it all away and reinvent the wheel. I guess that means this comment (rant?) has ended up where it started: Go defies convention, basically "just because". By contrast, C defines convention. "If you like C, you will love Go"? Nope, not at all.
kevbin 6y ago
> If you like C, you will love Go That may be true. But if you love C you’re going to hate Go like you’ve never hated any thing ever before.

Lariscus 6y ago

I like C but strongly dislike Go. They share nothing other than having a small(ish) feature set.

BoorishBears 6y ago
I agree. Go feels like it's aimed at creating applications that run at a level above where C traditionally runs while keeping the pared down feature set of C, and it just doesn't work well imo. I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names. It's like the simplicity gets in the way of itself. - My take is, use Go for a bit, take the "less is more" mentality with you to a language more suited for real work. ps: I'm not saying you can't use Go for real work before someone flies at me. I'm just saying that Go's strength is the mentality people have when using it, as a language it's not particularly enabling, and that's by design if anything...
- bak3y 6y ago
  Meanwhile the place I work writes all microservices in go and all of my team's (DevOps) tools are also written in go...
  - BoorishBears 6y ago
    I explicitly added the "ps" to avoid the situation where all the replies are fairly empty comment saying "Well we use it!" I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages. That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional effort it took to deal with what was missing There's an implicit ymmv here of course, because I'm not saying no one can find Go useful, I can see how in certain worlds with certain teams with certain priorities it'd all work out. It's just not for me.
    - murukesh_s 6y ago
      I have used Go in production. I found it roughly takes 2-3x additional time it takes to develop the same functionality in Node.js (with typescript). But it runs faster. If you want to write code that is probably not going to be thrown away it may be wise to invest the additional time in Go. However can't recommend that for building experimental code/APIs etc which are time bound and may/can get replaced (or split into micro services) in future if it becomes massively successful..
      - AlchemistCamp 6y ago
        And that's saying something give that neither Node nor TypeScript have ever had productivity as a main selling point! Imagine evaluating the time to market for an experimental back-end written in Rails, Laravel, Phoenix, etc vs Go! The difference is staggering.
        konart 6y ago
        >Rails, Laravel, Phoenix, etc vs Go! Comparing frameworks and a language, really?
        AlchemistCamp 6y ago
        Absolutely! There are obvious productivity differences between the languages themselves and frameworks can make it even more apparent. Different languages make writing the DSLs used in Rails-like frameworks easy, difficult or impossible. Much of my professional career was spent working on Node back-ends with a variety of frameworks and none of them were even close in terms of succinctness or productivity.
- Thaxll 6y ago
  The last couple of years are showing that Go delivers, it's pretty easy to find dozen of "real" software written in Go that are weidly used.
  - BoorishBears 6y ago
    Sometimes I don't know why I bother talking about Go. It's proponents are so quick to go defensive that no one is capable of reading any complaint in an even mildly charitable light. I mean I shouldn't literally have to say "I'm not saying you can't use Go for real work before someone flies at me." When talking about a language as widely used as Go right? Like that's common sense! And yet of course I'm getting replies that do exactly that because of how darn defensive people need to be about it.
    - Thaxll 6y ago
      Maybe don't use things like " to a language more suited for real work."
      - BoorishBears 6y ago
        There is a literal full paragraph dedicated to explaining it, maybe don't ignore the oodles of context I left to avoid exactly what you did. Saying other languages are more suited to real work doesn't mean Go isn't suited at all, it literally means other languages are more angled towards the "end product" or the "real meat and potatoes" of just making a thing work than Go. It's literally a strength of Go. Go doesn't want to include the kitchen sink or even confine you to having a kitchen at all and I respect that. But I'm saying that other languages that include more in the way of affordances can help one be more productive, and I believe combining a language that includes more, with the mindset of not abusing the buffet is a winning combination. Ymmv, I'm not an oracle, I just expect people to read things in a reasonably charitable way which usually works fine as long as they're not being defensive.
- steve_adams_86 6y ago
  I agree about becoming okay with bad code. But I think if you understand and embrace that, there’s a place for it and it can be quite powerful and easy to use at times. It’s a trade off that makes sense sometimes. I think the problem appears when people treat Go like it doesn’t have any problems. All languages do. As I’ve mentioned recently though, I don’t think I’d ever want to use Go as a forever solution to a complex problem. I’m sure some people could do it and do a great job, but I’m not one of those people. I need the ability to abstract and ensure more safety, or I’ll never feel secure with what I’m building.
- blablabla123 6y ago
  > I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names. Not well or hastily written Go is easily like that. I can only guess why you point out the repetition but when you look at well written Go code like in the Go std library, there isn't much repetition happening and it looks rather elegant. At the same time it can be quite some effort to create such code and might take several iterations. Documentation-wise I like the official documentation, it gives a lot of pointers why Go is how it is. Also obviously it's not for every use-case. Where it works really well IMHO is where error handling is a vital part of the application. (And of course anything concurrent is quite a breeze)
  - BoorishBears 6y ago
    Not having generics, by definition, invites a lot of repetition and boiler plate. I know generics are overrated and coming soon, but right off the bat that stuck out. I recall a point where I had written a function that needed to return a channel, but of course had to forgo types due to the lack of generics. The end result was having to wrap that channel in another channel that added typing at each call site. I asked around in go circles if that made sense, and called out how bad the felt but the answer was "no that's great! channels are cheap! the repetition is good because it's simple!" - The error handling has some sore points to that end too, and the implicit shadowing with shorthand assignments on one hand makes it easier to deal with multiple errors, but on the other hand introduced subtle logic bugs on one than more occasion where "err" was silently shadowed, which I greatly disliked. I'm actually suprised Go didn't forgo shadowing for the shorthand operator and force people to label their errors when dealing with multiple, it seems very "in brand", but I guess even Go draws the line somewhere lol - Then there's the whole stack trace situation. Which after plenty of reading still just wasn't making sense. I mean the idea of logging a stack of wrapped messages sounds very nice, but man proper stack traces not being the first class citizen of error handling just did not make sense to me in a language I hear referenced for systems work so much (and I realize they can be had) I saw proposals to rework Go's error handling, I don't know if any progress has been made to that end, but it's another example where simplicity can get in the way of itself - And I'll balance this all out by saying it was still fun to write, I don't want to seem like I'm just shitting on Go for existing. It's just these little warts that I kept getting over with just a little bit of "idiomatic Go" which I often found was just writing a little bit more code than you're used to, started to add up. And eventually I realized I was creating something that, while very easy to reason about, had a lot more to reason about than it needed to. That's where I kind of petered out in my personal usage.
- skrtskrt 6y ago
  I will take sometimes-tedious boilerplate over many-many-layered abstractions. You can write any language any which way, but some languages just have a culture of boilerplate vs abstractions. The most popular Python and Java libraries seem to love endless layers of indirection, and when it doesn't fit exactly what you need, you bang your head against the wall monkeypatching it to make it work since your whole app is already written in X mega library. Go culture seems to be quite a bit more boilerplate-y and uses smaller more composable libraries. It's just refreshing. Really I just need to buckle down on Rust, but I think it's a fair bet that teams and shops that bring in a lot of young programmers and want to ramp them up fast may cringe a bit at the learning curve of Rust. That's why for now in terms of a bet on employability, I am prioritizing experience with Go.
37ef_ced3 6y ago
Take Go's slices, for example Realize a Go []int ("slice of int") is just a C struct like this, passed by value: struct intSlice { int* addr; int len; int cap; }; The memory at addr is not owned by the slice. All the slice operations are simply notation for manipulating the struct. Go's garbage collection makes the whole thing work well This can be confusing if you're used to C++'s std::vector (which owns the memory) or Python's slices. Go's slices are a shallow pointer/length system exactly like is used in C all the time. For example: void sort(int* addr, int len); becomes func sort(a []int) A Go slice is just a formalization of C's pointer/length idiom, with terse notation for manipulation
- traes 6y ago
  I'm not really sure saying that features in Go can be modeled in C really suggests that they are similar as languages. Syntax is very important.
- nyanpasu64 6y ago
  Go's slices don't act like what I thought were called "non-owning references"(Rust's &/&mut [T] or C++'s std::span<T/T const>), which reference memory whose lifetime is bounded by something else (like a vector or array or shared pointer). Instead it's "shared ownership" where memory is referenced by one or more slices (and no single owner) which can reference and mutate the slice simultaneously, and it's freed by the GC sometime after all the slices are gone. This reminds me of Numpy's ndarrays, which act more like "owning containers" (which may sometimes share ownership and alias) than "non-owning references".
  - erik_seaberg 6y ago
    Slices are kind of a mess. They should either be uniqueness types or passed by reference (the way maps and channels are, and NIO buffers from Java). Instead they’re passed by value so multiple copies exist whose sizes and sometimes contents aren’t in sync.
- mhh__ 6y ago
  Slices should be the absolute bare minimum for a modern systems language, it's not really a reason to switch in my case If I want to write flat/simple code I'll just C, Go doesn't really offer anything to me because I want to be relatively low-level and able to make the compiler save my time.

alpaca128 6y ago

I'm not a C fan but isn't Zig much closer to C's philosophy while fixing bad parts than Go? Especially due to the garbage collection, at which point Go suddenly competes with many more simple languages.

jerf 6y ago
It depends on your definition of "C's philosophy", no sarcasm, and no implied preference by me for any particular definition, as I believe many have merit. Language philosophies evolve, and C, being so many decades old, has evolved a lot. The original philosophy is probably little more than a seed crystal at this point for the several philosophies that have been loaded on to it over the years. It is probably reasonable to say that Zig is closer to C's current philosophy in practice, which encompasses many additional developments over the decades to deal with various aspects of C and programming real machines that have arisen as both have changes, and Go closer to C's original philosophy of simplicity and relative ease of use. (In modern times, C is not one of the easier languages to use any more, due to significant advancements in the field of making easy-to-use languages. But it was originally intended to be an advancement there itself.) By similar logic, I can say with a straight face that all of Go, C++, Zig, Rust, and Swift (and more) are "evolutions in general-purpose programming languages like C", despite their wild differences, because the world has gotten larger, and there is room for a lot of variations like that, each addressing different aspects of the newer, larger world.

Jnr 6y ago

If I would have to replace C with anything, I would choose Rust and not Go.

simias 6y ago
To me Rust is more like "C++ done right". It's massively bigger, more complicated and slower to compile than C. The C ABI is also the de-facto lingua franca for language interop, something that's not easily achievable with Rust or C++ (or Go, for that matter).
- Jnr 6y ago
  Have you tried Rust? The ABI in Rust is doable: https://people.gnome.org/~federico/blog/rust-stable-abi.html https://people.gnome.org/~federico/blog/rust-stable-abi.html And it doesn't feel like C++ when writing it. The syntax and language features are nice and feel modern. It does require more attention because of what it compiles down to, but the compiler is there to help with it. I haven't been excited about any programming languages in years, but Rust has certainly taken my attention lately.
  - simias 6y ago
    I love Rust so dearly that I wish I could marry it, but I still feel that it's a massively more complicated language than C.

deleted 6y ago

[deleted]

cute_boi 6y ago

I like C but I would prefer Rust over Go. Go may be simple but I really hate using conventions like init(), comments working like syntax, captial letter means published etc.

steve_adams_86 6y ago
Do Go comments work like syntax? Do you mean that they need to be formatted a certain way like they’re language syntax?
- grey-area 6y ago
  The Go authors have (ab)used comments to extend the language in experimental ways for code generation, build pragmas and recently file embedding. They’ve done this to avoid breaking the language stability guarantee, not sure if there were other reasons. I think it’s a mistake personally to create this sort of metalanguage in comments (now you have two problems!) but it’s easy to avoid using this most of the time as the uses are pretty esoteric.
  - skrtskrt 6y ago
    File embedding is a common enough use case (HTML templates, config files) that it really makes me cringe that it's being done with comments.
    - grey-area 6y ago
      I just keep my templates and config in separate files. There are good reasons to keep them separate anyway (allows config without recompile for example) and for the apps I work on distribution isn’t a problem. So I haven’t really had to use comments as code in 7-8 years of go. Perhaps it’ll become more common with the embed stuff. But then I don’t use struct tags either so I guess I’d prefer Go to be even simpler.
- _ph_ 6y ago
  No, Go comments are just comments. They have been used though to add meta-information to special tools. So unless you use those tools and require to add the specific meta-information, you can treat comments as plain comments. Hiding certain meta-information, like exporting a function with a C-compatible signature when building a shared library is not a great way of doing things, but on the other side, it is a special usage which isn't part of the language itself, so not part of its syntax.

simias 6y ago

My main small day-to-day usability gripes with C are lack of type inference, lack of destructors and terrible ergonomics for error handling. Go solves two out of three, but it really dropped the ball hard on error handling which is very disappointing IMO. Things like generics and garbage collection involve some deep tradeoffs, so I get Go's take on them, even if I don't necessarily agree with it. On the other hand IMHO Go's crappy error handling boilerplate is not something I find acceptable in a modern programming language.

enw 6y ago
How would you design the error handling? Personally I'm glad Go has stayed out of exceptions (panics don't count), at scale it's so much easier to reason about flow.
- bmn__ 6y ago
  Monadic error handling like in ML work-alikes, Rust etc. would be a good start. Adopt: • https://github.com/rebeccaskinner/gofpher https://github.com/rebeccaskinner/gofpher • https://speakerdeck.com/rebeccaskinner/monadic-error-handling-in-go https://speakerdeck.com/rebeccaskinner/monadic-error-handlin... I've been talking to the local Go user group. No one even knows about that concept. This continues a pattern of general ignorance/lack of looking beyond one's horizon I've noticed.
steve_adams_86 6y ago
The error handling feels deeply wrong to me too. I love the explicitness and how hard it is to ignore errors - all languages should make it so easy to expect and handle potential errors - but other features (or lack thereof) of the language make it so you can’t handle any of it in concise or sane ways. Code is plastered with the same boilerplate, everywhere, always. It makes up a significant mount of all Go code.
autarch 6y ago
I agree that the error handling is terrible, but I'm not sure how much better it could be without generics. For me, the gold standard in error handling is Rust, where the type system simply does not allow you to ignore errors. This means that the existence of error handling is checked at compile time. Of course, this doesn't mean your error handling is _good_, but I think that's beyond any language design to enforce. But the Rust system is entirely built around a generic Result type, where both the non-error result (an int, string, struct, etc.) _and_ the error type itself are both generic.

xscott 6y ago

> Go fixes C's well-understood flaws (declaration resembling use This seems to be a common belief, but since Go kept pointer syntax as prefix, you're still stuck needing parens in some unfortunate cases: https://blog.golang.org/declaration-syntax https://blog.golang.org/declaration-syntax (see the part about pointers near the bottom) As Rob Pike writes in that link, they could've fixed it and still had declaration resembling use if they had chosen a suffix operator for pointers. He notes that Pascal uses ^, but it seems like @ might be a better choice: int foo // an integer int foo@ // pointer to int int foo[10]@ // 10 pointers int foo@[10] // pointer to array int foo()[10]@ // function that returns an array of 10 pointers In my opinion, they almost fixed it and then punted. As such, it's just different, but not really better.

burnthrow 6y ago

I thought this sounded familiar https://news.ycombinator.com/item?id=25622389 https://news.ycombinator.com/item?id=25622389 https://news.ycombinator.com/item?id=25555457 https://news.ycombinator.com/item?id=25555457 https://news.ycombinator.com/item?id=25531118 https://news.ycombinator.com/item?id=25531118

booleandilemma 6y ago
So the account was created 34 days ago and he's posted that same message 4 times already.

dpryden 6y ago

I'd like to chime in and say that I also like C but really dislike Go. C is simple, to what today is nearly an absurd degree, but it at least integrates well with an enormous ecosystem of existing tooling and libraries. Go, by contrast, feels the need to re-invent every possible wheel, often with a seemingly intentional effort to be different just because. C ABIs are rock solid on every platform. Any language or tooling in the world can load functions from a C library. By contrast, try calling Go from another language. You will quickly give up and use network protocols or subprocesses instead. The converse is true too: on major platforms, the C library defines the operating system more than the kernel does. (I mean, in a Unix sytem, the entire libc is documented in the man pages. Documentation for writing C is literally built into the operating system.) By contrast, Go decides to avoid the standard platform ways of calling every operating system function, and instead implements syscalls directly into the kernel, basically just because Go hates interoperating with anything that's not Go. C is a good language not because it is a good language, but because it is a good ecosystem. Unix and C are closely intertwined. (Even Win32 and C are pretty closely intertwined!) I could imagine a Go-based Plan9-like system -- if that existed, and had decades of engineering behind it, I could see the argument being made that Go's ecosystem compares to C's. But while Go may aspire to that, it isn't anywhere near there yet. And when you start comparing Go with other languages on the basis of language features, I think Go fails laughably more often than not. (I'll give you "C++ is a clumsy mess", though.) But compare Go with Rust, with C#, with Haskell -- for that matter, compare Go with Java and I think Go is a less powerful, less useful language to write real code in. If I want a lightweight, quick-and-dirty program, I'll use Python. If I want to write a reusable library that gets plugged into other software, I'd go with C (or at least write the interop layer in C). If I want a high-performance server, these days I would probably go with Rust. If I want a pragmatic, well-rounded language to write a large project in, I think C# would probably be my first choice. What space does that leave for Go? Outside of microservices (where I contend that Rust is a much better choice, and there are lots of other options), Go's niche seems to be command-line tools. I sort of understand that, because Go's static linking makes redistributing binaries relatively easy (although Go by no means has a monopoly on that). But in the space of command-line tools, Go's argument handling is frankly bizarre: it looks at decades of precedent about what users expect from argument syntax and behavior and decides to throw it all away and reinvent the wheel. I guess that means this comment (rant?) has ended up where it started: Go defies convention, basically "just because". By contrast, C defines convention. "If you like C, you will love Go"? Nope, not at all.

kevbin 6y ago

> If you like C, you will love Go That may be true. But if you love C you’re going to hate Go like you’ve never hated any thing ever before.