3 ms·

I agree with the programming language sentiments, but in its defense, Go is very much a language for and by people who don't care about programming languages. I

I agree with the programming language sentiments, but in its defense, Go is very much a language for and by people who don't care about programming languages. I mean this in the nicest way. Rob Pike doesn't care that the concurrency is unsafe or that nil is the billion dollar mistake. Neither do most users of Go. Does that make Go a good language? No. But that's besides the point. It's a convenient, good enough language combined with a compelling set of tools that make it easy to use. It's the crocs of programming languages.

bborud 3y ago
Well, some of us kind of care, but not enough to pay the price of ending up using a languages where people care more about language design than writing programs. Go is very much a language for getting things done rather than winning beauty contests. And it has proven itself as a productive language. I've worked with perhaps half a dozen real "language enthusiasts" in my time. People who spend lots of time obsessing over "perfect" language design and non-mainstream languages. People who never stick to a language for more than a year or three, who insist everyone else accommodate their current fascination with some language, and who leave behind codebases full of code that will be hard to maintain because they are a patchwork of languages. Not caring that the organization then has to take the time both train people in thoselanguages and ensure they have enough people experienced with the language to be able to use a portion of their time to train newbies. On a few occasions I actually researched their job history and found that these people had a tendency to make a lot of noise, but produce very little of consequence. They'd find jobs at the outskirts of projects where it would be easier to indulge in their interests without clashing with the principals. Most of their code would be gone just months after they left the position. My advice is that if you care about building stuff, don't hire language enthusiasts.
- jtasdlfj234 3y ago
  Okay, circling back here. So your position is that nil safety would reduce the value of Go's "getting things done"? As someone who uses Go in production, I don't agree at all.
  - bborud 3y ago
    No, I'm saying that nil safety is a lower priority for me than overall productivity. If Go had nil safety that would be very nice. But it doesn't. And it doesn't bother me all that much. Go set out to be a practical language for writing servers - not to tick all the boxes. In the 8 or so years I've used Go for production software, it hasn't actually turned out to be a big problem compared to my experience with C and C++. If it was a huge problem it should have manifested as such. But in my experience, nil errors are extremely rare in our production code. If this hadn't been the case, we would probably have invested in Rust. But I can't deny that when I look at those of my friends who use Rust, I'm not exactly impressed with what they accomplish. Even a couple of years in, I see them spending a lot of time fighting with the compiler, having to backtrack and re-think what they are doing or, sometimes, having to rewrite/replace code (sometimes third party) that isn't as strict as they wish to be. Is it worth the extra effort? That being said, sure, I think Go would be less of a "getting things done" if the maintainers had felt an obligation to add every checklist item to the language from the start. As someone else pointed out, the fact that they had the guts to say no to a bunch of things was a really good thing. Just throwing all your favorite ingredients in the pot and stirring it doesn't guarantee you'll end up with a delicious dinner. There's a lot more to it than that.

bborud 3y ago

Well, some of us kind of care, but not enough to pay the price of ending up using a languages where people care more about language design than writing programs. Go is very much a language for getting things done rather than winning beauty contests. And it has proven itself as a productive language. I've worked with perhaps half a dozen real "language enthusiasts" in my time. People who spend lots of time obsessing over "perfect" language design and non-mainstream languages. People who never stick to a language for more than a year or three, who insist everyone else accommodate their current fascination with some language, and who leave behind codebases full of code that will be hard to maintain because they are a patchwork of languages. Not caring that the organization then has to take the time both train people in thoselanguages and ensure they have enough people experienced with the language to be able to use a portion of their time to train newbies. On a few occasions I actually researched their job history and found that these people had a tendency to make a lot of noise, but produce very little of consequence. They'd find jobs at the outskirts of projects where it would be easier to indulge in their interests without clashing with the principals. Most of their code would be gone just months after they left the position. My advice is that if you care about building stuff, don't hire language enthusiasts.

jtasdlfj234 3y ago
Okay, circling back here. So your position is that nil safety would reduce the value of Go's "getting things done"? As someone who uses Go in production, I don't agree at all.
- bborud 3y ago
  No, I'm saying that nil safety is a lower priority for me than overall productivity. If Go had nil safety that would be very nice. But it doesn't. And it doesn't bother me all that much. Go set out to be a practical language for writing servers - not to tick all the boxes. In the 8 or so years I've used Go for production software, it hasn't actually turned out to be a big problem compared to my experience with C and C++. If it was a huge problem it should have manifested as such. But in my experience, nil errors are extremely rare in our production code. If this hadn't been the case, we would probably have invested in Rust. But I can't deny that when I look at those of my friends who use Rust, I'm not exactly impressed with what they accomplish. Even a couple of years in, I see them spending a lot of time fighting with the compiler, having to backtrack and re-think what they are doing or, sometimes, having to rewrite/replace code (sometimes third party) that isn't as strict as they wish to be. Is it worth the extra effort? That being said, sure, I think Go would be less of a "getting things done" if the maintainers had felt an obligation to add every checklist item to the language from the start. As someone else pointed out, the fact that they had the guts to say no to a bunch of things was a really good thing. Just throwing all your favorite ingredients in the pot and stirring it doesn't guarantee you'll end up with a delicious dinner. There's a lot more to it than that.