3 ms·

Experiment, Simplify, Ship

48 points by stablemap 7y ago

Sytten 7y ago
I personally think they missed one big pain point of Go: the logging. The standard logging should be an interface for structured logs that can be implemented by various vendors instead of the current really basic logger. This is especially bad for third party libraries that either force you to use one logging library (logrus, zap, etc) or built their own custom interface which you then have to implement yourself for your logger. That is something they should have stolen from Java...
- xyzzy_plugh 7y ago
  Libraries generally shouldn't depend on concrete loggers. Plumbing a logging interface throughout is a marginal improvement, but really they should provide a a structured tracing interface to let callers decide what events they care about, and how to act on that information. For example, the httptrace package provides a set of hooks you can opt in to for various http events. That being said I've only ever experienced a lot of pain when libraries use a global logger. Otherwise it's usually pretty painless to adapt one logging library to another.
frou_dh 7y ago
This was an exhausting read because Rich Hickeys "Simple Made Easy" presentation from years ago transmitted a mind-virus to me where I have to stop and have an internal conflict every time I read simpl(e|ify) in a programming context. It's notable how so many independent programming communities seem enamored with Simple being the goal, yet probably don't even agree on the definition of the term.
- xyzzy_plugh 7y ago
  From the book The Go Programming Language: > Simplicity requires more work at the beginning of a project to reduce an idea to its essence and more discipline over the lifetime of a project to distinguish good changes from bad or pernicious ones. With sufficient effort, a good change can be accommodated without compromising what Fred Brooks called the 'conceptual integrity' of the design but a bad change cannot, and a pernicious change trades simplicity for its shallow cousin, convenience. Only through simplicity of design can a system remain stable, secure, and coherent as it grows.
- vizzier 7y ago
  Is that this? https://www.youtube.com/watch?v=34_L7t7fD_U https://www.youtube.com/watch?v=34_L7t7fD_U
  - frou_dh 7y ago
    Here's the original location that has synced slides: https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
coldtea 7y ago
There's an eerily condescending tone throughout the piece. It's addressed to programmers and discusses topics like error handling and generics, but talks up trivial concepts as if they're unique, or as if the Go team has thought of them first, or something... "Experiment, simplify, ship"? Yeah, who would have thought of that! Surely other language teams never do the same... It's doubly annoying when the whole process involves trivial issues, long ago solved to satisfaction in tons of similar languages... (e.g. Optionals for error handling).
- ehnto 7y ago
  This tone has been prevalent in tech writing for years. It's like we all learned to write by listening to TED talks. When I first started coming across the tone as I was learning to be a developer, it was all really fresh and exciting. Everything was so aspirational. I try to just gloss over it now and let it be, because you never know who might be getting motivated by it like I was, and I would hate to think I ruined their excitement by being jaded about it. But it is still pretty annoying to read.
- tylerl 7y ago
  The meaning seems clear at least to me. Language revisions tend to focus on adding features or capabilities or expressiveness. Go is famously, aggressively, minimalist from an experiential point of view. What rsc is saying is that nothing is going in to Go 2 unless it noticably simplifies things, and unless the incremental addition is itself is as simple as it can get. This is definitely not the typical way languages evolve.

48 points by stablemap 7y ago

I personally think they missed one big pain point of Go: the logging. The standard logging should be an interface for structured logs that can be implemented by various vendors instead of the current really basic logger. This is especially bad for third party libraries that either force you to use one logging library (logrus, zap, etc) or built their own custom interface which you then have to implement yourself for your logger. That is something they should have stolen from Java...

xyzzy_plugh 7y ago
Libraries generally shouldn't depend on concrete loggers. Plumbing a logging interface throughout is a marginal improvement, but really they should provide a a structured tracing interface to let callers decide what events they care about, and how to act on that information. For example, the httptrace package provides a set of hooks you can opt in to for various http events. That being said I've only ever experienced a lot of pain when libraries use a global logger. Otherwise it's usually pretty painless to adapt one logging library to another.

frou_dh 7y ago

This was an exhausting read because Rich Hickeys "Simple Made Easy" presentation from years ago transmitted a mind-virus to me where I have to stop and have an internal conflict every time I read simpl(e|ify) in a programming context. It's notable how so many independent programming communities seem enamored with Simple being the goal, yet probably don't even agree on the definition of the term.

xyzzy_plugh 7y ago
From the book The Go Programming Language: > Simplicity requires more work at the beginning of a project to reduce an idea to its essence and more discipline over the lifetime of a project to distinguish good changes from bad or pernicious ones. With sufficient effort, a good change can be accommodated without compromising what Fred Brooks called the 'conceptual integrity' of the design but a bad change cannot, and a pernicious change trades simplicity for its shallow cousin, convenience. Only through simplicity of design can a system remain stable, secure, and coherent as it grows.
vizzier 7y ago
Is that this? https://www.youtube.com/watch?v=34_L7t7fD_U https://www.youtube.com/watch?v=34_L7t7fD_U
- frou_dh 7y ago
  Here's the original location that has synced slides: https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/

coldtea 7y ago

There's an eerily condescending tone throughout the piece. It's addressed to programmers and discusses topics like error handling and generics, but talks up trivial concepts as if they're unique, or as if the Go team has thought of them first, or something... "Experiment, simplify, ship"? Yeah, who would have thought of that! Surely other language teams never do the same... It's doubly annoying when the whole process involves trivial issues, long ago solved to satisfaction in tons of similar languages... (e.g. Optionals for error handling).

ehnto 7y ago
This tone has been prevalent in tech writing for years. It's like we all learned to write by listening to TED talks. When I first started coming across the tone as I was learning to be a developer, it was all really fresh and exciting. Everything was so aspirational. I try to just gloss over it now and let it be, because you never know who might be getting motivated by it like I was, and I would hate to think I ruined their excitement by being jaded about it. But it is still pretty annoying to read.
tylerl 7y ago
The meaning seems clear at least to me. Language revisions tend to focus on adding features or capabilities or expressiveness. Go is famously, aggressively, minimalist from an experiential point of view. What rsc is saying is that nothing is going in to Go 2 unless it noticably simplifies things, and unless the incremental addition is itself is as simple as it can get. This is definitely not the typical way languages evolve.