Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oh look, Google is shipping their org chart again.

  > What problems are Editions solving?
  >
  > In short, nothing really (for end users). The introduction of Editions
  > is the result of major Google-internal refactoring of how protoc and its
  > plugin architecture implements and observes feature checks when generating
  > code. This isn’t intended to force breaking changes to existing projects,
  > nor is it designed to impact any of the existing encodings.
  > 
  > It should be a boring change that gives plugin maintainers finer-grained
  > control over how future versions of their Protobuf runtimes behave,
  > improvements are made, and new features are introduced. Having said that,
  > it’s impossible to ignore the explosion of verbosity that Editions has
  > introduced to the project as a side-effect of this level of available control.
According to Google themselves, this change "solves no user problems" and introduces "an explosion of verbosity."


This blog post wasn’t written by Google themselves, but by Buf, a confusingly-named startup that makes their own protobuf implementation.


As a sibling has already pointed out, this blog post has nothing to do with “Google themselves”. In addition, “nothing really for end users” is obviously bullshit and inconsistent with what the post says itself, e.g.

> This means your existing proto3 projects can now use default field values and extensions.

proto3 not having required and default values was a big source of complaints, so supporting these indefinitely into the future with feature flags instead of having to be stuck forever on proto2 has to be a welcome change for a subset of users, at the very least.


Proto3 already got the required/optional feature added. I don't see why they couldn't have added default values too. (Personally I liked proto3 without optionals, defaults, extensions, etc, but it was a tough sell for people already used to proto2.)


They can, and feature flags is one flexible (if somewhat verbose) way to do it.


I don't understand why this is a problem. It's not uncommon to see multi-decade old systems refactored for extensibility and maintainability every once in a while. What worked when it was initially designed won't work forever, and it's hard to make users lives better if the maintainers can't make their own lives better.

(BTW, this isn't "shipping their org chart.")


I thought Conway's law was fairly prolific.

Though, the closer it is to a true a "law", then the closer GP's comment approaches a tautology.

https://wikipedia.org/wiki/Conway%27s_law


Did it ever work? I remember having to write some pretty gnarly hacks to work around the broken Python code protoc would barf out. Working outside of Go and perhaps Java/Kotlin I've little faith that they're not going to break things further.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: