If any of you haven't seen, the fireside chat is up https://www.youtube.com/watch?v=p9VUCp98ay4 . Here are some thoughts I had while watching it
It was commented that profiling tools are very good, which helped bring speed increases: Except for OSX, at least the last time I tried. Is there a chance that this will be fixed anytime soon?
Dependency management: I know this issue has been making the rounds for a while, and I agree with the Go team that people should be aware what they're doing when they use go get. That said, I know what I'm getting into when I download "some random person's github", but I'm not sure what the best practices are with it. A lot of the code I write is for my own uses, as opposed to for production, but at the same time, sometimes I do like to give code to collaborators. Not having a version control specification has positives, one of which is that it makes it easy to gain features and performance from the github package as it is worked on. On the other hand, if the github writer isn't as particular about backward compatibility as I thought, the github code might change in a backward incompatible way. If I'm not continually updating my local copy, I might not realize this change. I am hoping to get advice on best practices in dealing with these issues.
What would you take out?
Ampersand a struct: This feels so natural to me. What else would you do?
The number of ways to declare a variable is too high: What would you take out? I can see that new and struct literals are highly overlapping.
Colon equals for overwrite: Totally agreed. I avoid overwriting variable names. However, could someone point me to a use case where it's well done? I'd be interested in seeing the positive use cases.
Named result parameters: Please keep these in. They are really useful in remembering the order of outputs when you're returning several things. func(input) (float64, float64) is less clear than func(input) (sum float64, prod float64)
Variable reused in a for loop being confusing, especially for closures: I'm not sure what this means. Could you give an example of a proper and improper closure with it?
Facilitating concurrency across network: I agree, though I personally would like to see a focus on cluster / supercomputer stuff (I realize that I'm in the minority with that), though I imagine there is significant overlap between the two . It would be awesome if it could be nearly as easy as shared memory. Go circuit kind of looks like it, though I haven't had a chance to really play with it to see if that's true.
Lots of speedups from developments to the runtime and scheduler, and a lot more to come: What kinds of things should we expect to see? Any idea on how much more performance that will bring? Another blanket 40%? Just improvements for multi-core? As I begin to push Go, one of the questions I will get is about the computation speed, and in my world, that's mostly number crunching. Will I have to say "It's not quite as fast as C/C++, but it's way better for safety, compile time, ease of coding, GC, etc.", or will I be able to say "It's as fast as C++ and it's way better, etc."
Source transformation tools: There are some specific packages that involve re-writting source code would be very useful, and were such tools to exist well in Go it would make selling the language easier for me. If I wanted to learn how to write these packages, is reading the go fmt source the best way to learn how to do source transformation, or are there better ways?
Writing the go compiler/runtime in go: A good reason is that all of us here write Go. If the compiler and runtime are written in Go it becomes a lot easier for the community to read and understand what's going on. It would also make it easier for the community to submit patches and improvements (not sure how much that would actually happen).
Our go compiler is better than the C compiler: Did that mean that there is a go compiler written in Go that the team has, or just that compiling Go code is better than compiling C code?
Thanks for the discussion time.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out