4 ms·

> What other topics do y'all think HN provides unique insight on? Career managment I think (not sure if it's the good term for it). I see lots of people in the

by Zababa 5y ago

> What other topics do y'all think HN provides unique insight on? Career managment I think (not sure if it's the good term for it). I see lots of people in their 40's or more that quit some FANG job for another job that earns less but is more aligned with how they want to live their life. I see lots of people advocating to quit jobs as soon as you see red flags. I think both of these are good wisdom. On the other hand, a point that's still a mystery to me is "programming language choice". I've learned useful heuristics like you can do web backend in pretty much anything, if you have no libraries for something that needs them like an AWS SDK you're going to suffer, what helps in the long run slows you down at first, but that's about it. I don't know if it's because I'm too young in this field, because I don't understand/missed something, or because there is no big truth to find.

gridspy 5y ago
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
- 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.
Jarwain 5y ago
> I don't know if it's because I'm too young in this field, because I don't understand/missed something, or because there is no big truth to find. I'm pretty young in the field as well, but my impression so far is that there aren't really any big truths, just a lot of little ones
- ethbr0 5y ago
  The only big truths are things that seem obviously one way, but in reality are the other way due to a myriad of non-obvious sub-things. E.g. Productive person-hour scaling as a function of team headcount

by Zababa 5y ago

gridspy 5y ago

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
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.

Jarwain 5y ago

> I don't know if it's because I'm too young in this field, because I don't understand/missed something, or because there is no big truth to find. I'm pretty young in the field as well, but my impression so far is that there aren't really any big truths, just a lot of little ones

ethbr0 5y ago
The only big truths are things that seem obviously one way, but in reality are the other way due to a myriad of non-obvious sub-things. E.g. Productive person-hour scaling as a function of team headcount