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

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

Post reply on HN
Print view View original

231–240 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#231

Post by ColonelPhantom »

Aeolun wrote: post #219
candiddevmike wrote: post #50

Earlier quoted context omitted.

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

I dunno, if my exceptions would have to be manually rethrown every time, I’d get really cranky very quickly. I don’t think that’s any better in Rust though.

Rust has many convenient shorthands like the ? operator, where `let x = foo()?` is equivalent to

  let x = match foo() {
      Ok(value) -> value,
      Err(e) -> return Err(e),
  }

Re: Using Rust at a startup: A cautionary tale

#232

Post by cropcirclbureau »

bsder wrote: post #8

I really, really, really, don't understand why people want to use Rust for CRUD/web stuff. Every GC language is better than Rust for CRUD/web when you are in the less than 10,000 users phase. I understand why Rust is trying to shove its way into the CRUD/web space--that's where all the programming is. I just don't understand the converse.

I've written a few backend APIs with rust and I have to disagree. Not only have the frameworks managed to get the ergonomics similar to your popular GC lang[0][1], the natural lack of shared mutable state of HTTP handlers means you very rarely have to encounter lifetimes and a lot of the language's advanced features. What's more, now when I go back to work with other languages, I can't help but notice the significant number of unit tests I'd not have had to write in Rust. It doesn't have a Rails and Django but it's an easy pick over anything at the language level.

A note on performance, Rust's the only langauge where I haven't had the need to update my unit test harnesses to `TRUNCATE` tables instead of creating/discarding a separate database per test on PostgresSQL.

I'll also like to mention the gem that is SQLx[1]. As someone who's never been satisfied with ORMs, type checked SQL queries that auto-populate your custom types is revolutionary. With the error-prone langauge-SQL boundary covered, I was surprised just how good it can get making use of the builtin PostgreSQL features. Almost to the point that amount of effort the community's put to building great tools like Prisma.js and feel like a fool's errand (at least so for PosgreSQL).

[0]: https://github.com/alexpusch/rust-magic-function-params

[1]: https://github.com/juhaku/utoipa

[3]: lib.rs/crates/sqlx

Re: Using Rust at a startup: A cautionary tale

#233

Post by ColonelPhantom »

kazinator wrote: post #187
satvikpendem wrote: post #36

I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…

> I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type That's going to get tiresome after about half a day. Exceptions or GTFO.

The only difference between exceptions and Result are that you need to change your return type to Result, and that you need to add a ? after calls that might fail.

There's also a bit of annoying typing stuff involved, but generally with something like the anyhow crate you can handwave that away too.

Re: Using Rust at a startup: A cautionary tale

#234

Post by williamcotton »

nephanth wrote: post #186
williamcotton wrote: post #34

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…

Isn't that the problem that the backend framework + orm combination aim to solve? Like django, or flask+sqlalchemy

If you squint your eyes, sure, but if you’re looking at the details of something like Django or Rails you’re still having to wire up your own analytics, A/B testing, user permissions, headless browser testing… first, why not make all of these language features?

Second, when you wire up a web server module with a SQLite module with a JSON module and translate between them in Ruby or Python you’re taking a really big performance hit. Just think about how many times something is being translated into an unused intermediate state because that just happens to be how the ready-made pipes are sized.

I’m saying, let’s build a bunch of ready-made pipes that are built specifically for SQL backed HTTP servers and with the features that we all seem to use on every project.

The end result should make it easier and faster to build a more performant web application.

Re: Using Rust at a startup: A cautionary tale

#235

Post by bryanlarsen »

foundajob wrote: post #159
bryanlarsen wrote: post #136

Earlier quoted context omitted.

Rust's safety goes far beyond memory safety. Java or C# or Typescript don't force you to handle errors and don't force you to exhaustively match and don't have an ecosystem that prioritizes safety etc.

> an ecosystem that prioritizes safety etc. Idiomatic Rust code is just as cavalier regarding NPEs as Java or Python code. Because the language starts to look really gross when you make your code panic-safe. So you have an `expect` here, an `unwrap` there, and now you're going to have the exact same runtime issues as the more expressive managed languages. No Rust programmer thinks their `expect` will panic, just like…

expect is a lot safer than ignoring a return code.

Re: Using Rust at a startup: A cautionary tale

#236

Post by bryanlarsen »

tptacek wrote: post #139
bryanlarsen wrote: post #136

Earlier quoted context omitted.

Rust's safety goes far beyond memory safety. Java or C# or Typescript don't force you to handle errors and don't force you to exhaustively match and don't have an ecosystem that prioritizes safety etc.

Very little --- I'll go ahead and say, to a first approximation, none --- of that safety has anything to do with software security. The same kinds of bugs that hit Java programs hit Rust programs, with maybe the sole exception of deserialization (which has nothing to do with error handling or type safety). That matters because that's the kind of "safety" we're talking about when we discuss externalities for end-users…

Ignoring error codes and left-pad style issues are common sources of security issues.

Java is more left-pad resistant than Typescript, granted.

Re: Using Rust at a startup: A cautionary tale

#237

Post by pjmlp »

williamcotton wrote: post #34

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…

PHP, Java and .NET have been doing it for 20 years, more or less.

Re: Using Rust at a startup: A cautionary tale

#238

Post by pjmlp »

arcticbull wrote: post #6
paulddraper wrote: post #5

> Rust is awesome, for certain things. > This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices Of course. Use Java/Kotlin or Node.js/Typescript or Go or Python for your basic web services. Easy test: Would you at least seriously consider usin…

The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to your Cargo.toml. I think the assessment is no longer that straight-forward. There's some solid crates for building these types of endpoints now, but an honest self-assessment is required to see if it really meets your needs from a staffing perspective. I'm a Ru…

C++ already has that problem sorted out with Conan and vcpkg.

Re: Using Rust at a startup: A cautionary tale

#239

Post by pjmlp »

WirelessGigabit wrote: post #46
63 wrote: post #15

There's a reason why we see so many articles like "we rewrote x in rust." Rust makes sense when you've scaled to the point that you're seriously considering performance. Sure, starting with rust can potentially save you time, money, and refactoring down the line but only after you've reached a point that few startups ever hit. Otherwise you're limiting yourself with slow development times (compared to, say, Python) a…

The thing with Rust is that you are enforcing so many things from the start. I feel that it is actually harder to write bad code in Rust than it is in say, Python.

You can enforce the same with plenty of strong typed languages with automatic memory management, no need to go Rust for that.

Re: Using Rust at a startup: A cautionary tale

#240

Post by pjmlp »

fooker wrote: post #101

This matches my experience. I have been doing compiler development in C++ for about 10 years, lisp before that and a bit of python more recently. We could not figure out how to be productive in Rust after starting a greenfield project and sticking to it for a month. Luckily this was not a project which requires incremental updates, we were on the verge of rewriting it in C++.

Although I like Rust, C++ keeps being my systems language when coding outside Java, .NET and Web.

Why?

Those ecosystems are built alongside C++ tooling, so no need to add an extra layer of indirection.

I already have the safety from those ecosytems, if I am reaching out to C++ is exactly because I need to do some unsafe stuff, or binding libraries that are anyway written in C++.

Post reply on HN