What do you miss in Go and its ecosystem?

Technical Discussion
41

@nodir, sure, but then you have to invent a new, special purpose syntax that is only used when the func declaration is elided. Do you see the negative implications for comprehension and readability this would bring ?

42

Yea. I just wish there was a more collaborative place. We could find out pitfalls and upsides. Godoc.org IMHO should focus on indexing documentation only. I donā€™t want to see a bunch of +1s and reviews every time I go to read the docs

43

Personally, I like brevity, but it is another concept that would need to be explained to beginners. I guess Iā€™d wonder:

@nodir

  • When should arrow syntax be encouraged / dis?
  • How could we avoid the need for team disputes and style guides? Iā€™m thinking in terms of our effective Go guide.
  • Would the scope* remain the same for an arrow function?
  • Does this encourage inline implementations of functions; instead of isolating them and referencing them in a modular fashion? Idk.

To be fair, I do think that this has become relatively standard, and most developers are able to read this.

* this is the inconsistency I see with most languages; does it include surrounding scope or only mimic a new function scope

44

Yes, different func literal syntax adds complexity indeed. Maybe we can make it look more like the existing syntax.

First, reuse func but omit types:

var f func(x int)
f = func(x) { fmt.Println(x) }

Second, if func(...) is followed up by = and an expression, treat it as a return expression

f := func(x int) int = x+1
// same as
f := func(x int) int { return x+1 }

This gives us

var f func(func(int) int)
f(func(x) = x+1)
// same as
f(func(x int) int { return x+1 })
45

AFAIK, C# and presumably Java does not have this inconsistency. Arrow function is just a shorter syntax.

1 Like
46

Very true. As long as we do not include the surrounding scope, Iā€™m fine. I think it is becoming pretty standard.

47 
var list []HugeStruct
for i, e := range list {
  //...
}

does O(size(HugeStruct) * len(list)) of memory copying. One would have to write

for i := range list {
  e := &list[i]
  //...
}

to avoid that.

Would be great if we didnā€™t have to do to that:

for i, *e := range list {
  // e === &list[i]
}

WDYT?

3 Likes
48

@nodir I actually wasnā€™t aware of that, good to know for sure :smile:

49

actually, []HugeStruct is a bad idea anyway because append would reallocate huge array each time an item doesnā€™t fit. Should use []*HugeStruct, so nvm my previous message.

50

I carried this idea for a while and eventually dropped it, regular if statements are totally fine. I wouldnā€™t even call it a ā€œwishā€, itā€™s just a random ā€œwhat if itā€™s been hereā€.

51

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.

52

ā€œ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. :frowning:

53

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.

54

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.

55

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

1 Like
56

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.

57

From everything Iā€™ve read, Go really isnā€™t a kernel language anyway.

58

On 12 October 2015 at 14:47, Jacob forum@golangbridge.org wrote:

59

Your email client may not be compatible with Discourse.

60

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