> True but you could forget to do that in your alternative example as well
Not really, unless I'm misunderstanding you.
var a = if foo() { bar() } else { }
will (depending on the language) either not compile, or the type of `a` will be inferred to a common type of `typeof(bar())` and `None` (perhaps some `Any` type). And this would almost surely cause a compile time issue the moment you use `a` as the type you expect. The other way is to simply write
final int a = if foo() { bar() } else { }
and that would immediately not compile.
> Actually the compiler would catch that too.
Not quite:
b := someFunc()
var a int
if foo() {
a = bar()
} else {
b = baz() // meant to assign to a
}
> In fact I had already cited reasons I like Go.
I was talking about why the language became somewhat popular, not about why some people may like it or not. Some of the golang authors already worked on a predecessor to it, but it never got anywhere, because they were't at Google at the time, so it didn't have the Google brand behind it.
> People have and they do though.
Like the "arguments" about how "null pointers are part of the computer" or similar nonsense about why they included nullable by default pointers? Or that compile checked enums are not really useful because you can just check them yourself, etc.
> this is me pointing out that talk is cheap and most of the critics on HN are just average engineers at best.
This is just diverting now. You don't have to be a brilliant PL person to see what's good and not in the area, after using different languages in production and finding out what features are useful, and which aren't, and seeing others struggling with issues already solved in different programming languages and environments, or people writing hacks to get around the limitations of the language, ending up with more complexity than if the language supported those features to begin with.
> Clearly not everyone agrees with you there because a lot of successful important projects are now based on Go.
There are large projects based in C and assembly as well. This is a non-argument. I think it was kubernetes that was notorious for using large amounts of auto generated code because golang doesn't have generics. Not to mention that if you want to do unit testing you end up with a large mess of auto generated code to do mocking, an issue that's solved in other languages a long time ago.
It's just that people repeat mistakes instead of learning from them, and easily follow fads and are prone to claims that are not strongly backed. golang is another manifestation of this.
You are misunderstand me. I'm saying you could type the following by mistake:
if foo() { bar() } else { baz() }
Which is the equivalent of the human error you were demonstrating in Go.
> Not quite: b = baz() // meant to assign to a
Actually yes. You'd get the following error:
b declared and not used
The go compiler checks for variables declared and, well as the error message literally says.
Go's compiler is actually very good. The error messages are descriptive and it's strict enough (though some say too strict) to catch a whole plethora of silly user errors.
Sure, other compilers have this too. But the only one I've used (at least recently) that betters Go is Rust.
But of course you should already know this because you're an expert in Go. ;)
> I was talking about why the language became somewhat popular, not about why some people may like it or not.
The two are mutually inclusive. The language is popular because people like it. Again I'm forced to reiterate the question: "Why do you find it so hard to accept that other people might like something you don't?"
> Like the "arguments" about how "null pointers are part of the computer" or similar nonsense about why they included nullable by default pointers? Or that compile checked enums are not really useful because you can just check them yourself, etc.
Clearly I'm not going to agree with every defensive point ever made about Go but just because you can cherry pick a few of the more absurd examples doesn't mean that the well reasoned ones aren't valid.
> This is just diverting now. You don't have to be a brilliant PL person to see what's good and not in the area, after using different languages in production and finding out what features are useful, and which aren't, and seeing others struggling with issues already solved in different programming languages and environments, or people writing hacks to get around the limitations of the language, ending up with more complexity than if the language supported those features to begin with.
That wasn't what I was commenting on. It was the comments about how people who are clearly more experienced than you seemingly know jack shit in your outspoken opinion.
You're just letting your arrogance get the better of you by making defamatory and clearly untrue comments about your own peers and developers with likely decades more experience in designing programming languages. I'm just pointing that out.
You don't have to agree with the design of Go but calling them incompetent and stupid is clearly taking things too far. In fact it completely undermines your own credibility.
> There are large projects based in C and assembly as well. This is a non-argument.
And C and assembly are well suited for some specific domains as well.
> This is a non-argument.
Your argument is that Go isn't suitable and I was evidencing how it is used in the very fields you assumed it couldn't. That - therefore - is the very definition of a valid counterargument.
> It's just that people repeat mistakes instead of learning from them, and easily follow fads and are prone to claims that are not strongly backed. golang is another manifestation of this.
"Mistakes" as defined by your own binary view of programming languages?
"fad" defines something as short lived and Go has long since surpassed that stage.
I don't know if your comments are driven by insecurity or over confidence but, honestly, your attitude here is pathetic. I never set out to try and convince you to use Go - just to try and help you understand why some people like to use it. But since this is clearly just an exercise for you to assert your own arrogance onto the entire Go community - I'm going to quit the debate.
> You are misunderstand me. I'm saying you could type the following by mistake:
if foo() { bar() } else { baz() }
Then there wouldn't be a variable assigned to use in the first place. This is not the issue at hand here.
> Actually yes. You'd get the following error:
b declared and not used
The first line I wrote declared and assigned to b, but in the if/else statement, b was overridden, so the error you mentioned won't happen, it will simply get overridden and a bug would happen.
> "Why do you find it so hard to accept that other people might like something you don't?"
It seems most people don't realize the other advances in languages designed to reduce errors, which golang discards on purpose and without good reason, and they just accept the hype and marketing around golang. You keep hearing that golang's gc is the best gc around and things to that extent, clearly incorrect nonsense.
> Your argument is that Go isn't suitable and I was evidencing how it is used in the very fields you assumed it couldn't.
The argument is that you can use any (badly) designed language to write large software, it will just end up costing more effort and resources (e.g. see javascript or large programs written in ruby and python, they're doable, but with a very large cost).
Using things better suited for the task at hand is important, especially seeing how software these days is not up to par. Then you have another badly designed language (golang) that decides on purpose to ignore research done to improve software reliability, it's not a surprise things the way they are.
> It was the comments about how people who are clearly more experienced than you seemingly know jack shit in your outspoken opinion.
Being more experienced doesn't mean not falling into a closed way of thinking, which clearly shows if you follow the golang authors and their history. This is an appeal to authority fallacy.
> And C and assembly are well suited for some specific domains as well.
That's not the point of discussion. The point is that for practically anything other than some small tool type work (even there it's arguable), there are other strictly superior offerings.
> to try and convince you to use Go
I already use it at work, that's how I'm aware of it's enormous shortcomings, by using it myself, and hearing and seeing how others use it and complain about it as well. That's why it's a fad, the company is quite invested in it now so it's difficult for them to switch, so they have to find hacks to deal with its shortcomings.
oh geez, this whole conversation is a depressing read.
@apta I've noticed every single comment you've posted on this topic has been a rant at Go. It really sounds like the issue is you rather than the programming language. If you hate your job that much then go work elsewhere. If you're the expert developer you claim to be then finding other work shouldn't be hard for you and the upside (aside better job satisfaction and potentially more money) is you then feel less compelled to shout at people on Internet forums.
Not really, unless I'm misunderstanding you.
will (depending on the language) either not compile, or the type of `a` will be inferred to a common type of `typeof(bar())` and `None` (perhaps some `Any` type). And this would almost surely cause a compile time issue the moment you use `a` as the type you expect. The other way is to simply write and that would immediately not compile.> Actually the compiler would catch that too.
Not quite:
> In fact I had already cited reasons I like Go.I was talking about why the language became somewhat popular, not about why some people may like it or not. Some of the golang authors already worked on a predecessor to it, but it never got anywhere, because they were't at Google at the time, so it didn't have the Google brand behind it.
> People have and they do though.
Like the "arguments" about how "null pointers are part of the computer" or similar nonsense about why they included nullable by default pointers? Or that compile checked enums are not really useful because you can just check them yourself, etc.
> this is me pointing out that talk is cheap and most of the critics on HN are just average engineers at best.
This is just diverting now. You don't have to be a brilliant PL person to see what's good and not in the area, after using different languages in production and finding out what features are useful, and which aren't, and seeing others struggling with issues already solved in different programming languages and environments, or people writing hacks to get around the limitations of the language, ending up with more complexity than if the language supported those features to begin with.
> Clearly not everyone agrees with you there because a lot of successful important projects are now based on Go.
There are large projects based in C and assembly as well. This is a non-argument. I think it was kubernetes that was notorious for using large amounts of auto generated code because golang doesn't have generics. Not to mention that if you want to do unit testing you end up with a large mess of auto generated code to do mocking, an issue that's solved in other languages a long time ago.
It's just that people repeat mistakes instead of learning from them, and easily follow fads and are prone to claims that are not strongly backed. golang is another manifestation of this.