6 ms·

Startups are about cost, time to market, and a high level of efficiency to deliver on a promises ( product ) to sell or get to market. A language selection shou

Startups are about cost, time to market, and a high level of efficiency to deliver on a promises ( product ) to sell or get to market. A language selection should consider two things, talent pool and maturity of the tools. When you go hire developers, I want a strong pool to be able to be selective in finding attitude with the right aptitude, and I want them to be productive ASAP, so that means that we might bring in GNU protects that we are extending, tooling from other sources and high level knowledge of the code… this is where maturity comes in, not the language that matters, it’s the package you get on the product you are developing. I love rust, it will get there, but in a startup environment, it could end up been “not the best fit” all things considered.

synergy20 4y ago
Exactly, I did startup before, and my take is: Rust is absolutely the worst choice for startups. to survive startup, you need a large pool of talents, mature and verified and boring stack, easy to find tutorials, etc. The least thing you want is to spend cycles on fancy new bleeding unstable languages to build your earth shaking product.
- Curious_Furious 4y ago
  >you need a large pool of talents Forgive me if I'm quoting you out of context but the article mentions receiving 4000 applicants over 8 weeks time. I've hired (primarily) for Java and DBA positions, and we would be absolutely thrilled if we got even 40 applicants.
  - linkdd 4y ago
    "pool of talents" vs "pool of people who jumped on the hype train 2 weeks ago" Many people are searching for Rust jobs, but few have a really strong experience with it.
  - synergy20 4y ago
    "Many didn’t actually have Rust experience at all and that’s fine, they were just interested in the idea" -- to me, that's _not_ fine. startup needs to move fast to stay above the water, it's not the best place to learn 'coding in Rust 101' IMHO
    - sn9 4y ago
      In a pool of 4000, the fact that many didn't have experience with Rust doesn't mean that there weren't also many that did have experience. You could just filter the CVs for Rust experience and then take the most impressive 10 or 100 to interview.
- deleted 4y ago
  [deleted]
- tialaramex 4y ago
  > fancy new bleeding unstable language Where does a language magically go from "new bleeding unstable" to something you think is suitable to use at a startup ? Rust 1.0 was in 2015, seven years ago. Do you think a startup should also avoid the "fancy new" ES6 with "let" and arrow functions ?
  - javcasas 4y ago
    When I see people complaining about "experimental", "new bleedy unstable" I always picture some weak developer complaining about the language not being Java 1.4 and having to learn other stuff that is different from enterprise OO invented after the year 2000. See Rust (7 years already), Haskell (older than Java), React (9 years). They all miss their 5 million LoC mudball at the bank, because that's all they know how to do.
BigJ1211 4y ago
On the other hand, you might attract talent that wants to use a specific language like Rust, but hasn't had the chance in their current professional environment.
- pizza234 4y ago
  That'd be a disaster for a startup. In order to use Rust efficiently, one needs to have a significant experience with it; without experience, one wastes a lot of time wrestling with ownership, lifetimes etc. (I do program in Rust in my (non-trivial) hobby projects).
- gwbas1c 4y ago
  I've been toying with Rust on and off for a few years. It has an extremely steep learning curve. As a novice it's incredibly difficult to do things that are trivial in other languages. > On the other hand, you might attract talent that wants to use a specific language like Rust, but hasn't had the chance in their current professional environment Maybe if you're doing something embedded? Otherwise, the learning curve is so steep that you're better off just buying a faster computer to run C#/Java/NodeJS/Python/Whatever.
  - drogus 4y ago
    There are plenty of Rust devs looking for work outside of embedded. Also, for me Rust's speed is one of the benefits. I would default to Rust for a lot of different things where speed doesn't matter at all.
  - staticassertion 4y ago
    We've had 0 issues hiring for Rust, despite the vast majority of the company having no prior experience with it (or some experience on the side). The learning curve isn't that bad, maybe you just haven't dedicated the right time or you've had trouble learning it in isolation.
