5 ms·

The creators of Go assumed that their primary audience would be disgruntled C++ devs, and were surprised to find instead that it's mostly Ruby and Node.js peopl

The creators of Go assumed that their primary audience would be disgruntled C++ devs, and were surprised to find instead that it's mostly Ruby and Node.js people. Despite all of the "systems language" talk, it would not shock me in the least to see the same thing happen with Rust (or whatever new language comes along next year). I don't intend for this to be a slight, but the plain fact of the matter is that "dynamic" languages come in and out of fashion every 5 years or so. Those people are accustomed to that cycle. They get bored easily and PREFER that cycle. The senior ones are usually on their second or third language cycle (or beyond). In contrast, C++ and Java are ENTRENCHED in their areas (systems programming and business applications, respectively). Whatever ultimately displaces them someday... it will have to be an order of magnitude better, and it would still take years. By all means, market your favorite new language(s) to all possible demographics. Just understand that the "PHP/Python/Ruby/Node/Go/Elixir/Swift" crowd are going to be your primary adopters (and conversely, the first to grow bored and leave when the next thing comes along).

monkmartinez 11y ago
Do you think the "bored" and "move on" story could be driven by more than just a "shiny" new language perhaps? Economics maybe? Perhaps some developers in the "PHP/Python/Ruby/Node/Go/Elixir/Swift" crowd are trying to gain credibility in the OSS/Github world by making a not-yet-developed but vital library in the new language. If github is your resume, this could be a large win for their portfolio/resume. Another take... For Python, there are dozens of projects that do the same manipulations, but are implemented slightly differently. People can, of course, contribute(patches, issues, etc.) to libraries they use the most... or they can make the 25th iteration. A new language presents a way to tickle the brain in a not-so-tedious manner by eliminating the technical debt in the other language's implementation while providing new paradigms to code around. I call that tickling the brain and it can be addicting.
- StevePerkins 11y ago
  This is only supposition, but I believe that the vast majority of idle programming discussion on the Internet is non-professional. If you go to a site like StackOverflow, that is related to getting actual work done... the questions for Java, .NET, C++, and PHP absolutely dwarf those for Ruby, Python, and other fashionable dynamic languages (JavaScript being a notable exception). If you look at the number of GitHub repos by language, you find a similar pattern. However, you go to sites like Hacker News and others that are more about idle discussion, and it's hard to find people who will even admit to working with non-sexy industry standard languages. If you didn't know better, you would get the impression that there are more Nim and Forth programmers in the world than PHP ones. I believe that is because most such discussion comes either from students, who haven't started a career yet, or from professionals who enjoy discussing the "side" languages that they learn in their personal time (yet are not using professionally). I don't mean this in a negative way. I myself wrote OBSESSIVELY about Scala for years, even though my actual day jobs had me writing vanilla Java. But online discussion does create a bit of a "reality distortion field", that confuses young people just starting out. The #haskell channel on FreeNode is the most popular programming channel in all of IRC... yet the entire world's population of non-academic professional Haskell developers could hold a conference at the airport Holiday Inn. Rust is a fascinating language to learn and dabble with, but almost none of us will ever have a job working with it professionally. Etc. People get "bored" and "move on" from these languages not due to economics, but due to lack of economics. They are playing with them for fun, not because they're getting paid to do professional work with them. Hence the constant search for newer shiny things.
  - mattmanser 11y ago
    http://stackoverflow.com/tags http://stackoverflow.com/tags Doesn't support what you said. C++, for example, is smaller than Python. Ruby has about a 1/4 of the questions of Java. They're certainly not "absolutely dwarfed". Python is overwhelmingly the language of choice for scientists afaik.
  - EugeneOZ 11y ago
    You are writing it as comment to article, where demonstrated commercial usage of Rust and explained benefits of this usage. I do it not because Rust is a new shiny thing, but because I LOVE key ideas of errors handling, results returning and memory safety (RAII is awesome thing). I use it not because "oh, I can finally play with it", but because "finally I see language where things are done right so I can write code effectively, customers will be served without failures and I will not spend so many time in debugging stage anymore" - time is the most valuable resource. In usage Rust is not so cute and shiny (in first month). It's only pragmatic decision. And I'm glad I was able to convince my employer.
scardine 11y ago
Unfortunatelly the trade is full magpie developers. > I've often thought that software developers were akin to Magpies, birds notorious for stealing shiny items to decorate their complex nests. Like Magpies, software developers are unusually smart and curious creatures, almost by definition. But we are too easily distracted by shiny new toys and playthings. http://blog.codinghorror.com/the-magpie-developer/ http://blog.codinghorror.com/the-magpie-developer/
cballard 11y ago
Is that really a single crowd? It would seem like "PHP/Python/Ruby/Node" are separate from Swift (which is much more strict and is type/null-safe). Not sure where Go and Elixir would be sorted, but they feel less interchangeable than the first four.
- EugeneOZ 11y ago
  Swift is not safe at all, it's written in documentation - you can easily do race conditions errors, fail on unwrapping null value, and compiler will not notice it. It's declared honestly in their docs.
