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

For CLI tools whilst a single binary can be convenient, native-image lets you get those for JVM programs too these days. But it's not always the case that it's enough. In practice you will often hit the need for:

a. Cross platform / cross builds.

b. A way to easily update them for your users (that isn't "everyone mount this NFS/SMB drive")

c. Ability to ship other files e.g. third party libraries written in other languages, config files, data files, readmes ...

d. Possibly, avoiding virus scanners and Gatekeeper if you have users on Windows/macOS.

Conveyor [1] does support distributing CLI tools (in any language) that can then be updated via apt-get, the Windows package manager or Sparkle on macOS. If your language/runtime supports cross-building then it can do it all from your developer laptop, you don't need each OS to build for. The resulting artifacts are single files (deb, msix/exe, zip) and it supports both self-signing and regular signing if you want that.

It provides a few other neat features on Windows:

• One click install that immediately adds new tools to every single terminal session without needing restarts.

• If you want, silent background updates Chrome-style. If you don't, manually triggered updates.

• For JVM apps specifically it automatically configures the Windows terminal to support ANSI escapes, Unicode and other modern features so you can use all the same stuff as on UNIX without needing to futz around with win32 or wrappers.

Unfortunately the little default GUI that lets you trigger updates and add CLI tools to your path on macOS isn't officially launched yet, because it only works for JVM apps and not other types of program. But if anyone wants to try it just let me know, it's easy to activate.

If you don't need any such features then yes, a single binary can be a bit more convenient than a zip. But the number of situations where it breaks down is pretty high and it's not so hard to handle multiple files.

[1] https://hydraulic.software/

I recognize this is not entirely on rustc though.

    new HTMLDivElement()

    struct WebBrowser {
    ...

The verbosity and complexity of `wasm_bindgen`/serialization between JS and Wasm (written in Rust) is primarily the thing I am frustrated at here when I see hundreds and thousands of Rust code. A concrete example: creating a Websocket client in Javascript/Typescript vs in Rust/Wasm.

In general though (outside of Wasm), Rust is less readable.

And with regards to Rust errors, I've found Rust errors related to Tonic and Diesel to be quite annoying/unreadable. The Diesel docs seem to blame Rust for this (can't find the docs for it right now).

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.

I recently wrote an asynchronous microservice in C++, because it needed to use a C++ library I'd already written. Took about two weeks of effort, and clocked in at 1500 loc, not counting tests or the half-dozen external dependencies. I rewrote it in 100 lines of idiomatic Go using nothing except the standard library a few days ago. That's a 10x reduction in both lines of code and development time, although it's a bit unfair because I had already done the C++ version first. That is after giving up on a Rust version that was already weighing in at ~1000 LOC in an unfinished state.

After this experience, I don't think I'd ever use C++ or Rust again for a concurrent web service, unless there was hard real-time latency requirements. Golang is just so much better streamlined for that application, and the standard library is batteries included.

Can you expand on what you mean here? I know you're not implying Rust is faster to move thru a CICD pipeline, so can you tell me what you do mean? I seem to be unable to make a different reading

If Rust is helping you make prototypes and iterate quickly, I’d love to hear how you’re using the language.

Sorry, this is always the wrong choice, which is why it felt so bad.

Writing a UI in TypeScript with any of the major frontend frameworks will not require you to wade through run-time exceptions

Java native GUI toolkits are also far more mature

Python and TKinter and similar stuff is always just awful, I've never seen someone put together anything half decent with that stack

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 Java and Go. There aren't any, and senior people in those communities are hostile to the very idea. (Maybe remembering Java Nashorn?) Maybe the only people friendly to the idea of interoperable back ends are Rust people (where you have libraries like Yew/Sycamore/Dioxus/Leptos that actively imitate JS frameworks).

But yes, your claim is that the only reason to write JS back ends is ignorance and enfeeblement is ignorant and repugnant.

All languages come with tradeoffs in terms of performance, development/maintenance cost and ease of hiring. Most businesses only care superficially about performance, which leaves developer productivity and ease of hiring. Node/typescript isn't terrible in terms of developer productivity, and it's got the best hiring story of any language. Python is good in both those ways too, but since you already need a javascript hiring pipeline for the client it's easier just to use node and hire full stack devs.

I hate configuring typescript and having to deal with bundlers, package.json, esbuild, etc.

But Deno and Bun are just around the corner. What we need is to get rid of this a la carte mentality around tooling and just give everyone Typescript, batteries included, and make it fast.

Then Node really isn’t that bad anymore.

And for all of its faults, NodeJS can be fun compared to something like Java which feels more like doing taxes. Maybe it's the danger. Maybe it's the fact there are so many packages and libraries out there - everyone can contribute! Who knows, but I won't waste my time learning say Rails just to use a "better" backend framework. It's good enough even though I know better. There are way more important things.

Spring boot is great but it does have its quirks. Config and plumbing for instance compare to Nest or Rails doesn’t makes it the best and fastest dev experience. And all the Java extra stuff and it’s ecosystem makes it solid but also old compare to what you can see happening in other languages.

I have Quarkus in my mind though. It looks amazing in dev experience with lib like panache, resteasy etc… and performance are amazing too which comes as a bonus. But there is no dev out there. And I feel that in Java people want to work on Spring Boot because spending X years working on Spring Boot are more valuable in their career than X years on something else that is not really the de facto standard of the industry. So ya not great for hiring talented people…

But NestJS with the JS/TS ecosystem start to be very close to what Rails was in the past. Stuff like Prisma for instance makes everything a breeze. There is almost always a package for the thing you want. Great at websocket too. Can do GraphQL if it’s your thing. Same language as the front end, Nextjs, etc. One of the most performant dynamic languages. And interesting things happening like Deno or using Rust with it. So there are quite some perks to it.

Can’t speak about Django though. But I am wondering how is the dev experience like when we use it for real projects.

I am starting a new project/startup and wondering which one to start it with between all these technologies. And after looking for a long time I can see that they really all comes with their pros and cons.

In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost of the engineering hours sunk into them.

Rust async support was only released in late 2018. Not very long at all, especially if compared to Golang.

Go authors always disliked C++, and got a manager that allowed them to work on their toy language, which eventually became Go.

I've never really had a problem with it, but I isolate such resources behind a wrapper, which makes cleanup easy. I just create a little higher-order function:

  function doSomethingThatNeedsCleanup(fn) {
    const thing = createTheThing();
    try {
      return fn(thing);
    }
    finally {
      cleanUpTheThing(thing);
    }
  }

That's not really an issue with the type system, that's just coincidence and bad luck.

The signature of parseInt is:

  parseInt(string: string, radix?: number | undefined): number

  fn(element: string, index?: number | undefined, array?: string[] | undefined): any

I'm not sure what you expect the type system to do here. It works just fine at catching an actual type error, such as this:

  console.log([10, 10, 10].map(parseInt)

  Argument of type '(string: string, radix?: number | undefined) => number' is not assignable to parameter of type '(value: number, index: number, array: number[]) => number'.
    Types of parameters 'string' and 'value' are incompatible.
      Type 'number' is not assignable to type 'string'.

  > But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...

What portion of the bandwidth is end-user facing and what portion of it is connecting all the servers? Another way of asking this is if I need fewer servers because code runs faster, how much less bandwidth do I need?

Meyer + functional core nets you a great deal of code with no exception declarations and an easy path for unit tests. If it hurts to do stuff it might not be the language that sucks, it might be you. Pain is information. Adapt.

   try {
      ... something ... 
   } finally {
      ... clean up ...
   }

   try {
     ... something ...
   } catch(ACheckedExceptionThatHasNothingToDoWithThisCode x) {
      throw new SomeOtherCheckedExceptionToPleaseTheCompiler(x)
   } finally {
      ... do what has to be done ...
   }

   throw new AnUncheckedExceptionSoIDontVandalizeMyCodeMore(x)

   catch(...) {
      // i forgot to rethrow the exception but at least the compiler isn't complaining
   }

   // i forgot to add a finally cause because I was writing meaningless catch clauses

The unhappy path that you get for free with exceptions is correct for code with ordinary control flow. Most of the code has no global view of the application and is no position to handle errors. On the other hand, for many simple programs, the correct behavior is "abort the program, clean up resources, display an error message" which a sane exception system gives you for free (except for the finally which cleans up the happy path too)

For a complex control flow there is something high up in the call stack that has global responsibility. Imagine a webcrawler which is coordinating multiple threads that call fetchUrl(url) fetchUrl doesn't need to catch exceptions at all, just clean up with finally. What it may need to do is tag exceptions with contextual information that will help the coordinator make decisions. That webcrawler in particular will deal with intermittent failures all the time and only the coordinator is in a position to decide if it wants to retry and on one schedule.

People want error handling to vanish so that they can follow the "normal" flow, but in fact error handling is one of the critical things code does.

The issue is that sometimes the solution to the issue would require the client to get up and get out a shovel, and go dig somewhere or something. When the abstractions break down that hard there isn't really a way for the developer of the code to handle that unless they somehow stuff a full blown AGI into their program, and even then it would be a stretch.

0. https://github.com/tgbugs/idlib/blob/master/docs/identifiers...

If you could it'd mean altering the implementation would automatically alter the API, which would be rather unexpected.

That's why the Java approach is to wrap exceptions and propagate causal chains. The underlying errors thrown by the implementation can change but the advertised exceptions don't, but no information is lost.

If you bend over far enough backwards, and squint a bit, you can kind of do that...

    interface Runner<E extends Throwable> {
      public void run() throws E;
    }

    class Test {
      public static <E extends Throwable, T extends Runner<E>> void test(T runner) throws E {
        runner.run();
      }
    }

That is, you aren't accepting a risk that things will go wrong. You have moved what to do about many exceptions to somewhere else.

This is highly presumptuous. I have written many programs that did not need to handle errors locally, and so exception handlers were only at the very top level (or, actually, just below the top-level usually - but the point is that there were generally few and I had flexibility to decide where to put them). Perhaps you and I write very different applications. But the fact remains that the "almost always" in your statement doesn't hold.

Alternatively line of reasoning: if this was always true then there would be little point to Rust's ? as it would be so rarely used.

No, absolutely not! You only care about errors where you can retry/ignore or log and terminate so you only have try/catch in those areas. So maybe one or two.

In Erlang, "everything may kill your program" is typical method of operation, and there should always be some kind of path to reset your state from known good values.

My best example of this is a UI application that I built that had a single try/catch block around the event loop. It just displayed the error message to the user and returned to the event loop. If they tried to save a file to a network and failed, they got the message, and could just hit save again for somewhere else. No other code needed.

What people mean by "not handling errors" is that the Visual Basic style of "On Error Resume Next" is a terrible, terrible thing to do. The equivalent in modern languages is a try-catch block in the middle of a stack of function calls 200 deep. That function likely has no idea what the context before it is. Is it being called from a CLI? A kernel module? A web server? Who knows!

Just yesterday I had to deal with legacy code that made this mistake, and now it's going to cause a multi-day problem for several people.

It's a ASP.NET HTTP authentication module that simply swallows exceptions during authentication (e.g.: "Can't decrypt cookie"), doing essentially nothing. When deployed "wrong" (e.g.: encryption key is invalid) it just gets stuck in a redirect loop. The authentication redirects back with a cookie, it is silently ignored, then it redirects to the authentication page which already has a cookie so it redirects back, and so on.

There is nothing in the logs. No exceptions bubble up to the APM or the log analytics systems. The result is HTTP 200 OK as far as the eye can see, but the entire app is broken and we don't even know where or why exactly.

That's not even mentioning the security risks of silently discarding authentication-related errors!

This is what people mean by don't "handle" errors. Middleware or random libraries should never catch exceptions. It's fine if they wrap a large variety of exception types in a better type, but even then it is important to preserve the inner exception for troubleshooting.

I've had to tell every developer this that I've worked with recently as a cloud engineer. Stop trying to be "nice" by catching exceptions. Exceptions are not nice by definition and ignoring that reality won't help anyone.

In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs.

EDIT: I just realized my suggestion wouldn't exactly be equivalent to exceptions, in the sense that it wouldn't give stack traces but error return traces, like in Zig:

https://ziglang.org/documentation/master/#Error-Return-Trace...

When writing exception safe code, for me is more important to know which functions are guaranteed not to fail as they will be called in the commit path. Currently I just comment which operations are no-throw and otherwise assume that everything else can fail, but it would be nice to have the compiler tell me.

> But I guess that forcing individual trys makes you think harder about handling individual errors than just pushing the responsibility for error handling up the callstack.

It probably does but it can also make code much harder to read if you have to check for errors after every other line. I'm a bit divided on this.

[0]: https://news.ycombinator.com/item?id=34856910

The thing is if you know enough about why cloning is slow - like a really fat string or a tight loop - you probably also know enough to avoid that. At least in my experience.

There's a ton of rope in Rust with lifetimes, generics, etc. Most if not all generic bounds have implications about the user and caller. Choosing which type of methods you use to avoid allocation while prototyping can be exceptionally difficult to do and be correct.

Refcounting is not that bad imo, and is very very easy. The moment you're at "well we need to beat the performance of X" is probably when you can make better/intelligent decisions about how you allocate, whether to use Arena/Bump/etc.

Also, if you wanted to be in Go/C#/etc you just would. You're using Rust (in this discussion) because you wanted to. When performance is a concern, you can deal with it - but the basic allocation tricks (Arc/etc) don't represent such a significant performance loss that suddenly your Prototype no longer functions.

It's not imposing a space requirement. It's a reminder that these generalizations have limitations. The OP isn't in the embedded space, but they do say "a startup" not "a web startup." There are embedded startups.

The reason I questioned is because in my experience with those languages the 95% problem is not the actual data consistency rather it's locking and synchronization hell that results from needing to make your program threadsafe to ensure data consistency. Rust says, don't get yourself in a situations where you need to do that in the first place, it's not safe. Just clone the data or leak it read only or Cow it.

What Rust does is great, it sets you up so you're never sharing references across threads unless you try really really hard. And that's the source of needing manual synchronization the majority of the time. However, when you do need locks, Rust doesn't do anything to help. In other words, if you copied a Java program to Rust with object instance pointers all over the place, I bet it would feel just as bad in Rust.

So I tend to think of that more as "thread safety" than "memory safety". But we might just be arguing semantics at this point. I agree Rust is far more of a pleasure to work in than Java and C#.