- mwcampbell 4y ago
  It's also worth considering what will keep the founder(s) motivated to stay focused and do good work. Yes, using JavaScript and Electron might be the optimal rational business decision, and in theory we should be motivated solely by the problem we're trying to solve. But if the technical cofounder, who's currently the only programmer, then feels that they're creating something that nobody can really love, and they get discouraged at the state of the world that led to that decision in the first place, that's not good for productivity. You can probably guess how I know this.
strken 4y ago
I'm doing some work on a friend's startup, and we have a pretty stark divide between our hot path gateway service and our lower traffic services. All three of our services are currently written in typescript with no plans to change, but I've earmarked the gateway as "maybe we'll rewrite it in Rust in three years." It's so small it's nearly trivial (so a rewrite of that specific service will be quickish) and infrequently changed (so hiring won't be as big an issue), it deals with low latency IO-heavy workloads (so we'll possibly want a language without GC pauses), and we really don't want it to break (so it's worth more effort per line). Not sure how a hybrid approach will work.
- ekidd 4y ago
  > Not sure how a hybrid approach will work. The hybrid approach works great. We use typed scripting languages for business logic and Rust CLI tools for "inner loops", and this balance gives us the best of both worlds. There is an important caveat here: If you are already comfortable in Rust, then it's a fantastic tool for all sorts of things. But if you're just learning Rust, then there's a one-time cost for getting comfortable. So for a small team with zero prior Rust experience, expect to spend 2-6 weeks getting comfortable. (The learning curve is shorter if you already know about pointers and closures, and longer if it's your first low-level language.) Your plan sounds entirely reasonable.
  - orangetuba 4y ago
    2-6 weeks? I wish I could learn Rust in that time.
  - HWR_14 4y ago
    > The learning curve is shorter if you already know about pointers and closures Every time I read something like this, I'm reminded that pointers and closures aren't universally understood concepts in professional programmers. And I'm sad.
    - chungus 4y ago
      I share this sentiment, it's kind of a bummer. I ran into this non-stop in enterprise Java/C# development environments, more specifically in developers who are not "classically schooled" (i.e. bootcampers). Fact of the matter was, they never needed to know about pointers to do their job. They only even knew the term from the "null pointer exception". I looked into the curriculum of various levels of IT studies and unless you get taught at university level there are little to no memory / hardware oriented classes. It has started to get a bit better since the introduction of Java 8 (don't look up how long ago this was, ouch) and people got familiar with "lambda's".

synergy20 4y ago

Exactly, I did startup before, and my take is: Rust is absolutely the worst choice for startups. to survive startup, you need a large pool of talents, mature and verified and boring stack, easy to find tutorials, etc. The least thing you want is to spend cycles on fancy new bleeding unstable languages to build your earth shaking product.

Curious_Furious 4y ago
>you need a large pool of talents Forgive me if I'm quoting you out of context but the article mentions receiving 4000 applicants over 8 weeks time. I've hired (primarily) for Java and DBA positions, and we would be absolutely thrilled if we got even 40 applicants.
- linkdd 4y ago
  "pool of talents" vs "pool of people who jumped on the hype train 2 weeks ago" Many people are searching for Rust jobs, but few have a really strong experience with it.
- synergy20 4y ago
  "Many didn’t actually have Rust experience at all and that’s fine, they were just interested in the idea" -- to me, that's _not_ fine. startup needs to move fast to stay above the water, it's not the best place to learn 'coding in Rust 101' IMHO
  - sn9 4y ago
    In a pool of 4000, the fact that many didn't have experience with Rust doesn't mean that there weren't also many that did have experience. You could just filter the CVs for Rust experience and then take the most impressive 10 or 100 to interview.
deleted 4y ago
[deleted]
tialaramex 4y ago
> fancy new bleeding unstable language Where does a language magically go from "new bleeding unstable" to something you think is suitable to use at a startup ? Rust 1.0 was in 2015, seven years ago. Do you think a startup should also avoid the "fancy new" ES6 with "let" and arrow functions ?
- javcasas 4y ago
  When I see people complaining about "experimental", "new bleedy unstable" I always picture some weak developer complaining about the language not being Java 1.4 and having to learn other stuff that is different from enterprise OO invented after the year 2000. See Rust (7 years already), Haskell (older than Java), React (9 years). They all miss their 5 million LoC mudball at the bank, because that's all they know how to do.

