Live data from Hacker News

Why Rust is a great choice for startups

dailyedit.com

251–260 of 294 posts

Re: Why Rust is a great choice for startups

#251
post #149
post #124

Earlier quoted context omitted.

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

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

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

Re: Why Rust is a great choice for startups

#252
post #161
post #148

Earlier quoted context omitted.

These comments are still in context of using the language in a startup. Good luck with finding Ocaml, F# or Scala devs.

There are much more Scala devs than Rust devs.

Sounds like a bold claim to me, let alone the "much more" part.

Have you got any data to support it ?

Re: Why Rust is a great choice for startups

#253
post #208

Earlier quoted context omitted.

No, not really. Rust undoubtedly started on *nix, but all Tier 1 platforms are supported equally[1]. To quote from OCaml's main site[2] A gentle reminder that if you do not need Windows binaries, then a more stable option is to use WSL2 , ie when on Windows it is better to use OCaml from within a Linux VM. Ocaml is great, but its Windows support sucks, and that makes adoption hard in a lot of contexts. [1] https://do…

Any language that calls themselves systems programming language, on Windows, must have first class support for COM and WinRT, in their various workloads. Rust support for them is pretty much WIP. And then there is the whole matter that Windows shops love to ship binary libraries.

There has been a Microsoft supported Rust projection of WinRT for a few years now [1].

[1] https://github.com/microsoft/windows-rs

Re: Why Rust is a great choice for startups

#254

Rust is not a great choice for startups! In fact, NO LANGUAGE is a great choice for startups! You don't choose languages depending on whether you're a startup! You choose languages based of the problem you're trying to solve, how fit the language is for solving that particular problem, the ecosystem supporting that language, and the availability of developers who are experienced with that language. Rust just may be t…

> Rust just may be the best choice for your startup, but it's not necessarily the best choice for all startups - in fact it's probably not the best choice for most startups! Maybe it's just an assumption on your end. Neither title nor author imply that it's THE choice. The title literally says "a great choice" > In the next post we’ll go into some of the downsides of using Rust.

> The title literally says "a great choice"

When in reality it may be, or it may be the worst possible choice. This is the parent commenter's point, I believe.

Re: Why Rust is a great choice for startups

#255
post #112

Earlier quoted context omitted.

Two things I consider: 1. what languages does the team already know best? 2. are any languages dominant in the problem space? for us, I've used Python over 10 years and Python is the leader in data science / analytics. Some things might be a little faster if we used Rust, but compute is cheap. Go with what you know.

>compute is cheap. Go with what you know. sorry for picking on your comment in this generic fashion but I am critical of these memes not your observations: Compute Is Cheap(where Gustafson Bariss is true ) https://en.m.wikipedia.org/wiki/Gustafson%27s_law Going with what you already know is fine for knocking out the cobwebs and getting into a space. But most generally certainly in my experience I've never done anythi…

My response to the "compute is cheap" argument is always: Discord powers millions of concurrent live-chat and real-time-voice users from literally single (huge) VMs, using Elixir and Rust. Their revenue (relatively) sucks; its a powerhouse in communication because their revenue sucks (zero barrier to entry); and because their revenue sucks, they were forced to actually think critically about the technologies they use. They can't just throw more computers at the problem; and that limitation produced a far better product than, say, Slack.

Ok, smaller scale. You look at the latest Show HN SaaS product and wonder: "Why is there no free tier?" Free tiers are a classic in SaaS; it gets customers in the door, using your product, and you can upsell to higher tiers. Its all the same backend no matter the cost; but if your infrastructure & engineering costs are high, you may not be able to afford a generous free tier.

