4 ms·

TIOBE's good for trivia, but probably not for picking a specialisation path or choosing which tech to build a project on. When choosing a language to learn, I

by blub 11y ago

TIOBE's good for trivia, but probably not for picking a specialisation path or choosing which tech to build a project on. When choosing a language to learn, I consider: * what a particular industry or project of significance is using * job availability * compatibility with my existing toolbox * the power/fun factor But that's far from the whole story, because programming languages are relatively fungible and investing in domain knowledge, people skills, architecture and many other things will bring bigger benefits than learning that brand new programming language! And yet here we are, discussing how Rust will deliver us.

smt88 11y ago
> programming languages are relatively fungible I agree with that regarding learning them, but I disagree strongly when it comes to the end result. I make a lot of my money fixing/replacing PHP projects. As has been pointed out many times before, there are issues with PHP that are guaranteed to cause bugs. The same is true of many languages. But there is a spectrum! Some compilers/interpreters scream at you and terminate if you contradict yourself. Some of them even recognize security vulnerabilities. I agree that people skills, domain knowledge, and architecture are hugely important, but great teams are still less effective when they use slow or confusing tools. You might be the greatest contractor in the world, but if someone asks you to build a skyscraper with plywood and super glue, you're going to end up with something dangerous, fragile, and guaranteed to fall apart as soon as someone tries to use it.
pcwalton 11y ago
> * what a particular industry or project of significance is using > * job availability That just boils down to popularity once again. I prefer to pick languages based on suitability for the problem domain. For me, Rust is suitable in a way that C++ is not, due to memory safety among many other reasons.
- blub 11y ago
  I think we are mostly in agreement. If an industry is standardizing on a language, it's probably a good match for the kind of problems that they solve, i.e. for their problem domain. Job availability is not just about number of jobs, but also about project quality, companies and personal preference. E.g: I don't have an interest in containers, and most Go jobs involve containers, so this is a minus for Go. This works in the other direction too. Let's say I want to work for Mozilla, I notice they use mostly C++ & Js, so I decide to invest time brushing up my skills in those areas.
kamaal 11y ago
>>many other things will bring bigger benefits than learning that brand new programming language! The other narrative is also true. Using newer technologies is the best way to be a part of new projects and avoid working legacy maintenance kind of projects.
- mcguire 11y ago
  It's interesting that a synonym for "legacy maintenance kind of projects" is "successful".
jimbokun 11y ago
"And yet here we are, discussing how Rust will deliver us." So why are you here, debating about Rust, if you already know your time would be better spent investing in domain knowledge, people skills, or architecture?
- blub 11y ago
  Spending let's say 1h on HN is not at the same level of time investment as learning a programming language. ;) I am not really discussing Rust per se, as I am not familiar enough with it, however, when I see biased or misleading statements I do sometimes feel obliged to offer a counterpoint.

by blub 11y ago

smt88 11y ago

> programming languages are relatively fungible I agree with that regarding learning them, but I disagree strongly when it comes to the end result. I make a lot of my money fixing/replacing PHP projects. As has been pointed out many times before, there are issues with PHP that are guaranteed to cause bugs. The same is true of many languages. But there is a spectrum! Some compilers/interpreters scream at you and terminate if you contradict yourself. Some of them even recognize security vulnerabilities. I agree that people skills, domain knowledge, and architecture are hugely important, but great teams are still less effective when they use slow or confusing tools. You might be the greatest contractor in the world, but if someone asks you to build a skyscraper with plywood and super glue, you're going to end up with something dangerous, fragile, and guaranteed to fall apart as soon as someone tries to use it.

pcwalton 11y ago

> * what a particular industry or project of significance is using > * job availability That just boils down to popularity once again. I prefer to pick languages based on suitability for the problem domain. For me, Rust is suitable in a way that C++ is not, due to memory safety among many other reasons.

blub 11y ago
I think we are mostly in agreement. If an industry is standardizing on a language, it's probably a good match for the kind of problems that they solve, i.e. for their problem domain. Job availability is not just about number of jobs, but also about project quality, companies and personal preference. E.g: I don't have an interest in containers, and most Go jobs involve containers, so this is a minus for Go. This works in the other direction too. Let's say I want to work for Mozilla, I notice they use mostly C++ & Js, so I decide to invest time brushing up my skills in those areas.

kamaal 11y ago

>>many other things will bring bigger benefits than learning that brand new programming language! The other narrative is also true. Using newer technologies is the best way to be a part of new projects and avoid working legacy maintenance kind of projects.

mcguire 11y ago
It's interesting that a synonym for "legacy maintenance kind of projects" is "successful".

jimbokun 11y ago

"And yet here we are, discussing how Rust will deliver us." So why are you here, debating about Rust, if you already know your time would be better spent investing in domain knowledge, people skills, or architecture?

blub 11y ago
Spending let's say 1h on HN is not at the same level of time investment as learning a programming language. ;) I am not really discussing Rust per se, as I am not familiar enough with it, however, when I see biased or misleading statements I do sometimes feel obliged to offer a counterpoint.