pcwalton 11y ago
> Whatever ultimately displaces them someday... it will have to be an order of magnitude better, and it would still take years. I actually think there's no room for any language to displace C++ in that way, ever. The biggest reason that people give for bouncing off Rust is that the novel aspects of the language--lifetimes and borrowing--are too unfamiliar and/or hard to learn. Any language that is to be an "order of magnitude better" than C++ will necessarily have aspects that are unfamiliar and hard to learn. Long-time C++ users will bounce off that language for the same reasons they're bouncing off Rust. No non-C++ language will ever appeal to C++ users who don't want to learn new concepts. C++ is very good at being C++, and for that reason it's immortal. Rather, new languages will continue to chip away at the uses of C++, making its use more and more marginal. This is a process that has been going on since the '90s--remember that in the '90s practically all software was written in C++, whereas in 2016 most new programmers aren't even learning it anymore. C++ has been declining not because it's being replaced but because its domains have become smaller and smaller. Rust is just a continuation of that trend: now there's a better option for security-critical software that can't be written in a GC language for performance and/or flexibility reasons (to name Rust's strongest domain), which has reduced the domain of C++ just as Java did 15 years ago for the server space and the rise of the iPhone App Store did in 2008 for the consumer app space. The continuation of this trend is what will gradually make C++ more and more niche going into the future.
- gue5t 11y ago
  This seems like the opposite of what I would expect. I'd think any good C or C++ programmer would reason about lifetimes in their programs on a regular basis. When I first came across Rust I was so happy to see a language codify the conventions around ownership and mutation that had previously been relegated to comments, naming patterns, and a rough consensus around what "const" meant. I would expect the people bouncing off of borrowck to be those coming from GC'd languages where where and how long a value lives aren't things most programmers think about. Programmers coming to Rust from this environment have to learn about the fundamental concepts of lifetimes and in-memory representation/storage at the same time as they learn the limitations and reasoning model of borrowck. Without having seen the mistakes they're being prevented from making, I can imagine trying to fix borrow errors would feel more like a game of appease-the-adversarial-checker than a safety harness catching you when you slip up. The only reason I see to keep writing C++ is the impedance gap between Rust and C++ making it less than pleasant to convert a large C++ codebase to Rust gradually. On top of name-mangling/linking concerns, Rust encourages composition and static method dispatch whereas it's rare to find a large C++ project not using inheritance and vtables extensively. You'd probably just end up going through the C ABI for all interop which is hard to argue would increase code quality compared to simply sticking to pure C++.

monkmartinez 11y ago

Do you think the "bored" and "move on" story could be driven by more than just a "shiny" new language perhaps? Economics maybe? Perhaps some developers in the "PHP/Python/Ruby/Node/Go/Elixir/Swift" crowd are trying to gain credibility in the OSS/Github world by making a not-yet-developed but vital library in the new language. If github is your resume, this could be a large win for their portfolio/resume. Another take... For Python, there are dozens of projects that do the same manipulations, but are implemented slightly differently. People can, of course, contribute(patches, issues, etc.) to libraries they use the most... or they can make the 25th iteration. A new language presents a way to tickle the brain in a not-so-tedious manner by eliminating the technical debt in the other language's implementation while providing new paradigms to code around. I call that tickling the brain and it can be addicting.

StevePerkins 11y ago
This is only supposition, but I believe that the vast majority of idle programming discussion on the Internet is non-professional. If you go to a site like StackOverflow, that is related to getting actual work done... the questions for Java, .NET, C++, and PHP absolutely dwarf those for Ruby, Python, and other fashionable dynamic languages (JavaScript being a notable exception). If you look at the number of GitHub repos by language, you find a similar pattern. However, you go to sites like Hacker News and others that are more about idle discussion, and it's hard to find people who will even admit to working with non-sexy industry standard languages. If you didn't know better, you would get the impression that there are more Nim and Forth programmers in the world than PHP ones. I believe that is because most such discussion comes either from students, who haven't started a career yet, or from professionals who enjoy discussing the "side" languages that they learn in their personal time (yet are not using professionally). I don't mean this in a negative way. I myself wrote OBSESSIVELY about Scala for years, even though my actual day jobs had me writing vanilla Java. But online discussion does create a bit of a "reality distortion field", that confuses young people just starting out. The #haskell channel on FreeNode is the most popular programming channel in all of IRC... yet the entire world's population of non-academic professional Haskell developers could hold a conference at the airport Holiday Inn. Rust is a fascinating language to learn and dabble with, but almost none of us will ever have a job working with it professionally. Etc. People get "bored" and "move on" from these languages not due to economics, but due to lack of economics. They are playing with them for fun, not because they're getting paid to do professional work with them. Hence the constant search for newer shiny things.
- mattmanser 11y ago
  http://stackoverflow.com/tags http://stackoverflow.com/tags Doesn't support what you said. C++, for example, is smaller than Python. Ruby has about a 1/4 of the questions of Java. They're certainly not "absolutely dwarfed". Python is overwhelmingly the language of choice for scientists afaik.
- EugeneOZ 11y ago
  You are writing it as comment to article, where demonstrated commercial usage of Rust and explained benefits of this usage. I do it not because Rust is a new shiny thing, but because I LOVE key ideas of errors handling, results returning and memory safety (RAII is awesome thing). I use it not because "oh, I can finally play with it", but because "finally I see language where things are done right so I can write code effectively, customers will be served without failures and I will not spend so many time in debugging stage anymore" - time is the most valuable resource. In usage Rust is not so cute and shiny (in first month). It's only pragmatic decision. And I'm glad I was able to convince my employer.

scardine 11y ago

Unfortunatelly the trade is full magpie developers. > I've often thought that software developers were akin to Magpies, birds notorious for stealing shiny items to decorate their complex nests. Like Magpies, software developers are unusually smart and curious creatures, almost by definition. But we are too easily distracted by shiny new toys and playthings. http://blog.codinghorror.com/the-magpie-developer/ http://blog.codinghorror.com/the-magpie-developer/

cballard 11y ago

Is that really a single crowd? It would seem like "PHP/Python/Ruby/Node" are separate from Swift (which is much more strict and is type/null-safe). Not sure where Go and Elixir would be sorted, but they feel less interchangeable than the first four.

EugeneOZ 11y ago
Swift is not safe at all, it's written in documentation - you can easily do race conditions errors, fail on unwrapping null value, and compiler will not notice it. It's declared honestly in their docs.

pcwalton 11y ago

> Whatever ultimately displaces them someday... it will have to be an order of magnitude better, and it would still take years. I actually think there's no room for any language to displace C++ in that way, ever. The biggest reason that people give for bouncing off Rust is that the novel aspects of the language--lifetimes and borrowing--are too unfamiliar and/or hard to learn. Any language that is to be an "order of magnitude better" than C++ will necessarily have aspects that are unfamiliar and hard to learn. Long-time C++ users will bounce off that language for the same reasons they're bouncing off Rust. No non-C++ language will ever appeal to C++ users who don't want to learn new concepts. C++ is very good at being C++, and for that reason it's immortal. Rather, new languages will continue to chip away at the uses of C++, making its use more and more marginal. This is a process that has been going on since the '90s--remember that in the '90s practically all software was written in C++, whereas in 2016 most new programmers aren't even learning it anymore. C++ has been declining not because it's being replaced but because its domains have become smaller and smaller. Rust is just a continuation of that trend: now there's a better option for security-critical software that can't be written in a GC language for performance and/or flexibility reasons (to name Rust's strongest domain), which has reduced the domain of C++ just as Java did 15 years ago for the server space and the rise of the iPhone App Store did in 2008 for the consumer app space. The continuation of this trend is what will gradually make C++ more and more niche going into the future.

gue5t 11y ago
This seems like the opposite of what I would expect. I'd think any good C or C++ programmer would reason about lifetimes in their programs on a regular basis. When I first came across Rust I was so happy to see a language codify the conventions around ownership and mutation that had previously been relegated to comments, naming patterns, and a rough consensus around what "const" meant. I would expect the people bouncing off of borrowck to be those coming from GC'd languages where where and how long a value lives aren't things most programmers think about. Programmers coming to Rust from this environment have to learn about the fundamental concepts of lifetimes and in-memory representation/storage at the same time as they learn the limitations and reasoning model of borrowck. Without having seen the mistakes they're being prevented from making, I can imagine trying to fix borrow errors would feel more like a game of appease-the-adversarial-checker than a safety harness catching you when you slip up. The only reason I see to keep writing C++ is the impedance gap between Rust and C++ making it less than pleasant to convert a large C++ codebase to Rust gradually. On top of name-mangling/linking concerns, Rust encourages composition and static method dispatch whereas it's rare to find a large C++ project not using inheritance and vtables extensively. You'd probably just end up going through the C ABI for all interop which is hard to argue would increase code quality compared to simply sticking to pure C++.