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.
Why Rust is a great choice for startups
251–260 of 294 posts
Re: Why Rust is a great choice for startups
#252Earlier 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.
Have you got any data to support it ?
Re: Why Rust is a great choice for startups
#253Earlier 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.
Re: Why Rust is a great choice for startups
#254Rust 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.
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
#255Earlier 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…
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?
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.
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
#257Earlier 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.
Re: Why Rust is a great choice for startups
#258Earlier 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.
Re: Why Rust is a great choice for startups
#259Earlier 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
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
#260Earlier 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.