The days of the SaaS unicorn are behind us. Also; the days of Moore's Law (server-side at least) are quickly dwindling. This idea of "just throw more compute at the problem" needs to die a painful death. This week I consulted with a startup with something like $500k in ARR, spending $80k/year in cloud infrastructure. No free tier, all enterprise contracts, the most basic CRUD app you can imagine. A hundred NodeJS containers, every security service AWS offers enabled and logging terabytes of useless shit to an S3 bucket, autoscaling their database up to 100s of gigabytes in memory because "we don't have time to optimize". Sure; you also don't have time to not to. You're banking on some large enterprise contract to come through and buy another year; which will also add a few tens of thousands of more users to the platform, so you'll tweak the scale numbers up again, and again, and just keep praying one day you can cost optimize. Every day that goes by makes that harder, so you're also praying that maybe you can find more talent to do it, maybe we can grab some people from these layoffs, except what if we don't have the money to pay for talent just like the company that laid them off?

Python, JS, Big Cloud, had their time and were valuable during it; but today, startups need to think about cost optimization from day 1, and every cycle a CPU spends doing something is a cost. I'm not prescribing technologies; I'm just asking for more critical thinking, and not always operating with the "throw money at it" mindset. Maybe python makes sense; how can we deliver it with extremely low costs? Lambda? DigitalOcean? Can we integrate a more performance-oriented view into reviews? This part of the app experiences 10x the traffic the rest does; can we break that out into something far more efficient?

[1] https://discord.com/category/engineering

Re: Why Rust is a great choice for startups

#256

> it’s still orders of magnitude faster than Python, Ruby, Javascript and Java. Unsubstantiated claims like this, just makes me stop reading.

What's your ballpark guestimate?

aot language implementation based-on llvm, guess something like clang?

Then guess it depends which Python and Ruby language implementations, what exactly we need to do and how much we can call C libs :-)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Why Rust is a great choice for startups

#257
post #241

Earlier quoted context omitted.

> FYI: If you're primarily IO-heavy, the GC pauses aren't going to be a big deal. Something like NodeJS (or Async .Net) will have great performance; even with garbage collection. (IO-heavy is the specific use case that NodeJS was designed to handle.) This just isn't true. Node is pretty terrible even at IO heavy workloads, especially if you have servers with many cores. Any benchmark will confirm this.

Is not Java or Go but surely beats the pants out of Ruby/Python, and then, Ruby/Python has been wildly successful for lots apps/companies.

Of course. It's also better than solving problems with pen and paper.

Re: Why Rust is a great choice for startups

#258
post #250

Earlier quoted context omitted.

Yeah fair, in my mind I was just responding to the bit about node, but whatever. > I'd argue that choosing Rust for most startups is outright irresponsible. I feel the opposite and I run a startup using Rust. If I could go back I'd use Rust in more places, not fewer.

Rust, Python and Go. Props to you for being sensible with technology choice. https://github.com/grapl-security/grapl https://github.com/grapl-security/pulumi-hcp Whish you guys success.

Much appreciated

Re: Why Rust is a great choice for startups

#259
post #208

Earlier quoted context omitted.

Any language that calls themselves systems programming language, on Windows, must have first class support for COM and WinRT, in their various workloads. Rust support for them is pretty much WIP. And then there is the whole matter that Windows shops love to ship binary libraries.

There has been a Microsoft supported Rust projection of WinRT for a few years now [1]. [1] https://github.com/microsoft/windows-rs

Now go try to write a UWP app with it, or a COM library to be consumed by .NET in MTA mode.

Why do you think I mentioned WIP?

The competition bare minimum is MFC, ATL, WRL, including Visual Studio tooling.

Re: Why Rust is a great choice for startups

#260

Earlier quoted context omitted.

Unpopular opinion - Haskell was intended for research and learning, not so much for mainstream production code. I'm not saying you can't use Haskell for that purpose, but you should think long and hard before doing so. If the answer is still yes then go back and make sure you've thought long enough and hard enough! :)

Haskell is fine for production code. You just need to know what you're doing, and not go crazy with abstraction.

It's the same for all languages, premature abstraction is a plauge in this industry.
Post reply on HN