Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I love building a startup in Rust but wouldn't pick it again

propelauth.com

Post reply on HN
Print view View original

281–290 of 496 posts

Re: I love building a startup in Rust but wouldn't pick it again

#281

Post by steveklabnik »

strokirk wrote: post #275
ye-olde-sysrq wrote: post #200

Earlier quoted context omitted.

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right c…

Is there any statically typed HTML templating language, for non-node languages? Genuine question.

crates.io for Rust has 213 crates tagged "template-engine" https://crates.io/categories/template-engine

handlebars, terra, askama, and maud are examples I recognize from high up on that list.

Maud example: (chosen because it's the most "native Rust" in a sense and is designed for HTML specifically so I believe it's the closest to what you're asking for)

  html! {
      h1 { "Hello, world!" }
      p.intro {
          "This is an example of the "
          a href="https://github.com/lambda-fairy/maud" { "Maud" }
          " template language."
      }
  }
https://maud.lambda.xyz/

Re: I love building a startup in Rust but wouldn't pick it again

#282

Post by dilippkumar »

Ylmaz wrote: post #143

I like this quote from 'The art of Unix Programming' published in 2003 "While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly const…

In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second.

Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation.

I'm pretty sure that maintaining a C++ codebase is less than 7.7 times more expensive than Node, even if you throw in extra development time etc. This also ignores the decades worth of excellent tooling we've built up for C++ (static analyzers, fuzzers, etc).

At a startup, when building things fast matters more than costs, sure. I buy the argument for Node or Python or any other interpreted backend. But once you start to scale, things change after some threshold. Unless you're facebook[1].

[0]. https://www.techempower.com/benchmarks/#section=data-r21

[1]. https://developers.facebook.com/blog/post/2010/02/02/hiphop-...

Re: I love building a startup in Rust but wouldn't pick it again

#283

Post by ISL »

AceJohnny2 wrote: post #279

> Perf is easy when you have AWS credits. I get that the point of this article is that launching > sustaining. But I have a horror story about AWS credits for startups: a friend's startup got their account suspended for a couple days when their Credits ran out, they started getting billed 5 digits (as they expected), and Amazon's fraud detection detected this as an anomalous billing pattern and suspended them! For tr…

If those reassurances are in unmistakable writing, a letter from the startup's corporate attorney may yield a quick refund and compensation.

Re: I love building a startup in Rust but wouldn't pick it again

#284

Post by brimstedt »

legerdemain wrote: post #257
ye-olde-sysrq wrote: post #200

Earlier quoted context omitted.

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right c…

This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in…

To clarify my point, I think nodejs is great for the backend part of the view layer and to proxy requests to another backend service.

But for business logic, database interactions, calculations, etc, I really think the language construct is to clumsy and does not scale nicely.

Re: I love building a startup in Rust but wouldn't pick it again

#285

Post by xcdzvyn »

tomp wrote: post #240
lenkite wrote: post #201

Earlier quoted context omitted.

All these workarounds for easier Result handling truly make me wonder whether Rust will eventually evolve exceptions as a feature - of-course without explicitly terming them so.

Rust already has exceptions, they just call them panic and offer exceedingly poor language support for them. Some people simply live in denial, believing untruths that confirm their worldview. This is the same situation as with Go and generics. The maintainers were in denial for a very long time, before finally admitting what was obvious to some of us long before [1] [1] https://news.ycombinator.com/item?id=8626978

The implementation, outcome, use-case, and characteristics of panics are all very different from exceptions. The only marked similarity between the two is that they both interrupt program execution (and in different ways). But I feel as if you already knew that.

Re: I love building a startup in Rust but wouldn't pick it again

#287

Post by ModernMech »

alfalfasprout wrote: post #205
throw14082020 wrote: post #94

Earlier quoted context omitted.

Go is in a sweet spot where it is often used to compete with both groups: [Rust, C/C++] and [Node, Python, Ruby, etc]. The reason GP said it is probably because of Garbage collection. I've done a bit of Rust in my job, and there are some basic things that Rust doesn't have going for it: - steep learning curve (this means for the first 6 months, you or your colleagues are unproductive, write bad Rust which your compan…

Unfortunately, I'm inclined to agree. Rust lives in this interesting spot where, on paper, it should be superior to anything... but in practice, it's not a good choice in most cases. It's very easy to ramp up someone in Go that's had a standard CS education and written C/C++ before. It's also simple enough syntax-wise for someone who knows python well enough to understand references, etc. Its stylistic restrictions a…

> With Rust, I've found even very experienced C++ folks have a long ramp-up period

I've found C++ folks especially have the hardest time with Rust, because they approach it using C++ idioms and habits, then get frustrated when they can't do things the way they're used to.

I've had better success teaching Java people Rust. They find it much easier to learn than C++, and I can get them writing idiomatic Rust code quickly, while C++ devs are still trying to get their coding habits past the borrow checker.

Re: I love building a startup in Rust but wouldn't pick it again

#288

Post by anacrolix »

echelon wrote: post #235
a5huynh wrote: post #144

Earlier quoted context omitted.

I've run into similar issues and found that the `thiserror` crate ( https://crates.io/crates/thiserror ) combined w/ anyhow makes a lot of that pain go away

`anyhow` + `?` make writing an application as smooth as butter. You won't miss exceptions. Don't use `anyhow` for libraries, though. You want to provide your consumers the ability to `match`.

here we go again!

Re: I love building a startup in Rust but wouldn't pick it again

#289

Post by timerol »

dilippkumar wrote: post #282
Ylmaz wrote: post #143

I like this quote from 'The art of Unix Programming' published in 2003 "While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly const…

In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second. Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation. I'm pretty sure that maintaining a C++ codebase is less…

> I'm pretty sure that maintaining a C++ codebase is less than 7.7 times more expensive than Node, even if you throw in extra development time etc.

The problem here is assuming that a 7.7x less expensive AWS bill is the same value as a 7.7x more expensive development time. Imagine an app that is maintained by one programmer costing $10k a month and running in AWS for $1k a month. It is not worth dividing that AWS cost by 10x if it means a 10% development time hit. Actual numbers may vary, but development often costs much more than running in AWS. (For startups it's even more of a difference, because you pay AWS as you get more traffic, but you pay developers before you have an MVP.)

Re: I love building a startup in Rust but wouldn't pick it again

#290

Post by pclmulqdq »

mike_hearn wrote: post #277
pclmulqdq wrote: post #159

Earlier quoted context omitted.

Kind of yes, and kind of no. On the happy path, if errors are very very rare, the check is also basically free thanks to branch prediction. They start to cost something when you start to add a higher frequency of errors, which incidentally is where exceptions cost a lot more.

The cost is higher because of all the branches that are scattered everywhere to check return codes. With exceptions there's a check at the place the error is thrown, but that's inevitable. There aren't checks scattered throughout the rest of the code, which would otherwise reduce icache utilization.

Arguing about icache utilization is a little silly here - the code will be laid out for you as though the branches are not taken (or you should force it to do so). In that case, the only "waste" of icache is the CMP and JMP, an additional 4-8 bytes per return, and literally 0 cycles.

When you do take an error, each RET takes you 1 cycle, plus the 10-15 cycle mispredict for the CMP+JMP because there's a stack engine in the CPU that tells you the address to return to. It's counterintuitive that doing "a lot" of things is cheaper than doing fewer things, but it's true.

In comparison, an exception involves taking the one control flow break to some cold control code (maybe page faulting), figuring out where to go using a jump table (slow), restoring the old state from that context (slow), figuring out the type of the thrown object (in many languages, also slow), and then handling accordingly. Each of these steps can easily take 100+ cycles, and may be more.

The math does not work out in favor of exceptions. Neither do the benchmarks in most cases. You do 1 slow thing to avoid doing 20 things that are trivially fast.

Post reply on HN