4 ms·

Please don't write programs in go. Sure it looks awesome on the surface but it's a nightmare when you get a null pointer panic in a 3rd party library. Instead

by bb88 4y ago

Please don't write programs in go. Sure it looks awesome on the surface but it's a nightmare when you get a null pointer panic in a 3rd party library. Instead use Rust. See here for more info: https://getstream.io/blog/fixing-the-billion-dollar-mistake-in-go-by-borrowing-from-rust/ https://getstream.io/blog/fixing-the-billion-dollar-mistake-...

tomcam 4y ago
Or, you know, whatever the fuck language you care to use.
michaelsshaw 4y ago
Nothing wrong with any of these languages, especially C. It's been around since the early 70s and is not going anywhere. There's a very good reason it (and to an extent C++) is still is the default language for doing a lot of things since everyone understands it.
- KronisLV 4y ago
  C and C++ both have excellent library support, perhaps the best interop of any language out there and platform support that cannot be beat. That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Thus, unless you have a good reason (of which, admittedly, there are plenty) to use C or C++, something that holds your hand a bit more might be a reasonable choice for many people out there. Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good library support and decent platform support. Rust is a safer choice, but at the expense of needing to spend a non-insignificant amount of time learning the language, even though the compiler is pretty good at being helpful too.
  - bb88 4y ago
    > perhaps the best interop of any language out there and platform support that cannot be beat. Disagree here. The C++ ABI has pretty much been terrible for the last 20 years. C is fine in this regard though.
    - pjmlp 4y ago
      Not really, https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-function-abi https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...
  - throwaway894345 4y ago
    > That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Many of the most highly credentialed, veteran C developers have said they can't write secure C code. Food for thought. > Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good library support and decent platform support. Rust is a safer choice, but at the expense of needing to spend a non-insignificant amount of time learning the language, even though the compiler is pretty good at being helpful too. Go doesn't have the strongest static guarantees, but it does provide a decent amount of static guarantees while also keeping the iteration cycle to a minimum. Languages like Rust have significantly longer iteration cycles, such that you can very likely ship sooner with Go at similar quality levels (time savings can go into catching bugs, including bugs which Rust's static analysis can't catch, such as race conditions). Moreover, I've had a few experiences where I got so in-the-weeds trying to pacify Rust's borrow-checker that I overlooked relatively straightforward bugs that I almost certainly would've caught in a less-tedious languages--sometimes static analysis can be distracting and in that respect, harm quality (I don't think this a big effect, but it's not something I've seen much discussion about).
    - _gabe_ 4y ago
      > secure C code. There is unsecure code hidden in every project that uses any programming language ;) I get what you're saying here, you're specifically talking about security vulnerabilities from memory related errors. I honestly wonder how many of these security vulnerabilities are truly issues that never would have come up in a more "secure" language like Java, or if the vulnerabilities would have just surfaced in a different manner. In other words, we're constantly told C and C++ are unsafe languages they should never be used and blah blah blah. How much of this is because of the fact that C has been around since the 1970s, so its had a lot more time to rack up large apps with security vulnerabilities, whereas most of the new recommended languages to replace C and C++ have been around since the late 90s. In another 20 years will we be saying the same thing about java that people say about C and C++? And will we be telling people to switch to the latest and greatest because Java is "unsafe"? Are these errors due to the language, or is it because we will always have attackers looking for vulnerabilities that will always exist because programmers are fallible and write buggy code?
- pjmlp 4y ago
  One reason is historical baggage and sinergy. It is easier to just pick an existing library and deal with security flaws, than trying to ramp up an ecosystem from scratch, unless one has the backing of a multinational pumping up development.
AnimalMuppet 4y ago
You've obviously been burned by null pointers (probably not just once). And you think they are a problem, and you're right. And you think they are a mistake, and you could be right about that, too. But they're not the only problem. Writing async network servers can be a problem, too. Go helps a lot with that problem. If for your situation it helps more with that than it hurts with nulls, then it can be a rational choice. And, don't assume that go must be a bad choice for all programmers, in all situations. It's not.
- bb88 4y ago
  And it's certainly not perfect in writing async network servers. It adds new concurrency bug types: https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf
