3 ms·

> But I don't think good engineers could "shine" with it. any concrete example on what a good engineer couldn't achieve when using Go in its intended domain/ro

• danpalmer 8y ago
  I've seen some amazing abstractions created in Rust and Haskell. Some of the Haskell ORMs are really nice abstractions over SQL for example, and there are many examples of Rust macros doing amazing things (I believe async/await was implemented as a macro?). Obviously you can write an ORM in Go, and you can write async code or code that will do whatever Rust macros can do, but the solutions will be less elegant, less re-usable, less useful. There's an argument to be made that this is all "clever" code, and that that is bad for maintainability. I'd agree they can be misused, but when used correctly they can level up how code is written in a very substantial way. Understanding the difference and when they are appropriate is what I really mean good engineering here.
  • skohan 8y ago
    I'm a huge proponent of boring code, but for me it's an orthogonal concept to having a lot of tools for abstractions in a language. What you actually want is to be able to write code which is as close to the problem domain as possible. Overly "clever" code is one way to get that wrong, but so is being too low-level or needing a lot of boilerplate. Having the right level of abstraction lets you write self-documenting code whose function and intent is made clear just by reading it.
    • danpalmer 8y ago
      Exactly. I’m not sure Go provides the tools. Although I could be wrong.