4 ms·
Heroku is a meta-adoption, not actual use. How much is it actually being used by the users of Heroku? The other two examples are companies I've never heard of.
by krig 15y ago
Heroku is a meta-adoption, not actual use. How much is it actually being used by the users of Heroku? The other two examples are companies I've never heard of.
Of course my statement is hyperbole; I'm sure there are people who use Go, and I didn't intend to hate on Go: I do think it's an interesting language that I am trying to learn. I'm just saying that I haven't seen it in use, and that perhaps the simplicity that its authors are touting lies mostly in their own familiarity with it. Go contains a lot of new and unfamiliar concepts, and it's not trivial to figure out how to best solve a problem using it. But remember that the whole point of my argument is that I don't consider simplicity an interesting criterion for the value of a technology - I can think Go is complex and interesting at the same time.
edit: Relevant information regarding the above examples, from the linked page about Tinkercad: "I also used to work on the Go team at Google so I had used it in production before."
- enneff 15y ago> Heroku is a meta-adoption, not actual use. How much is it actually being used by the users of Heroku? A huge part of their billing system is written in Go. > I'm just saying that I haven't seen it in use, and that perhaps the simplicity that its authors are touting lies mostly in their own familiarity with it. The creators are also expert C and C++ programmers, and have also designed several other languages. Go was born out of frustration with the thorns, inconsistencies, and surprises that plague a lot of languages. My personal experience is with JavaScript - I wrote JS code every day for several years, and still regularly had to use the console to test essential elements of the language, often with surprising results. We've tried to fix that with Go. Its features are designed to be simple in isolation and predictable when combined. This is the crux of my Google+ post. Our tools should be clean and consistent, so we can spend more time thinking about what we're building, not how the tool might explode if we hold it in the wrong way.