Hacker News Reader

A big problem in large-scale systems is dependency management. One of the significant decisions that Go makes in its design is its approach to package management. Its approach isn't perfect, but is simple, making it a breath of fresh air compared to C++ or JVM-based languages... e.g. how many hours have been spent tweaking Maven or debugging discrepancies between classpaths referencing different copies of commons-logging?

Speaking of Maven - `go build` normalizes build systems so there is less time twiddling builds. It's not a silver bullet, but it's specifically intended for large systems.

Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python.

Go isn't perfect, but it's certainly designed for large-scale systems.

I agree with you that the JVM languages have better large-scale system support currently (20 years does give you something) -- but Go's goal is not dissimilar to the one Java eventually settled on after the applet craze.

Contrary to what you've seen, Go seems (to me) to be a go-to language for new companies principally concerned with distributed systems / cloud infrastructure (particularly those that once might have hired a hybrid of C and scripting language devs). One of the trends in those communities is toward microservices / SOA / etc, but the total codebases managed are certainly enterprise-scale.

All that said I have absolutely no significant opinions on Go vs Rust :) Just had to take issue with the "go is not enterprise scale" idea.

View on HN

type dataSlice []*data // Len is part of sort.Interface. func (d dataSlice) Len() int { return len(d) } // Swap is part of sort.Interface. func (d dataSlice) Swap(i, j int) { d[i], d[j] = d[j], d[i] } // Less is part of sort.Interface. We use count as the value to sort by func (d dataSlice) Less(i, j int) bool { // WRONG : will crash if there's a nil in the list ... return d[i].count < d[j].count // Correct version if d[i] == nil { return true // note : true is an exported name, with no capital ... yet another inconsistency } if d[j] == nil { return false } return d[i].count < d[j].count } func main() { // create s of type []*data sort.Sort(s) }

// Create Vector<Data> in s sort(s.begin(), s.end(), [](const Data& d1, const Data& d2) { return d1.count < d2.count; }); (bonus for the C++ version : it's behavior is defined and correct for nulls, just saying this because none of the other examples are, including the Go one)