You basically miss a by-reference foreach from C++, which is imo a great thing and a common pitfall in Go (people tend to expect e to be sort of a const reference). It’s been discussed a lot already. IIRC, guys from Go team (=Pike & Co.) found it weird and decided that this thing should not be added to the language. I don’t agree with that though.
Also, correct me if I am wrong, but I’ve got a funky feeling that go compiler has optimizations against excessive copying in for-range.
“C” flavor static variables ie variables that are declared inside a function but persist across function calls. I end up making a bunch of global variables that just clutter the program. 
If you want an equivalent to static variables you’re looking for closures. But if this is a systemic problem for you I’d argue that you probably need to rethink how your code is organized.
closures constitute a complicated solution to a simple problem. They still end up being global scope and thus create the same amount of clutter as a simple variable. Sometimes the problem is as simple as counting the number of times a function is called, or resetting some local state after the function has been called ‘n’ times. A pretty-printer that counts lines is a simple example. You want to reset the linecount every 55 lines for example. Sure there are other ways to do it, but a static variable solved it pretty well in C. And I miss that simplicity.
Static variables are just global variables with hidden names. That means they have many of the same problems as globals, such as two different places unintentionally using the same state, or even worse: concurrent modification resulting in data races. Closures can give you the same benefits without those problems.
A counter for example: https://play.golang.org/p/nOkda9OW7P
A line pretty printer for example: https://play.golang.org/p/0SF0iIIsEW
This solves the same thing as static variables with only a couple extra lines of code, while avoiding all the pitfalls. And if you really, really, want global static variables, you can do that too: https://play.golang.org/p/kNY2iTNynf
after i reading this topic i understood that __attribute__ (( packed)) are missing. basically is not big deal but if someone want to write a kernel can be a big problem.
From everything I’ve read, Go really isn’t a kernel language anyway.
Your email client may not be compatible with Discourse.
Your email client may not be compatible with Discourse.
Thanks Dave, that would be sad/amusing. I’m using GMail “reply.” I suspect it’s because I use a custom email address for this forum, and Discourse doesn’t know my replies are “me.”
Anyway my original reply was supposed to read:
You might want to poke around a bit and keep reading then, I’ve read a number of discussions describing how to use Go for kernel development. It’s a lively subject and I don’t think there’s any consensus that Go is inappropriate for kernel development.
To add to that, I’d refer to this thread on golang-nuts:
https://groups.google.com/forum/#!topic/golang-nuts/wEUiS4UyiKs
I understand where you are coming from, because it is more of a cleanly code thing than a hard implementation detail. I have to say that static variables appear to be harder to locate simply by scrolling through the code. Globals clutter. Pick and choose your evil.
The bright thing about globals is that they are normally all declared at the top or the bottom (unless they are in another file in the same package 
– harder to locate if the files are not named adequately).
As long as we don’t adopt implicit parameters from Scala, I’m happy. IMHO this is a debugging nightmare.
yep, basically is not but we can admit that golang is a generally purpose language and maybe someone can start a kernel project at a moment… but also can be certain situations where a packed structure is necessary (e.g. in microcontrollers programming).
I’d like a standard lib math for float32
+1 for official GUI toolkit.
I miss the ternary operator, but I’m getting over it.
I often wish errors were more than just values. Much of the time, perhaps most of the time, I want to capture the stack trace alongside the error. This is the aspect of exceptions that I miss from other languages, not the control flow.
I can understand why the designers decided not to do this – it’s expensive performance-wise, you definitely wouldn’t want to attach it to io.EOF for instance – but I still find myself wishing I had it when debugging. The third party error packages that can do this for you are helpful, but it’s just not as useful as having it be a core part of the language would be.
Did you ever try putting the result of debug.Stack in the errors? Maybe only in a dev environment controlled via an env flag or something. I haven’t tried this out myself - just a quick idea I had reading your post.
I would encourage you to look at how cockroachdb handles errors, specifically the error utility they use:
https://github.com/cockroachdb/cockroach/blob/master/util/error.go#L38
Yes, that works only for your own code, though, and not errors generated by others.