BigJ1211 4y ago

On the other hand, you might attract talent that wants to use a specific language like Rust, but hasn't had the chance in their current professional environment.

pizza234 4y ago
That'd be a disaster for a startup. In order to use Rust efficiently, one needs to have a significant experience with it; without experience, one wastes a lot of time wrestling with ownership, lifetimes etc. (I do program in Rust in my (non-trivial) hobby projects).
gwbas1c 4y ago
I've been toying with Rust on and off for a few years. It has an extremely steep learning curve. As a novice it's incredibly difficult to do things that are trivial in other languages. > On the other hand, you might attract talent that wants to use a specific language like Rust, but hasn't had the chance in their current professional environment Maybe if you're doing something embedded? Otherwise, the learning curve is so steep that you're better off just buying a faster computer to run C#/Java/NodeJS/Python/Whatever.
- drogus 4y ago
  There are plenty of Rust devs looking for work outside of embedded. Also, for me Rust's speed is one of the benefits. I would default to Rust for a lot of different things where speed doesn't matter at all.
- staticassertion 4y ago
  We've had 0 issues hiring for Rust, despite the vast majority of the company having no prior experience with it (or some experience on the side). The learning curve isn't that bad, maybe you just haven't dedicated the right time or you've had trouble learning it in isolation.
mwcampbell 4y ago
It's also worth considering what will keep the founder(s) motivated to stay focused and do good work. Yes, using JavaScript and Electron might be the optimal rational business decision, and in theory we should be motivated solely by the problem we're trying to solve. But if the technical cofounder, who's currently the only programmer, then feels that they're creating something that nobody can really love, and they get discouraged at the state of the world that led to that decision in the first place, that's not good for productivity. You can probably guess how I know this.

strken 4y ago

I'm doing some work on a friend's startup, and we have a pretty stark divide between our hot path gateway service and our lower traffic services. All three of our services are currently written in typescript with no plans to change, but I've earmarked the gateway as "maybe we'll rewrite it in Rust in three years." It's so small it's nearly trivial (so a rewrite of that specific service will be quickish) and infrequently changed (so hiring won't be as big an issue), it deals with low latency IO-heavy workloads (so we'll possibly want a language without GC pauses), and we really don't want it to break (so it's worth more effort per line). Not sure how a hybrid approach will work.

ekidd 4y ago
> Not sure how a hybrid approach will work. The hybrid approach works great. We use typed scripting languages for business logic and Rust CLI tools for "inner loops", and this balance gives us the best of both worlds. There is an important caveat here: If you are already comfortable in Rust, then it's a fantastic tool for all sorts of things. But if you're just learning Rust, then there's a one-time cost for getting comfortable. So for a small team with zero prior Rust experience, expect to spend 2-6 weeks getting comfortable. (The learning curve is shorter if you already know about pointers and closures, and longer if it's your first low-level language.) Your plan sounds entirely reasonable.
- orangetuba 4y ago
  2-6 weeks? I wish I could learn Rust in that time.
- HWR_14 4y ago
  > The learning curve is shorter if you already know about pointers and closures Every time I read something like this, I'm reminded that pointers and closures aren't universally understood concepts in professional programmers. And I'm sad.
  - chungus 4y ago
    I share this sentiment, it's kind of a bummer. I ran into this non-stop in enterprise Java/C# development environments, more specifically in developers who are not "classically schooled" (i.e. bootcampers). Fact of the matter was, they never needed to know about pointers to do their job. They only even knew the term from the "null pointer exception". I looked into the curriculum of various levels of IT studies and unless you get taught at university level there are little to no memory / hardware oriented classes. It has started to get a bit better since the introduction of Java 8 (don't look up how long ago this was, ouch) and people got familiar with "lambda's".