4 ms·

I'm in a similar boat. I've tried Go, and partially agree with your sentiment that the ease of use justifies usage of it in any team. Even with its flaws, it's

I'm in a similar boat. I've tried Go, and partially agree with your sentiment that the ease of use justifies usage of it in any team. Even with its flaws, it's a tempting feature. But I'm not sure if bringing -anything- into an existing stack should be done lightly though since someone has to maintain whatever is brought in. Even if the ramp up time is shorter than usual. For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? I say this as someone who has never really ran into issues with Python performance, but am looking towards learning Rust once it hits 1.0 for writing my first non-Python library because if I can find something CPU intensive enough, I can justify deep diving on Rust. Doesn't mean I won't ever run into performance issues, but even Rust may not be necessary (for me), with PyPy/Pyston around. Go itself is more a replacement for other tech, rather than complimentary, which in my view is the biggest drawback not on your list. I like things with big ecosystems that work well together so you're not stuck on an island, and the Python/C(++)/Rust world has great interop. Unless you're a true Go diehard about the language for whatever reasons, this isn't really what I think many like myself are looking for. I see more value in simply adopting another implementation of a shop's existing platform, if you have so many options at least. I'll be really interested to hear responses to this, as I don't feel interop with Go has been discussed often. Seems people who really like Go are either 'all in' or not at all, figuratively and literally.

unoti 12y ago
> For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? Two big things here, for my applications. 1. Memory. You mention CPU use, but memory use is even more critical for what I do. For game servers, for example, lower memory usage for an application can change the multipliers on how many users I can handle per server. This can make a dramatic (like 20x) difference in what you can offer users for free vs charging. 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.
- arthurtw 12y ago
  > 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time. Correct. When comparing a static programming language to a dynamic one such as Go vs Python, this is a critical difference. It impacts system stability (production outage rate) and code maintainability a lot, the two characteristics a long-running product desperately needs. But Go is not comparable to C. Go is garbage-collected, so unlike Rust, it is not a true system programming language (i.e. not low-level enough). On the other hand, it is not high-level enough. It lacks many advanced language constructs, and its type system is rather limited. Simplicity is a big merit of Go, but it's too limited IMO. Go solves many software development problems for large engineering teams, so I think its ecosystem will keep growing for a while.

unoti 12y ago

> For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? Two big things here, for my applications. 1. Memory. You mention CPU use, but memory use is even more critical for what I do. For game servers, for example, lower memory usage for an application can change the multipliers on how many users I can handle per server. This can make a dramatic (like 20x) difference in what you can offer users for free vs charging. 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.

arthurtw 12y ago
> 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time. Correct. When comparing a static programming language to a dynamic one such as Go vs Python, this is a critical difference. It impacts system stability (production outage rate) and code maintainability a lot, the two characteristics a long-running product desperately needs. But Go is not comparable to C. Go is garbage-collected, so unlike Rust, it is not a true system programming language (i.e. not low-level enough). On the other hand, it is not high-level enough. It lacks many advanced language constructs, and its type system is rather limited. Simplicity is a big merit of Go, but it's too limited IMO. Go solves many software development problems for large engineering teams, so I think its ecosystem will keep growing for a while.