The graphs are broken in Safari, so I looked in Chrome, but I'm not sure I understand what this means? Go is a bit slower than Java and C++ for grpc calls? Is this a significant problem?
Good talk about writing code which is platform-dependent. Hopefully in most apps this won't be relevant as they can just use go abstractions in packages like os or filepath, but sometimes it's necessary.
Feels a bit frustrating that they're so vague about plans for Go 2, but I guess they just don't know yet what they want to include, and are trying to get an idea of what needs to be fixed. Looking back at my experience of Go the most important thing for me is that it's stable and the go1 promise, so I hope there will be a go2 promise and that go2 will concentrate on making sure the transition is painless by rewriting go1 projects seamlessly to use go2 idioms. Introducing generics would of course make that far more difficult, will be interesting to see what they come up with.
Good video - I've been guilty of at least one of these problems and he really steps through the examples in detail. As usual with security the devil is in the details, and defaults.
Lots of good material here - this is probably more in depth than is required for a beginner programmer (IMO), and Go does a good job of hiding the complexity most of the time, but it is useful to understand this stuff if you're using pointers. I do think you can write consistent and readable code in Go without understanding the behaviour language to this level of detail though as long as you grasp what a pointer is (a reference not a value).
Really not convinced that stars are a good metric for judging web frameworks. Looking at this list they're almost inversely correlated with quality.
I know it's about generics, but this does show a real-world problem caused by their lack (to do with writing orms).
The graphs are broken in Safari, so I looked in Chrome, but I'm not sure I understand what this means? Go is a bit slower than Java and C++ for grpc calls? Is this a significant problem?
Good talk about writing code which is platform-dependent. Hopefully in most apps this won't be relevant as they can just use go abstractions in packages like os or filepath, but sometimes it's necessary.
Feels a bit frustrating that they're so vague about plans for Go 2, but I guess they just don't know yet what they want to include, and are trying to get an idea of what needs to be fixed. Looking back at my experience of Go the most important thing for me is that it's stable and the go1 promise, so I hope there will be a go2 promise and that go2 will concentrate on making sure the transition is painless by rewriting go1 projects seamlessly to use go2 idioms. Introducing generics would of course make that far more difficult, will be interesting to see what they come up with.
Good video - I've been guilty of at least one of these problems and he really steps through the examples in detail. As usual with security the devil is in the details, and defaults.
Lots of good material here - this is probably more in depth than is required for a beginner programmer (IMO), and Go does a good job of hiding the complexity most of the time, but it is useful to understand this stuff if you're using pointers. I do think you can write consistent and readable code in Go without understanding the behaviour language to this level of detail though as long as you grasp what a pointer is (a reference not a value).