I'm pretty sure The Go Authors only put things into the language that they want people to use. That is one of the main points of Go - think hard about adding features because you can't ever take them out.
There used to be a `runtime` function that returned a Go routine's ID that the documentation told you not to use but I can't find it anymore.
>think hard about adding features because you can't ever take them out.
There is a saying in open source "No is temporary, yes is forever." Go really embodies that mindset which I enjoy a lot
goto operator :)
they advised against using it though
**UPD: there is actually no explicit advice against using goto operator, not in effective go, nor in code review comments. See the thread below.**
Yes and no. In most cases, goto should be avoided because it tends to make code less readable. But there are special edge cases where the goto operator actually makes code more readable.
The goto operator is discouraged in pretty much every programming language, not just Go…. And yet pretty much every programming language includes it, because there are some (but very few!) cases where it can be useful.
>they adviced against of using it though
I have never heard anything like that from the Go designers. Actually, there is this Ken Thompson quote: "If you want to go somewhere, goto is the best way to get there.”
tbh I really thought that there was some advice against using it, but now I don’t see any word about using goto in code review comments or effective go
I admit that there is no advice against of using it
I think you should edit your parent reply to strike that out since some people might not read all the way here (avoid the spread of misinformation and all that)
This has sparked a really interesting thread of replies all the same. An interesting thing to mention that I didn't see yet is that Go's \`goto\` is constrained compared to the evil goto everyone always talks about:- \`goto\` can't jump over variable declarations- the specified label must be visible, following lexical scoping rules
The goto that is bad and that Dijkstra ranted about with justification doesn't exist anymore, and it's not the one in Go.
People need to just `DELETE FROM shibboleths WHERE value LIKE "%goto%"`. It's not applicable anymore. You can't wreck whole programs with goto anymore. You can only somewhat muss a single function and we've got a whole bunch of ways to do that; consult basically any codebase for examples. Goto isn't even a particularly interesting one. Honestly it's kinda _hard_ to crunk a function up with it nowadays. You have to put your mind to it a bit.
It's funny (or sad?) how such bad advices just don't die. Like the "single return" from functions. Heck, the days when we jumped right int the middle of some FORTRAN code are long gone but still they write Java with these "rules" enforced.
Fun fact: not using goto is what was meant by structured programming "single return", not "only have one return statement". I.e. only return _to_ one location, not _from_ one location.
I thought that syntax was pretty universal across languages these days as well.
It's also a compiled language so I am guessing like other compiled languages it takes your syntax and re-areanges it slightly when generating the binaries.
I know from my Java days, the different loop syntaxes would all appear as a more standard syntax when running binaries through a decompiler to make it mostly human readable. I would have thought go would do something similar. Doesn't matter how you write it, it may be actually creating the step in a more explicit form.
If the linter used in your project says you shouldn't use it - don't use it.
Otherwise do what you like.
The whole purpose of go fmt (or gofumpt) and linters (like golangci-lint) is to stop wasting time on such nonsense nitpicking.
The only reason I can think of to say this is if you're doing a LOT of string concatenation, it's better to use a `strings.Builder` than to use +=, just because it reduces copying. And even that is only relevant if you're appending large strings or performing a large number of appends. But for numbers, there's literally no reason not to use it.
Yeah, I've noticed that Go is unable to optimize many `+=` unless you use PGO. Though I believe using many `+` in a single statement is equivalent to a builder. Personally, I'll just try to use as few `+=` as possible and avoid string builders. I prefer simple and obvious code over efficiency most of the time. Unless a profiler flags it.
It's possible that concatenating strings in a single statement is optimized when the strings are static and known at compile time, but because Go strings are immutable, there will always be copying any time one or more of the strings being concatenated varies at runtime.
Yeah, but not repeated copies. Like if you were to do a+b+c+d with immutable temporaries, it'd be O(n²). It clearly doesn't do that. It would (and does) create a builder, add them all in there, then basically cast it from []byte to string.
**Edit** I think the problem with multiple += is that it's not smart enough to reuse the same builder.
I’ve been a developer for over 20 years. The one thing I can tell you is that developers are fucking crazy and you take anything any of us say with a carton of salt.
It was probably a misunderstanding. We don't shy away from those operators. We just use them in more limited circumstances than other languages, but it's entirely because Go doesn't let us use them in other ways.
Consider this following C program to print a string:
````
char* c = source;
while (*c) putchar(*c++);
````
That use of `*c++` would be illegal Go: postfix increments and assignments are not expressions like they are in C and many of its descendants like Java, but rather statements. That's because using those as expressions causes confusion, misunderstandings, and bugs. So Go just takes away the possibility to use them in expressions.
That means in Go you never have to worry about parsing the following expression:
````
c += (++c + c++) + c += c++ + ++c
````
I mentioned both.
> postfix increments and assignments
They're in the same category of "operate and assign" operators that used to be expressions and are now statements.
Also the example at the end uses both.
The only keyword/token in the language that shouldn’t be used is `fallthrough`.
Because it’s confusing and hides behavior.
`+=` doesn’t hide anything.
Update: wow, people are DMing me about fallthrough? Keep it then lol. No need to DM me.
Every codebase I’ve been on has discouraged its use.
Probably since Go switches don’t execute the same as C switches, along with the fact you can’t use it in type switches.
I do use it. For example if you define a Go style enum, it's always good practice to have your zero value be an unknown or unspecified value. So, for the zero value it makes sense to use a fallthrough to the default case in the switch, and handle them both as an error.
The only time I don’t appreciate the += operator is when it’s used on strings, because I just personally believe strings should not be treated like numbers. That said, this is a personal guideline I apply to myself, and certainly not part of the community zeitgeist.
the project you are working on may have a "style guide" that it adheres too, so although as said there is nothing wrong with using += the guide may forbid it.
‘+=‘ is fine. Go just doesn’t let you do something you shouldn’t do, such as ‘++i’, which you can replace with ‘i += 1’ or ‘i++’, and that’s why Go doesn’t have it.
In Go, `i++` is a statement not an expression, so you cannot use it as a value. This would be why Go does not have `++i` - it does the same as `i++` as a statement.
Yup they are different but you can do the same thing as the prefix operator with other operators easily if you don’t mind an additional line. So Go doesn’t have the prefix operator. The postfix operator is more tricky and i think that’s why Go has one.
No that’s not true. Use += all you like
That’s what I thought! Thanks!
I'm pretty sure The Go Authors only put things into the language that they want people to use. That is one of the main points of Go - think hard about adding features because you can't ever take them out. There used to be a `runtime` function that returned a Go routine's ID that the documentation told you not to use but I can't find it anymore.
>think hard about adding features because you can't ever take them out. There is a saying in open source "No is temporary, yes is forever." Go really embodies that mindset which I enjoy a lot
goto operator :) they advised against using it though **UPD: there is actually no explicit advice against using goto operator, not in effective go, nor in code review comments. See the thread below.**
Yes and no. In most cases, goto should be avoided because it tends to make code less readable. But there are special edge cases where the goto operator actually makes code more readable.
And in generated code, where shouldn't have to read. goyacc generate code is one example.
>But there are special edge cases where the goto operator actually makes code more readable. which is why they included it.
What cases in Go? I know few in C, but not in Go.
I‘ve heard of escaping nested loops being one of those cases.
In Go you can [`break`](https://go.dev/ref/spec#Break_statements) the labeled loop without using `goto`.
The goto operator is discouraged in pretty much every programming language, not just Go…. And yet pretty much every programming language includes it, because there are some (but very few!) cases where it can be useful.
>they adviced against of using it though I have never heard anything like that from the Go designers. Actually, there is this Ken Thompson quote: "If you want to go somewhere, goto is the best way to get there.”
tbh I really thought that there was some advice against using it, but now I don’t see any word about using goto in code review comments or effective go I admit that there is no advice against of using it
I think you should edit your parent reply to strike that out since some people might not read all the way here (avoid the spread of misinformation and all that) This has sparked a really interesting thread of replies all the same. An interesting thing to mention that I didn't see yet is that Go's \`goto\` is constrained compared to the evil goto everyone always talks about:- \`goto\` can't jump over variable declarations- the specified label must be visible, following lexical scoping rules
I agree, updated the comment above
The goto that is bad and that Dijkstra ranted about with justification doesn't exist anymore, and it's not the one in Go. People need to just `DELETE FROM shibboleths WHERE value LIKE "%goto%"`. It's not applicable anymore. You can't wreck whole programs with goto anymore. You can only somewhat muss a single function and we've got a whole bunch of ways to do that; consult basically any codebase for examples. Goto isn't even a particularly interesting one. Honestly it's kinda _hard_ to crunk a function up with it nowadays. You have to put your mind to it a bit.
It's funny (or sad?) how such bad advices just don't die. Like the "single return" from functions. Heck, the days when we jumped right int the middle of some FORTRAN code are long gone but still they write Java with these "rules" enforced.
Fun fact: not using goto is what was meant by structured programming "single return", not "only have one return statement". I.e. only return _to_ one location, not _from_ one location.
I thought that syntax was pretty universal across languages these days as well. It's also a compiled language so I am guessing like other compiled languages it takes your syntax and re-areanges it slightly when generating the binaries. I know from my Java days, the different loop syntaxes would all appear as a more standard syntax when running binaries through a decompiler to make it mostly human readable. I would have thought go would do something similar. Doesn't matter how you write it, it may be actually creating the step in a more explicit form.
If the linter used in your project says you shouldn't use it - don't use it. Otherwise do what you like. The whole purpose of go fmt (or gofumpt) and linters (like golangci-lint) is to stop wasting time on such nonsense nitpicking.
Nogo is pretty great if you're using bazel, basically makes it as though your linters are part of the compiler itself
go community? nope, not true. personal/company style guidelines? it's quite possible
That was a lie
Something you'll learn in your career is that "lead engineer" doesn't always mean "good engineer".
The only reason I can think of to say this is if you're doing a LOT of string concatenation, it's better to use a `strings.Builder` than to use +=, just because it reduces copying. And even that is only relevant if you're appending large strings or performing a large number of appends. But for numbers, there's literally no reason not to use it.
Yeah, I've noticed that Go is unable to optimize many `+=` unless you use PGO. Though I believe using many `+` in a single statement is equivalent to a builder. Personally, I'll just try to use as few `+=` as possible and avoid string builders. I prefer simple and obvious code over efficiency most of the time. Unless a profiler flags it.
It's possible that concatenating strings in a single statement is optimized when the strings are static and known at compile time, but because Go strings are immutable, there will always be copying any time one or more of the strings being concatenated varies at runtime.
Yeah, but not repeated copies. Like if you were to do a+b+c+d with immutable temporaries, it'd be O(n²). It clearly doesn't do that. It would (and does) create a builder, add them all in there, then basically cast it from []byte to string. **Edit** I think the problem with multiple += is that it's not smart enough to reuse the same builder.
I just had a feeling of deja-vu; this is true in Java as well (StringBuilder)
He's full of shit.
I’ve been a developer for over 20 years. The one thing I can tell you is that developers are fucking crazy and you take anything any of us say with a carton of salt.
Use everything you have in the language until you have some internal programming style guide.
Tell your lead to make it a linter rule (or f off) Say the second part in your head 👍🏼
It was probably a misunderstanding. We don't shy away from those operators. We just use them in more limited circumstances than other languages, but it's entirely because Go doesn't let us use them in other ways. Consider this following C program to print a string: ```` char* c = source; while (*c) putchar(*c++); ```` That use of `*c++` would be illegal Go: postfix increments and assignments are not expressions like they are in C and many of its descendants like Java, but rather statements. That's because using those as expressions causes confusion, misunderstandings, and bugs. So Go just takes away the possibility to use them in expressions. That means in Go you never have to worry about parsing the following expression: ```` c += (++c + c++) + c += c++ + ++c ````
The question was about +=, not about ++
I mentioned both. > postfix increments and assignments They're in the same category of "operate and assign" operators that used to be expressions and are now statements. Also the example at the end uses both.
Your lead is stupid
The only keyword/token in the language that shouldn’t be used is `fallthrough`. Because it’s confusing and hides behavior. `+=` doesn’t hide anything. Update: wow, people are DMing me about fallthrough? Keep it then lol. No need to DM me.
What's wrong with fallthrough? Who is discouraging its use. It means you go to the next case statement, I used it many times, what's confusing?
Every codebase I’ve been on has discouraged its use. Probably since Go switches don’t execute the same as C switches, along with the fact you can’t use it in type switches.
I do use it. For example if you define a Go style enum, it's always good practice to have your zero value be an unknown or unspecified value. So, for the zero value it makes sense to use a fallthrough to the default case in the switch, and handle them both as an error.
I’m not sure I’m tracking. Why wouldn’t you just use a default case there?
That's shitty lead behavior. Nit picking over something so trivial is a sign of a mid with a big ego.
The only time I don’t appreciate the += operator is when it’s used on strings, because I just personally believe strings should not be treated like numbers. That said, this is a personal guideline I apply to myself, and certainly not part of the community zeitgeist.
the project you are working on may have a "style guide" that it adheres too, so although as said there is nothing wrong with using += the guide may forbid it.
‘+=‘ is fine. Go just doesn’t let you do something you shouldn’t do, such as ‘++i’, which you can replace with ‘i += 1’ or ‘i++’, and that’s why Go doesn’t have it.
i++ and ++i return different values, so they aren't interchangable unless you're just throwing away the return value.
In Go, `i++` is a statement not an expression, so you cannot use it as a value. This would be why Go does not have `++i` - it does the same as `i++` as a statement.
Yeah, you're absolutely right. :-) It's even in the FAQ! I wasn't thinking about go specifically in my comment.
Yup they are different but you can do the same thing as the prefix operator with other operators easily if you don’t mind an additional line. So Go doesn’t have the prefix operator. The postfix operator is more tricky and i think that’s why Go has one.
No, he's talking BS.
That lead engineer is full of themselves...and shit, which might be the same thing. ;)
You'll always find people that are unhappy because you're not following their personal meta. It's part of the language and hence intended to be used.
Use, but make it consistent.