|
|
|
|
|
by shiloa
4328 days ago
|
|
Very cool - solid library all the way. As an aside, I keep hoping Google (or others) open sources a bunch of their internal Go libraries; I'm just gussing here, but surely they've built a bunch of tools outside the standard library to match scientific, numeric and utility libraries found in other languages (scipy, numpy, PIL, etc)? Based on its rumored wide adoption and extensive use inside the company, it sure makes sense they've extended the core to suit their irregular needs. Can anyone who's worked/works with Go at Google shed some light on this? Just curious. |
|
IE The GC thread I linked in another comment [1] makes it pretty clear that they may actually break the ability to easily call existing scientific libraries (ie by handing a pointer to a go []float64 to cgo) in favor of better real-time guarantees.
[1] https://groups.google.com/forum/#!topic/golang-dev/pIuOcqAlv...