some fascinating examples of backwards-compatibility challenges at the scale of a language like Go. as one example: obligatory relevant xkcd
some fascinating examples of backwards-compatibility challenges at the scale of a language like Go.
as one example:
Go 1.13 added support for underscores in large numbers for readability. Along with the language change, we made strconv.ParseInt accept the new syntax. This change didn’t break anything inside Google, but much later we heard from an external user whose code did break. Their program used numbers separated by underscores as a data format. It tried ParseInt first and only fell back to checking for underscores if ParseInt failed. When ParseInt stopped failing, the underscore-handling code stopped running.
Yes, when I was at Google this was known as Hyrum's law. Sometimes adding random variation can help make sure nobody depends on specific behavior. One example: the order in which for loops iterate...
Yes, when I was at Google this was known as Hyrum's law.
Sometimes adding random variation can help make sure nobody depends on specific behavior. One example: the order in which for loops iterate over maps in Go is randomized to ensure that the hashing algorithm used for maps can be changed. (They learned from issues Java had with upgrades.)
This technique can also be used to prevent protocol ossification. If there's a field reserved for future use that nobody should be reading, make sure it varies.
The QUIC protocol was intentionally designed using these principles.
A language which is expressive and orthogonal and admits growth can afford to be smaller up-front and therefore have fewer compatibility commitments to make and later regret. Go, being designed in...
A language which is expressive and orthogonal and admits growth can afford to be smaller up-front and therefore have fewer compatibility commitments to make and later regret. Go, being designed in flagrant opposition to these principals, will obligatorily have more trouble with compatibility. The tradeoffs of expressiveness are well known and have been studied formally; but go strikes a very sour spot.
That said, it has a couple of saving graces, which may prevent it from running into really serious trouble on the compatibility front:
Under the broader design constraints, a good number of the specific design choices seem to have been made in reasonably good taste.
It has a fairly narrow target use case (insert rob pike copypasta).
It was designed in a period of relative stagnation of hardware. (For example, compare with java, which got a concurrency model before we really started to figure out what the constraints on the design space are, and so needed to replace its concurrency model with another, which still has some issues.)
There is an interesting discussion on lobste.rs on this. Both on how a language with such promise will evolve and whether they are actually keeping that promise.
There is an interesting discussion on lobste.rs on this. Both on how a language with such promise will evolve and whether they are actually keeping that promise.
Jesus, I used to use lobste.rs and I kind of forgot how much of a colosseum it is in there. Now that I see all the people yelling at each other in that thread, I do remember a period of a few...
Jesus, I used to use lobste.rs and I kind of forgot how much of a colosseum it is in there. Now that I see all the people yelling at each other in that thread, I do remember a period of a few years where any mention of Go anywhere in any thread on the entire website would lead to whatever thread it was in becoming a massive Go vs. Rust brawl for no reason. Just goes to show that making your site invite only doesn't necessarily create what Tildes has absent moderation and a community that is interested in keeping that kind of stuff in check.
some fascinating examples of backwards-compatibility challenges at the scale of a language like Go.
as one example:
obligatory relevant xkcd
Yes, when I was at Google this was known as Hyrum's law.
Sometimes adding random variation can help make sure nobody depends on specific behavior. One example: the order in which for loops iterate over maps in Go is randomized to ensure that the hashing algorithm used for maps can be changed. (They learned from issues Java had with upgrades.)
This technique can also be used to prevent protocol ossification. If there's a field reserved for future use that nobody should be reading, make sure it varies.
The QUIC protocol was intentionally designed using these principles.
A language which is expressive and orthogonal and admits growth can afford to be smaller up-front and therefore have fewer compatibility commitments to make and later regret. Go, being designed in flagrant opposition to these principals, will obligatorily have more trouble with compatibility. The tradeoffs of expressiveness are well known and have been studied formally; but go strikes a very sour spot.
That said, it has a couple of saving graces, which may prevent it from running into really serious trouble on the compatibility front:
Under the broader design constraints, a good number of the specific design choices seem to have been made in reasonably good taste.
It has a fairly narrow target use case (insert rob pike copypasta).
It was designed in a period of relative stagnation of hardware. (For example, compare with java, which got a concurrency model before we really started to figure out what the constraints on the design space are, and so needed to replace its concurrency model with another, which still has some issues.)
There is an interesting discussion on lobste.rs on this. Both on how a language with such promise will evolve and whether they are actually keeping that promise.
Jesus, I used to use lobste.rs and I kind of forgot how much of a colosseum it is in there. Now that I see all the people yelling at each other in that thread, I do remember a period of a few years where any mention of Go anywhere in any thread on the entire website would lead to whatever thread it was in becoming a massive Go vs. Rust brawl for no reason. Just goes to show that making your site invite only doesn't necessarily create what Tildes has absent moderation and a community that is interested in keeping that kind of stuff in check.