- lmm 4y ago
  > But they're not the only problem. No, but they're literally more than 50% of bugs, in my experience, so they're a bigger problem than all your other problems put together.

by bb88 4y ago

tomcam 4y ago

Or, you know, whatever the fuck language you care to use.

michaelsshaw 4y ago

Nothing wrong with any of these languages, especially C. It's been around since the early 70s and is not going anywhere. There's a very good reason it (and to an extent C++) is still is the default language for doing a lot of things since everyone understands it.

KronisLV 4y ago
C and C++ both have excellent library support, perhaps the best interop of any language out there and platform support that cannot be beat. That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Thus, unless you have a good reason (of which, admittedly, there are plenty) to use C or C++, something that holds your hand a bit more might be a reasonable choice for many people out there. Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good library support and decent platform support. Rust is a safer choice, but at the expense of needing to spend a non-insignificant amount of time learning the language, even though the compiler is pretty good at being helpful too.
- bb88 4y ago
  > perhaps the best interop of any language out there and platform support that cannot be beat. Disagree here. The C++ ABI has pretty much been terrible for the last 20 years. C is fine in this regard though.
  - pjmlp 4y ago
    Not really, https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-function-abi https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...
- throwaway894345 4y ago
  > That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Many of the most highly credentialed, veteran C developers have said they can't write secure C code. Food for thought. > Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good library support and decent platform support. Rust is a safer choice, but at the expense of needing to spend a non-insignificant amount of time learning the language, even though the compiler is pretty good at being helpful too. Go doesn't have the strongest static guarantees, but it does provide a decent amount of static guarantees while also keeping the iteration cycle to a minimum. Languages like Rust have significantly longer iteration cycles, such that you can very likely ship sooner with Go at similar quality levels (time savings can go into catching bugs, including bugs which Rust's static analysis can't catch, such as race conditions). Moreover, I've had a few experiences where I got so in-the-weeds trying to pacify Rust's borrow-checker that I overlooked relatively straightforward bugs that I almost certainly would've caught in a less-tedious languages--sometimes static analysis can be distracting and in that respect, harm quality (I don't think this a big effect, but it's not something I've seen much discussion about).
  - _gabe_ 4y ago
    > secure C code. There is unsecure code hidden in every project that uses any programming language ;) I get what you're saying here, you're specifically talking about security vulnerabilities from memory related errors. I honestly wonder how many of these security vulnerabilities are truly issues that never would have come up in a more "secure" language like Java, or if the vulnerabilities would have just surfaced in a different manner. In other words, we're constantly told C and C++ are unsafe languages they should never be used and blah blah blah. How much of this is because of the fact that C has been around since the 1970s, so its had a lot more time to rack up large apps with security vulnerabilities, whereas most of the new recommended languages to replace C and C++ have been around since the late 90s. In another 20 years will we be saying the same thing about java that people say about C and C++? And will we be telling people to switch to the latest and greatest because Java is "unsafe"? Are these errors due to the language, or is it because we will always have attackers looking for vulnerabilities that will always exist because programmers are fallible and write buggy code?
pjmlp 4y ago
One reason is historical baggage and sinergy. It is easier to just pick an existing library and deal with security flaws, than trying to ramp up an ecosystem from scratch, unless one has the backing of a multinational pumping up development.

AnimalMuppet 4y ago

You've obviously been burned by null pointers (probably not just once). And you think they are a problem, and you're right. And you think they are a mistake, and you could be right about that, too. But they're not the only problem. Writing async network servers can be a problem, too. Go helps a lot with that problem. If for your situation it helps more with that than it hurts with nulls, then it can be a rational choice. And, don't assume that go must be a bad choice for all programmers, in all situations. It's not.

bb88 4y ago
And it's certainly not perfect in writing async network servers. It adds new concurrency bug types: https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf
lmm 4y ago
> But they're not the only problem. No, but they're literally more than 50% of bugs, in my experience, so they're a bigger problem than all your other problems put together.