It's not clear to me what "onramp" actually means here, since it's not defined anywhere. Given the examples it appears to be something as generic as "a reason to use the language", and the whole argument becomes pretty much a tautology. Yes, of course most people will only use the language if they have a reason to use it. Unfortunately that's not a very actionable insight.
Incidentally, I'm not finding some of those examples of "onramps" very convincing. For example I would be stunned if a large proportion of current Go users said that they're using Go because it comes from Google. That (and the pedigree of the authors) might have gotten it some early buzz, but that's unlikely to carry the project very far by itself. The trail of failed or failing development tools from Google should be proof enough of that.
Yes, of course most people will only use the language if they have a reason to use it. Unfortunately that's not a very actionable insight.
Of course it is. Both illuminating ("hmm, we are lacking a concrete reason/opportunity to use the language, that's why people don't come to us") and actionable ("hmm, we better buuld one then").
Groovy, for an example of the latter, copied Rails to get Grails, which is one of its major selling points. And Julia tries to rebuild the Python/R statistical/scientific ecosystem.
For example I would be stunned if a large proportion of current Go users said that they're using Go because it comes from Google.
They might not say it, not even believe it themselves (they'd say thing like "it's the goroutines", or "it's the refhersing simplicity"), but I don't doubt much of it is true. Other worthwhile languages don't have the same visibility, a-level core teams, and sessions during Google-confs that Go has.
Weird, I found the concept so obvious I didn't notice the lack of a definition. An 'onramp' is a wooly concept because so many things could constitute one. A killer use case, a flagship company using the tech and shouting about it, maybe even just a great book/documentation. I think, and again this is without consulting someone else's definition, you need many, diverse, onramps, to become popular.
I distinctly remember being introduced to Go, it was around launch time but there was already a working compiler suite (that was easy to install from source on OSX and Linux), website, tutorial and introductory talks. Rather than Google backing per se, you could just say it was a well-launched product, but the two are probably intertwined.
People aren't using Go because of Google, but Go gained a lot of attention, and therefore a lot of people looked at Go, because of Google. Google also did a good job with developer outreach, which, IMO, is what keeps Erlang from moving to the next level,
People aren't using Go because of Google, but Go gained a lot of attention, and therefore a lot of people looked at Go, because of Google.
I chose to ignore Go initially because I thought it'd be yet another soon-to-be-abandoned Google project and because I felt that a programming language created by a large (unfocused) corporation doesn't have the best chances to develop in the direction I'd like (yes, I know how C started...).
What got me interested in the end was a) well-known (to me anyway) developers using Go and writing about it, b) the purported ease of learning, simplicity, standardized formatting and resulting "fun", c) concurrency features (lacking in many older languages).
Conclusion: it actually works to look at the needs / interests of influential developers and create something that fits for them. As far as Erlang is concerned, I believe too many of them have been put off by the syntax. Or it mostly attracts people who do not talk about it much, for some obscure reason.
Comments
It's not clear to me what "onramp" actually means here, since it's not defined anywhere. Given the examples it appears to be something as generic as "a reason to use the language", and the whole argument becomes pretty much a tautology. Yes, of course most people will only use the language if they have a reason to use it. Unfortunately that's not a very actionable insight.
Incidentally, I'm not finding some of those examples of "onramps" very convincing. For example I would be stunned if a large proportion of current Go users said that they're using Go because it comes from Google. That (and the pedigree of the authors) might have gotten it some early buzz, but that's unlikely to carry the project very far by itself. The trail of failed or failing development tools from Google should be proof enough of that.
Of course it is. Both illuminating ("hmm, we are lacking a concrete reason/opportunity to use the language, that's why people don't come to us") and actionable ("hmm, we better buuld one then").
Groovy, for an example of the latter, copied Rails to get Grails, which is one of its major selling points. And Julia tries to rebuild the Python/R statistical/scientific ecosystem.
They might not say it, not even believe it themselves (they'd say thing like "it's the goroutines", or "it's the refhersing simplicity"), but I don't doubt much of it is true. Other worthwhile languages don't have the same visibility, a-level core teams, and sessions during Google-confs that Go has.
Weird, I found the concept so obvious I didn't notice the lack of a definition. An 'onramp' is a wooly concept because so many things could constitute one. A killer use case, a flagship company using the tech and shouting about it, maybe even just a great book/documentation. I think, and again this is without consulting someone else's definition, you need many, diverse, onramps, to become popular.
I distinctly remember being introduced to Go, it was around launch time but there was already a working compiler suite (that was easy to install from source on OSX and Linux), website, tutorial and introductory talks. Rather than Google backing per se, you could just say it was a well-launched product, but the two are probably intertwined.
People aren't using Go because of Google, but Go gained a lot of attention, and therefore a lot of people looked at Go, because of Google. Google also did a good job with developer outreach, which, IMO, is what keeps Erlang from moving to the next level,
I chose to ignore Go initially because I thought it'd be yet another soon-to-be-abandoned Google project and because I felt that a programming language created by a large (unfocused) corporation doesn't have the best chances to develop in the direction I'd like (yes, I know how C started...).
What got me interested in the end was a) well-known (to me anyway) developers using Go and writing about it, b) the purported ease of learning, simplicity, standardized formatting and resulting "fun", c) concurrency features (lacking in many older languages).
Conclusion: it actually works to look at the needs / interests of influential developers and create something that fits for them. As far as Erlang is concerned, I believe too many of them have been put off by the syntax. Or it mostly attracts people who do not talk about it much, for some obscure reason.