4 ms·
Go-internals: Chapter 2, “Interfaces” released
- paraboul 8y agoReally nice write up. I wish more microbenchmarks go that deep into IR/codegen analysis (somewhat related : https://mrale.ph/blog/2014/02/23/the-black-cat-of-microbenchmarks.html https://mrale.ph/blog/2014/02/23/the-black-cat-of-microbench...).
- sAbakumoff 8y agoto me it seems like the version of "you don't know JS" but for Golang. nicely done!
- timtosi 8y agoLooking forward to read the GC chapter.
- pansinghkoder 8y agoLove the writeup! Very readable for someone like me who works much layers up in programming. I have also written a primer on go-concurrency. https://gist.github.com/rushilgupta/228dfdf379121cb9426d5e90d34c5b96 https://gist.github.com/rushilgupta/228dfdf379121cb9426d5e90... Thoughts?
- kierkeGuard 8y agoGreat writeup, really happy to see closer looks at Golang. I've worked with Go a few times, but I've thought that getting good independent looks/great examples is a bit too difficult. Thanks!
- 0xdeadbeefbabe 8y agoWhat does //go:noinline mean in this context?
- axaxs 8y agogo has certain quasi hidden directives for the compiler. This one means "don't inline the following function."
- jnordwick 8y agoGo assembly is more of a low-level intermediate representation. It isn't as high level as LLVM-IR, but it isn't what the processor runs on. I wonder how much is obfuscated by this, especially when compiled with optimizations? Is there really much to be learned by analyzing performance in unoptimized pseudo-assembly? It's like looking at JVM bytecode for performance indicators.
- ivoras 8y agoIt surprised me how go's interfaces have non-trivial limitations. What lately bit me is illustrated in the following snippet: the call to doSomething() is just not possible in Go: package main import "fmt" type S struct { i int } func (s *S) foo() { s.i++ fmt.Println(s.i) } type Sarr []S type I interface { foo() } func doSomething(arg []I) { arg[0].foo() } func main() { arr := Sarr{S{i: 1}, S{i: 2}, S{i: 3}} arr[1].foo() doSomething(arr) } I understand why the current implementation of Go doesn't work that way, and that the meta-reason for this not being implemented is the "we don't want generics" attitude, since it would effectively require 2 different compilations of doSomething(), one which accepts a slice of interfaces, which are a (pointer,type) tuple, and one which accepts an slice of this specific struct which happens to actually implement the I interface, and that's a taboo, but come on... it just weakens the idea of interfaces. It could have been done as a compile-time work-around which constructs the slice-of-interfaces argument on-the-fly before calling the function - it wouldn't have been the only magical thing in Go.
- leaveyou 8y ago>It could have been done as a compile-time work-around which constructs the slice-of-interfaces argument on-the-fly before calling the function - it wouldn't have been the only magical thing in Go. Is there a language that works the way you describe ?
- girvo 8y agoNot quite, but I believe Nim works similarly. But it also has generics, and it’s function dispatch resolution is neat, so it’s not quite apples-to-apples
- perfmode 8y agoThe reason this doesn’t work is because conversions of this nature may require allocations, and like C++, Go doesn’t want to hide costly operations from the author.