> Before Go, Rust, and the like arrived on the scene
I'm glad you now agree that Go and Rust have enough similarities to be grouped together in this discussion. ;)
> There may have been some glimmer of understanding of needing to interface with the system at a low level that Go is not well suited for, but "oooh shiny networking abilities"...
I mean, that's just not how Docker was developed at all. I was there (okay, maybe not at the very start but I was involved in the project when it was still very young).
The honest answer is that they didn't foresee how annoying it would be to deal with those things in Go, not that they didn't expect to have to do those things. For one thing, their internal version of Docker at dotCloud was written in Python and so they had a good idea of the kinds of things they will need to do in the rewrite. Lots of lessons were learned over the past decade, you can't just retroactively apply modern maxims like that (i.e., "well, obviously we now know that Go isn't good at X so when they started using it obviously they didn't really plan to use it for X" isn't particularly convincing, especially to people who actually lived through it).
(But none of this is particularly relevant to the original point IMHO.)
> I'm glad you now agree that Go and Rust have enough similarities to be grouped together in this discussion. ;)
I'm glad you finally got around to reading the thread. ;) They've been grouped on the same spectrum since the beginning. For example, "Go is most similar to Go, but on the spectrum is way closer to Python and Ruby than it is Rust."
> The honest answer is that they didn't foresee how annoying it would be to deal with those things in Go
I'm sure it was underestimated — developers tend to be optimistic — but certainly when the creators are explicitly telling you that it is a 'dynamically-typed' language intended for writing network services you're going to understand that you're in for a least a bit of a bumpy ride if you try use it for something that would traditionally have been written in C. No need to look back retroactively. Go was originally announced that way.
Regardless, what is curious, though, is that it wasn't recognized as annoying very quickly at the onset. This does suggest, like before, that work began in the places Go excels and once the other stuff came 'round the sunk costs starting sinking in. You were there, so feel free to tell us the whole story, but you'd think the ship would have been abandoned pretty quickly if the "hard parts" were where things started. It is not like the team didn't already give up on another language.
> (But none of this is particularly relevant to the original point IMHO.)
Or is it? I mean, if Go were just like Rust then wouldn't you say those annoying aspects of Docker wouldn't be annoying anymore? That was my read from earlier. But since Go is more like Python and Ruby...
I'm glad you now agree that Go and Rust have enough similarities to be grouped together in this discussion. ;)
> There may have been some glimmer of understanding of needing to interface with the system at a low level that Go is not well suited for, but "oooh shiny networking abilities"...
I mean, that's just not how Docker was developed at all. I was there (okay, maybe not at the very start but I was involved in the project when it was still very young).
The honest answer is that they didn't foresee how annoying it would be to deal with those things in Go, not that they didn't expect to have to do those things. For one thing, their internal version of Docker at dotCloud was written in Python and so they had a good idea of the kinds of things they will need to do in the rewrite. Lots of lessons were learned over the past decade, you can't just retroactively apply modern maxims like that (i.e., "well, obviously we now know that Go isn't good at X so when they started using it obviously they didn't really plan to use it for X" isn't particularly convincing, especially to people who actually lived through it).
(But none of this is particularly relevant to the original point IMHO.)