5 ms·

He lists many things he likes and very few he dislikes, but the last sentence is: > For big and longstanding projects, I do believe Go is bad because if you wa

He lists many things he likes and very few he dislikes, but the last sentence is: > For big and longstanding projects, I do believe Go is bad because if you want to do something complex, Go won’t let you do this anyhow. Without a proper explanation how he got to this strong conclusion. And especially with so many cloud infrastructure projects being written in Go (Docker, Kubernetes, Terraform, Consul, etcd, CockroachDB, Nebula, ...), it seems to be in contrast to the common perception, thus requiring a proper explanation even more.

BossingAround 7y ago
> Without a proper explanation how he got to this strong conclusion. Seems like the author would say the same about any other language that's not Assembler, C, or C++.
bborud 7y ago
This interested me as well. In particular since we have developed quite a few medium sized projects in Go (20.000-50.000 LOC) and, in my experience, it is more pleasant than, say, doing it in Java or C++. In my experience, with both C++ and Java there is always a discussion of style, frameworks and practices. Especially in C++ those choices have big consequences since C++ isn't just one language: it is every snapshot of the language for the last 20 years. If your project requires the use of a library, your code has to adapt to choices made for that library. Java has different problems. Higher level problems. It isn't so much about which features aren't available/usable/advisable, but about what framework you use. Most people don't really work in Java, they work in various Java frameworks. And some frameworks are like herpes of programming: if you start using them in a project, you can never get rid of them. At least not at reasonable cost. (Actually it is much worse than that, but let's save that for another time). The barriers of entry tend to be higher when so many parameters have to be figured out and adapted to in a software project. Go appears to have fewer such barriers. I haven't done any large projects (200kLOC+) in Go yet, but I don't quite see how C++ would make large projects much easier. C++ itself is hard. It takes years to learn. Add to that the complexity in having to decide what subset of it to use and what C++ culture to adopt, and you might have to compromise on comfort from day one. Skip this discussion, and there's trouble further down the road.
bsaul 7y ago
I agree and in fact i think this sentence is a self-contradiction in some way : If you want a "big longstanding" project, then doing "complex" thing is probably the thing you want to avoid at all cost. And as a proof that it's possible, one can have a look at the standard library, which is big, longstanding and is the most readable std lib i've ever seen.
- weff_ 7y ago
  So when is it appropriate to do complex things?
  - sfifs 7y ago
    HPC where you try to wring the last ounce of performance from machines insufficiently powerful for the task. Weather forecasting, weapons simulation, protein folding...
    - weff_ 7y ago
      That's interesting. I don't think as optimized memory manipulation via convoluted casting and such as "complex stuff". I think of that as optimization. I thought what the author meant by complex was a gigantic system that needs to use many design patterns for good reasons; the code models a very complex, convoluted domain.
  - bsaul 7y ago
    When you prototype. But once it reaches production, you should hopefuly have managed to reduce the complexity to its bare minimum
lazyant 7y ago
Yes the comment is "funny" since from what I understand, Google wanted a relatively simple language that a lot of people could use in large projects.

BossingAround 7y ago

> Without a proper explanation how he got to this strong conclusion. Seems like the author would say the same about any other language that's not Assembler, C, or C++.

bborud 7y ago

This interested me as well. In particular since we have developed quite a few medium sized projects in Go (20.000-50.000 LOC) and, in my experience, it is more pleasant than, say, doing it in Java or C++. In my experience, with both C++ and Java there is always a discussion of style, frameworks and practices. Especially in C++ those choices have big consequences since C++ isn't just one language: it is every snapshot of the language for the last 20 years. If your project requires the use of a library, your code has to adapt to choices made for that library. Java has different problems. Higher level problems. It isn't so much about which features aren't available/usable/advisable, but about what framework you use. Most people don't really work in Java, they work in various Java frameworks. And some frameworks are like herpes of programming: if you start using them in a project, you can never get rid of them. At least not at reasonable cost. (Actually it is much worse than that, but let's save that for another time). The barriers of entry tend to be higher when so many parameters have to be figured out and adapted to in a software project. Go appears to have fewer such barriers. I haven't done any large projects (200kLOC+) in Go yet, but I don't quite see how C++ would make large projects much easier. C++ itself is hard. It takes years to learn. Add to that the complexity in having to decide what subset of it to use and what C++ culture to adopt, and you might have to compromise on comfort from day one. Skip this discussion, and there's trouble further down the road.

bsaul 7y ago

I agree and in fact i think this sentence is a self-contradiction in some way : If you want a "big longstanding" project, then doing "complex" thing is probably the thing you want to avoid at all cost. And as a proof that it's possible, one can have a look at the standard library, which is big, longstanding and is the most readable std lib i've ever seen.

weff_ 7y ago
So when is it appropriate to do complex things?
- sfifs 7y ago
  HPC where you try to wring the last ounce of performance from machines insufficiently powerful for the task. Weather forecasting, weapons simulation, protein folding...
  - weff_ 7y ago
    That's interesting. I don't think as optimized memory manipulation via convoluted casting and such as "complex stuff". I think of that as optimization. I thought what the author meant by complex was a gigantic system that needs to use many design patterns for good reasons; the code models a very complex, convoluted domain.
- bsaul 7y ago
  When you prototype. But once it reaches production, you should hopefuly have managed to reduce the complexity to its bare minimum

lazyant 7y ago

Yes the comment is "funny" since from what I understand, Google wanted a relatively simple language that a lot of people could use in large projects.