3 ms·

I use go (long term) in places where I need as part of my DR plan the ability to fix stuff without expert access. The toolchain is simple enough that I can main

by raggi 6y ago

I use go (long term) in places where I need as part of my DR plan the ability to fix stuff without expert access. The toolchain is simple enough that I can maintain it in this scenario alone, and meanwhile the stdlib is complete enough as to be useful for solving a multitude of problems, while offering the ability to produce programs that run on many systems and integrate with them with sufficient efficiency. It's a really usable systems glue language, and it powers chunks of my telco infrastructure. This pro is mostly about the implementation/engineering design. My biggest gripe with the language is that it doesn't scale that well for teams. It requires a certain culture & approach to produce maintainable programs that goes against the grain for many developers, and while I enjoy the simplicity it offers, that simplicity leads to cost of ownership problems in many team scenarios. This con is mostly about the language. As a specific tactical item, the runtime multiplexer could do with a refactor. The merging of the pollers essentially could continue until it is much cleaner, there are more layers there than necessary to solve the problem. You can follow the FD close path to understand the strains of the current factoring. Such a cleanup could probably remove some overhead for io heavy workloads too, maybe even drop some lock contention. Oh, and the spins should all be removed from the runtime before we really start using it on very high core count systems. This opportunity is mostly a side effect of a long history of incremental improvement.

bborud 6y ago
Could you elaborate on why you think it doesn't scale well for teams?
- InvOfSmallC 6y ago
  Imho because it is highly opinionated and the designers of the language also suggests best practices. They don’t do anything wrong in suggesting best practices although some of those best practices only work when you write infrastructure code and not micro services (with business logic) and some programmers cannot really compute that and they stick with the religion. I also had the same experience of not scaling for teams for this reason, because you had people who would not allow for discussion. It is honestly never happened to me before. Given it could only be a matter of having found just a bad apple in the team, my first reaction was that this language doesn’t scale with teams.
  - bborud 6y ago
    > Imho because it is highly opinionated and the designers of the language also suggests best practices. In my experience this is actually a plus. I've lead a department that made the transition from Java to Go, and one of the really noticable things were entire classes of fruitless (and frankly, unnecessary) discussions disappeared. Having an opinionated language that comes with a canonical formatter and lots of established idioms made it easier to scale up to more people because more of the code looked homogenous more of the time. However, with any new language someone takes up there is the risk that people will try to bring along their old habits from other languages and be unhappy if they can't just continue writing C/C++/Java/Python/C#/JavaScript/Lisp in Go. If this takes hold, you will waste a lot of time having fruitless discussions. It is easier to adapt to a coding style that is shared than it is for every project and every team to invent their own. For instance, I've worked for only one company where using C++ was even somewhat pleasant: and it was in large part because a) the company had a very strictly enforced code standard for C++ (and other approved languages), and b) you had to demonstrate you could stick strictly to the code standard before you were able to approve changelists. At the time that company had some 7000 developers, of which probably 3-4000 had "C++ readability" rating. The upshot being that after getting used to it, it was pretty easy to understand other people's code. And you would spend a lot of time reading other people's code. I suspect Go being opinionated is a direct result of this experience.

by raggi 6y ago

bborud 6y ago

Could you elaborate on why you think it doesn't scale well for teams?

InvOfSmallC 6y ago
Imho because it is highly opinionated and the designers of the language also suggests best practices. They don’t do anything wrong in suggesting best practices although some of those best practices only work when you write infrastructure code and not micro services (with business logic) and some programmers cannot really compute that and they stick with the religion. I also had the same experience of not scaling for teams for this reason, because you had people who would not allow for discussion. It is honestly never happened to me before. Given it could only be a matter of having found just a bad apple in the team, my first reaction was that this language doesn’t scale with teams.
- bborud 6y ago
  > Imho because it is highly opinionated and the designers of the language also suggests best practices. In my experience this is actually a plus. I've lead a department that made the transition from Java to Go, and one of the really noticable things were entire classes of fruitless (and frankly, unnecessary) discussions disappeared. Having an opinionated language that comes with a canonical formatter and lots of established idioms made it easier to scale up to more people because more of the code looked homogenous more of the time. However, with any new language someone takes up there is the risk that people will try to bring along their old habits from other languages and be unhappy if they can't just continue writing C/C++/Java/Python/C#/JavaScript/Lisp in Go. If this takes hold, you will waste a lot of time having fruitless discussions. It is easier to adapt to a coding style that is shared than it is for every project and every team to invent their own. For instance, I've worked for only one company where using C++ was even somewhat pleasant: and it was in large part because a) the company had a very strictly enforced code standard for C++ (and other approved languages), and b) you had to demonstrate you could stick strictly to the code standard before you were able to approve changelists. At the time that company had some 7000 developers, of which probably 3-4000 had "C++ readability" rating. The upshot being that after getting used to it, it was pretty easy to understand other people's code. And you would spend a lot of time reading other people's code. I suspect Go being opinionated is a direct result of this experience.