5 ms·

Personally I think programming language is about a compromise between performance and convenience. For instance, I program in Python if speed is irrelevant. Ru

Personally I think programming language is about a compromise between performance and convenience. For instance, I program in Python if speed is irrelevant. Rust if it is very relevant. C# if I want a large project where performance is somewhat important. I think there are a wide range of languages for each "category" where I put Python, C# and Rust above, but those 3 are my current favorites. Certain languages are very well suited to specific tasks. You learn these with experience. Initially I loved python because it was a joy to slice and dice strings in it. I understand that Ruby is popular for the same reason. Closure is great if you want lots of agents processing stuff on a network stack. If I were you, I'd just focus on making fun projects in your favorite language.

Zababa 5y ago
> Personally I think programming language is about a compromise between performance and convenience. That's one dimension, but what about popularity, maintainability, being able to hire, productivity, being able to tackle precise problems, etc.
- fiddlerwoaroof 5y ago
  I think concern about “ability to hire” is a bit overblown: I’ve worked at a couple places now that have taken the “hire people that know what they’re doing and they’ll figure out the language” approach, and it’s generally successful for most business applications: this is true even when the team is using unusual languages like Clojure.
  - xfer 5y ago
    The problem is really about tooling, you also need people who can fix bugs/port to new arch in the compiler and related tools. For a very popular language you can always find the right people for this task or even offload this task like they do with oracle.
- dgb23 5y ago
  Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. Edit: I didn’t read the comment right. Productivity and being able to solve precise problems are essentially why you’re choosing a technology in the first place?
  - Zababa 5y ago
    > Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. I don't think that's true, I believe most programmers are either dark matter developers [1] or people doing Java (or equivalent) all their life for a software service company. There is nothing wrong with that, but that would explain why less popular languages and ecosystem still have lots of stuff. For example, Rust has ~60k crates on crates.io, while Maven Central has ~400k packages. I believe Java is used by more than 10 times the number of people that use Rust. But the people writing the libraries in the first place are usually the people that are open to trying out new languages. [1]: https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99 https://www.hanselman.com/blog/dark-matter-developers-the-un...
- gridspy 5y ago
  I concur, though most of the traits you mention are not problem-specific. When putting a language into "your toolbox" you indeed SHOULD focus on "popularity, maintainability, being able to hire." However, when picking which of the languages you have learnt to apply to a given problem you need to know their relative strengths. Most of the strengths you mention help you pick the "best in class" language. But only the problem can tell you which subset of langauges you are picking from. Sometimes the best possible tool for your problem is going to be unpopular.
seanmcdirmid 5y ago
That’s true for conventional languages, you can trade off some performance for a bit of productivity. However, if you want significantly more productivity, we hit walls quickly in PL design where trading off performance is no longer effective. So ya, Kotlin is slightly better and slower than C, but both languages are fundamentally still in the same ballpark that we don’t know how to get out of yet.

Zababa 5y ago

> Personally I think programming language is about a compromise between performance and convenience. That's one dimension, but what about popularity, maintainability, being able to hire, productivity, being able to tackle precise problems, etc.

fiddlerwoaroof 5y ago
I think concern about “ability to hire” is a bit overblown: I’ve worked at a couple places now that have taken the “hire people that know what they’re doing and they’ll figure out the language” approach, and it’s generally successful for most business applications: this is true even when the team is using unusual languages like Clojure.
- xfer 5y ago
  The problem is really about tooling, you also need people who can fix bugs/port to new arch in the compiler and related tools. For a very popular language you can always find the right people for this task or even offload this task like they do with oracle.
dgb23 5y ago
Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. Edit: I didn’t read the comment right. Productivity and being able to solve precise problems are essentially why you’re choosing a technology in the first place?
- Zababa 5y ago
  > Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. I don't think that's true, I believe most programmers are either dark matter developers [1] or people doing Java (or equivalent) all their life for a software service company. There is nothing wrong with that, but that would explain why less popular languages and ecosystem still have lots of stuff. For example, Rust has ~60k crates on crates.io, while Maven Central has ~400k packages. I believe Java is used by more than 10 times the number of people that use Rust. But the people writing the libraries in the first place are usually the people that are open to trying out new languages. [1]: https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99 https://www.hanselman.com/blog/dark-matter-developers-the-un...
gridspy 5y ago
I concur, though most of the traits you mention are not problem-specific. When putting a language into "your toolbox" you indeed SHOULD focus on "popularity, maintainability, being able to hire." However, when picking which of the languages you have learnt to apply to a given problem you need to know their relative strengths. Most of the strengths you mention help you pick the "best in class" language. But only the problem can tell you which subset of langauges you are picking from. Sometimes the best possible tool for your problem is going to be unpopular.

seanmcdirmid 5y ago

That’s true for conventional languages, you can trade off some performance for a bit of productivity. However, if you want significantly more productivity, we hit walls quickly in PL design where trading off performance is no longer effective. So ya, Kotlin is slightly better and slower than C, but both languages are fundamentally still in the same ballpark that we don’t know how to get out of yet.