Rust for a startup

Hi,

A friend and I are trying to launch a Startup. My background is in .NET (Mono/C#/F#), Scala and bare-metal C programming.

The 3 options we are looking at are:

  • Haskell
  • C#/F#
  • Rust

Rust seems to combine the good parts of Haskell and C#

I was wondering whether the community thinks Rust is in a usable state?

I particular the following questions came up:
A. Environment

  • Is Iron (or any other web framework) startup-ready? (The other option is ASP.NET Core with our own routing. I hate reflection based code.)
  • Are drivers for RabbitMQ/Reddis/MangaDB/MariaDB in a stable state?
  • Can we integrate Rust libraries in IOS/Android? Is mobile development possible?
  • How much time does it take to really learn Rust well? I have experience with most languages(C#/Scala/Haskell/F#/C (bare-metal)) so I think I should be able to pick it up fast. But what about other devs?
  • What is the state of tooling? Are there good linters we can use/contribute too?

B. The language

  • Are there any use cases where a bad programmer can make big mistakes with the lifetimes?

In other words, is there an equivalent to null ? Something people always forget but the compiler doesn't catch?

We are actually using it for our startup. Iron is pretty good. Good enough to be used in production, anyway. And Redis and MariaDB/MySQL drivers are stable enough. InteliJ Idea and Atom plugins are really awesome, and I think the tooling is really ready for production.

About the rest of the questions, I wouldn't know what to say. It took me about a month to learn Rust and about 6 months to be 100% confortable using it. I still learn small new things though. And about mobile development, I know it's possible to compile for mobile, but I'm not sure of SDK support.

4 Likes

The canonical linter is clippy.

As long as the bad programmer stays away from unsafe, it should not be possible to make any mistakes with lifetimes. If you find that some bad code compiles at all, that's a bug you should report.

Actually, that's only valid for nightly Rust, afaik.

Yeah, that's kind of the point of "unsafe" :slight_smile: Nice!

There's a lot here! Some quick comments:

There are a number of companies using Rust in production for various things: Production - Rust Programming Language

I think it really depends on the other libraries. The basics of web stuff works, and works well. But if you need to say, integrate with some exotic API, you might find yourself writing a wrapper.

[quote="OzieGamma, post:1, topic:7101"] Are drivers for RabbitMQ/Reddis/MangaDB/MariaDB in a stable state?
[/quote]

Redis has a fairly mature library. I'm not sure about RabbitMQ or MangaDB. MariaDB, IIRC, is MySQL, so there's libraries, though not as far along as postgres.

iOS and android are supported platforms. The experience is similar to C or C++ though: you lose direct access to native toolkits. So it's most suitable for shared logic or apps where you're drawing your OWN UI anyway.

It's easier if you've studied C++, functional programming of some sort, or ideally, both. A bit harder if you haven't. This question is super individual. That said...

One thing we've repeatedly heard from companies using Rust is that because the compiler is so strict, they find it easier to onboard new people: if it compiles, they know that a large number of issues have already been fixed. And error messages help teach people how to fix those kinds of problems.

"tooling" is extremely general. Clippy is the big linting library, and rustc has its own lints too.

If you make a mistake with lifetimes, then it fails to compile.

There is not, we use an Option enum, similar to some of the languages you mention that you know.

Unless you're using unsafe, then at least with regards to memory safety, this would be a bug. Logic errors are of course possible in any language :wink:

1 Like

Thanks for clarifying this! F# and Scala are great but the compiler will let you write null and things like that. Kind of defeats the entire purpose.

I'll try it out for part of our stack then. If I like it, I'll stick to it :slight_smile:

I'm using Rust for my startup.

For me Rust replaces C for new development of performance-critical code and also is a glue between existing C dependencies. For network-bound code I'm using NodeJS just because I'm more familiar with it and it was good enough.

  • Rust is quite stable and reliable.
  • I'm happy with portability and modularity of Rust/Cargo packages. I'm able to build my project as a set of small modules and have them work on OS X and Linux.
  • There's already a number of good Rust packages, and they're in active development.
  • Even where I have to fall back to C libraries, it's easy with bindgen, and writing a thin Rust wrapper can add a lot of type safety and automate memory management. This helps me sleep at night.
  • Rust community is very helpful.

The downsides:

  • Learning curve is steep. It's possible to get stuck. It takes some experience to know how to please the borrow checker and get all the angle brackets incantations right for generics.

If you're racing to launch as soon as possible, consider whether having potentially less-stable, leaky C code (or other language with GC overhead) sooner is more important than having a solid Rust codebase.

If you're past prototype/experimentation stage and now you know what you're building, and now just need to execute it well, then Rust is a good choice.

5 Likes

I haven't thought about this in the startup space, but I have thought about it in the enterprise space, so my observations may not be applicable.

First, I'd say that if you're going it alone, the learning curve will be steeper than if you're immersed in a team that already has exposure, or are able to pair with someone. Teaching others will get easier after you bootstrap yourself with the help of the great Rust community. After working on three or four projects now, I feel like I could shorten the learning period for someone new to Rust that I worked with.

Second, language aside, it's important to know whether the runtime characteristics that Rust offers are important to your domain. If you can get by with a managed runtime from a performance/efficiency/platform perspective, and have hiring constraints that need more flexibility, then I'd pick your favorite managed runtime language, but keep Rust in reserve to optimize. (E.g., Ruby for the server architecture, but native Rust to speed up any bits requiring high performance.) If the alternative is really between Rust and C/C++, then I'd bite the bullet and pick Rust.

I do think there are quite a few things (maybe more so in the enterprise space) where you'd end up rolling your own infrastructure or wrappers. The database driver story is one (assuming, for instance, that you can't pick Postgres and have a database choice already made.) Since you have a clean slate, things like redis and Postgres seem to have mainstream support. But there will be other things you'll need where there's an immature crate that isn't quite right, or only partially complete, and you'll have less lift.

Finally, if there are services isolable from the rest of the architecture, Rust might fit--learn it, learn what its strengths are, then see if that experience makes sense in other pieces you're building out with familiar (or more widely hirable) tech.

I tend to learn things in a very spiral fashion, and it's taken me 3-4 moderately sized projects for the language to feel more intuitive and natural. As I revisit those projects, I'm still seeing cases where I can create better code (and better designs) with concepts I learned on later projects. That's good, but I would plan on throwing some of your early code away as you learn. But as mentioned above, a lot of that was the result of picking up bad habits living in managed code for a long time--once I got back to my C/C++ roots, I found Rust to be a delightful improvement over the C/C++ days AND the managed language days.

1 Like

i dont want to use ruby/python/php/nodejs. I only know nodejs(not a language but a framework I know) anyways.

The appeal of Rust is that its not Haskell while still not having null and having a type system that makes sense. None of the OOP that I never use anyways and lead to misunderstandings. Additionally if my startup works well, we can expand on that to do big optimizations.

The alternatives are C# on .NET Core but even though promising it is in a worse state than rust.
Haskell: Never really tried. I read a lot about it.
Erlang: Never used.

Am I missing any other language where the compiler will save me before I ship to clients? (Thats our main reason right there. We want our clients to depend and rely on our code. I dont want it to be ridden with NullReferenceExceptions and segfaults. Of course logic errors can still happen).

I feel pretty confident Rust might proven to be a good selective barrier to not hire the wrong people in the first place.

As a side note: where is the best place to ask noob questions? I am reading The book and tried to implement map on (A, A). Is there any difference between &u64 and u64 since u64 implements Copy? (I know they have different semantics but they express the same thing!). Can I go from one to the other?

It depends, Ada and Eiffel may also be an option in general although both are not so well suited for database and web stuff that you seem to be interested in.

Here (in the Rust user forum), StackOverflow, IRC channel and Reddit, especially:

https://www.reddit.com/r/rust/comments/503l2w/hey_rustaceans_got_an_easy_question_ask_here/

Thanks !

You can lint using nightly, a deploy with stable.

1 Like

I find the main IRC channel a good place for my noob questions; that said, if you're implementing a map, using & means most anything can be stored, vs only things that can be copied.