5 ms·

Uhh, maybe. Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your p

Uhh, maybe. Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your pipeline. But are you considering all the issues that didn't pop up because you chose Go? Java's boilerplate code? Rust and C++'s lifetime analysis and memory management? C's lack of tooling? Python/Typescript's runtime errors? Functional languages' tiny employee pool? How much did trouble did you save by avoiding these?

dataflow 2y ago
Thoughts on C#?
- underdeserver 2y ago
  When last I tried it, maybe around 2014? I found it a kinder, cleaner Java with better tooling. Visual Studio (not Code) is still the best IDE I've ever used. Unfortunately it's not popular in the circles I hang around in and the places I've worked. Now that .NET core is the one true runtime I'd welcome an opportunity to try it again; alas, I doubt I'll have such an opportunity (at least not through work). I remember the upsides but I'm sure there are downsides I'm not aware of. I'd love to read a critique from someone with real world experience.
- jchw 2y ago
  Not that you asked me but since Go is my goto language, my thought on C# is that it looks pretty cool. C# with hill-climbing thread pool and async seems rather compelling. I really see only two (major, obvious) downsides with C#: - It has so much. language. design. This is both a strength and a weakness, of course, but C# really does take this to an extreme. I won't bother making a huge list of examples because I think you get the picture. - Microsoft needs to stop doing things that harm confidence in .NET. Between the silliness of removing hot reloading from the CLI, the situation around debugging outside of Visual Studio products, and drama around the .NET organization... I feel cautious touching the .NET ecosystem. That's saying something considering the company that backs the Go programming language. (Note: I have not used C# in production, so I can't speak to what it's like in that case. Seems like it's at least fairly "boring" in a good way for a lot of organizations though.)
  - neonsunset 2y ago
    Is there a specific aspect of language design that you see as problematic? I agree that it can be perceived as "way too many things to keep track of". I think most of it are small, atomic changes designed to reduce boilerplate that can be intuitively understood (like collection literals, additions to pattern matching and null-coalescing operators). You don't have to spend mental effort on these and if there is a scenario where more idiomatic syntax is available - the analyzer has a good chance of catching it and providing an autofix suggestion.
guappa 2y ago
Go is very boilerplate. It requires at least 3 lines of error checking every 1 line of actual code. Also it doesn't have packed structs so it's completely incapable of doing low level networking or to handle binary files (you can of course do all the bitwise operations yourself… but is it sensible to use a language that is more error prone than C in 2024?). Also due to its lack of A LOT of system calls, you will need to use modules written by someone on github, which will happily segfault if you look at them funny. So now you have hidden memory management! Fun! Of course if all you do with go is a glorified jq script… sure then it's kinda fine.
- underdeserver 2y ago
  I worked on a project with gopacket. It was completely fine.
  - guappa 2y ago
    Try defining a new packet format and ping me.
- mrbadguy 2y ago
  I’m not sure I understand the packed structs complaint. I have used Go to read binary data and it’s quite easy. You just need to ensure that all of your struct fields have fixed sizes e.g. int32 or [4]int64 or whatever. Unless I’ve misunderstood what you mean?
  - guappa 2y ago
    Yes it works, but you can't state the endianness and you have no control to decide if the compiler will decide to insert padding. It's undefined. You HOPE it works.
    - mrbadguy 2y ago
      I don’t know about the padding (certainly it never inserted any when I’ve used it) but you can definitely state the byte order upon reading or writing. That would definitely be an oversight. Take a look at the encoding/binary package: https://pkg.go.dev/encoding/binary https://pkg.go.dev/encoding/binary

dataflow 2y ago

Thoughts on C#?

underdeserver 2y ago
When last I tried it, maybe around 2014? I found it a kinder, cleaner Java with better tooling. Visual Studio (not Code) is still the best IDE I've ever used. Unfortunately it's not popular in the circles I hang around in and the places I've worked. Now that .NET core is the one true runtime I'd welcome an opportunity to try it again; alas, I doubt I'll have such an opportunity (at least not through work). I remember the upsides but I'm sure there are downsides I'm not aware of. I'd love to read a critique from someone with real world experience.
jchw 2y ago
Not that you asked me but since Go is my goto language, my thought on C# is that it looks pretty cool. C# with hill-climbing thread pool and async seems rather compelling. I really see only two (major, obvious) downsides with C#: - It has so much. language. design. This is both a strength and a weakness, of course, but C# really does take this to an extreme. I won't bother making a huge list of examples because I think you get the picture. - Microsoft needs to stop doing things that harm confidence in .NET. Between the silliness of removing hot reloading from the CLI, the situation around debugging outside of Visual Studio products, and drama around the .NET organization... I feel cautious touching the .NET ecosystem. That's saying something considering the company that backs the Go programming language. (Note: I have not used C# in production, so I can't speak to what it's like in that case. Seems like it's at least fairly "boring" in a good way for a lot of organizations though.)
- neonsunset 2y ago
  Is there a specific aspect of language design that you see as problematic? I agree that it can be perceived as "way too many things to keep track of". I think most of it are small, atomic changes designed to reduce boilerplate that can be intuitively understood (like collection literals, additions to pattern matching and null-coalescing operators). You don't have to spend mental effort on these and if there is a scenario where more idiomatic syntax is available - the analyzer has a good chance of catching it and providing an autofix suggestion.

guappa 2y ago

Go is very boilerplate. It requires at least 3 lines of error checking every 1 line of actual code. Also it doesn't have packed structs so it's completely incapable of doing low level networking or to handle binary files (you can of course do all the bitwise operations yourself… but is it sensible to use a language that is more error prone than C in 2024?). Also due to its lack of A LOT of system calls, you will need to use modules written by someone on github, which will happily segfault if you look at them funny. So now you have hidden memory management! Fun! Of course if all you do with go is a glorified jq script… sure then it's kinda fine.

underdeserver 2y ago
I worked on a project with gopacket. It was completely fine.
- guappa 2y ago
  Try defining a new packet format and ping me.
mrbadguy 2y ago
I’m not sure I understand the packed structs complaint. I have used Go to read binary data and it’s quite easy. You just need to ensure that all of your struct fields have fixed sizes e.g. int32 or [4]int64 or whatever. Unless I’ve misunderstood what you mean?
- guappa 2y ago
  Yes it works, but you can't state the endianness and you have no control to decide if the compiler will decide to insert padding. It's undefined. You HOPE it works.
  - mrbadguy 2y ago
    I don’t know about the padding (certainly it never inserted any when I’ve used it) but you can definitely state the byte order upon reading or writing. That would definitely be an oversight. Take a look at the encoding/binary package: https://pkg.go.dev/encoding/binary https://pkg.go.dev/encoding/binary