I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. People will brag about Rust's memory safety, and then you find out that they don't really know how lifetimes work, they just .clone() or Arc<Mutex<RefCell>> everything. Which is totally valid, but Rust is hardly necessary for that.

Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right.

I also want to write code in languages where you don't have to engage in bad software engineering practices to get optimal performance. That usually means aggressive inlining, something that Rust excels at.

edit: the other thing I wanted to mention is that rust's features cause dependencies to be pretty high quality.

If I pass in a slice of something, I'm no longer worried that something ten layers down will change it.

Error handling is explicit and panics are rare, so I'm not worried that dependencies will start throwing exceptions after an update. (This is the reason functions should indicate errors in type signatures—a better ecosystem.)

ADTs mean dependencies represent fewer illegal states internally.

It's just really nice to write code where the bugs are a couple levels up from bullshit like this.

I say this as a Rust enjoyer, but I take the pain because I _really_ want what I'm working on to be fast.

I use Rust often for things that aren't possible in other languages, so I also use it for things that are possible in other languages. (Though I used Python for a production and an art project recently -- with uv it's quite nice.)

I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation. Most of the time I bring this up, someone will suggest something like Swift or OCaml, but I think the part people miss is how even despite all of the complexity that comes with being a systems programming language, Rust really goes out of its way to try to be developer friendly despite that.

Yes, it's a meme that Rust programmers are zealous evangelists and want to rewrite the world in it (which is a bit of an exaggeration in terms of lumping all Rust enthusiasts into that group, but there's certainly an element of truth in it), but no one seems to talk about how _weird_ of an idea it is for a language notorious for having a terrible learning curve to be so popular with people perceived to be lacking real-world experience with the domain. How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? You might chalk some of it up to marketing, but I think people undervalue how much effort is put into the little details in Rust to try to make it more approachable, like error messages, standard library documentation, first-class support for all major platforms, and high-quality introductory materials (e.g. both the original and rewritten The Rust Programming Language book, Rust by Example, Rustlings). I don't think the same experience is there if you want to use Swift on Linux (where the support isn't nearly as strong, and a lot of the fancy new things coming out won't be available) or OCaml (from googling right now, a debate on reddit about "which stdlib should I use as a beginner" is on the first page of results when I search "ocaml std" or "ocaml stdlib").

Maybe a language with a similar syntax, traits, monomorphization, and macros would still be interesting to many people? Would people prefer traits and macros over ad-hoc polymorphism (in the style of C++, which could subsume the macro use cases, too)?

Unfortunately people keep placing all GC languages on the same basket.

And before anyone mentions that it is easy to forget, well those languages have their own "Clippy" to take care of it.

They are only second class in the context people put all GC languages on the same basket, and rather go for the X rewritten in Y blog posts.

Because apparently adding newer languages to CV is cooler than mastering the one they have.

I dream about a Rust subset that's exactly that. What would be even better is if you could just use Rust packages directly with it. Since these libraries already do compile, correctness has been verified.

Jai solves this by having a "context", which includes an "allocator" member by default, whose default value is a standard heap allocator. You can override this allocator member to point to your own allocator, so it's easy and straightforward to have the main server procedure allocate a pool of memory, create a new context with a new allocator that uses this pool of memory, then "push" this context for the duration of the request resolution, then free (or mark for reuse) the memory pool afterward.

I gladly take the whole rust "package" because overall it's just so good, at least for opensource / hobby stuff. I wish there was an equivalent but with GC, to use for work.

I think Rust is especially popular with a demographic that was not previously exposed to lower level programming. Meaning younger programmers (because modern languages are higher level) and web centric programmers (because we're in a boom of web development).

This demographic had a hard time entering systems programming, because while fascinating, its exposure is lower (less jobs, less projects), and entry cost (learning C, or C++<11) is harder.

Rust made systems programming more accessible, and systems programming, just as anything related to how things work under the hood, is fascinating.

Now Rust is hard, as you noted, but not hard in the same sense than C is hard.

C is hard because low level stuff bites you immediately. You can't quite easily just use a random library in C if you don't understand your build system, linkage, etc. If you mess up in C, the compiler will not tell you either, you will have to debug your way out of it.

Rust is different, in the sense that its difficulty is limited to the compiler saying "nope". If you can get the compiler to say "yep", then you're 99.9% of the time safe. Now getting that compiler to say "yep" may take time, indeed, but all in all you most often can just get away with sprinkling unwraps, clones and Arcs all over the place until it works.

In that sense, I think Rusts popularity essentially lies in the fact that it is a way to do low level stuff with a barrier of entry limited to being stubborn in learning it.

Yes it does corrupt memory, there are some crashes, I usually bash C, nonetheless it seems we have too much "safety playground" regarding learning processes nowadays.

> What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin?

I'd argue that Rust has better interop with C, C++, JavaScript, Python, Ruby, and probably almost every other non-JVM language than Java and Kotlin. I'm not sure why you think that getting people to write more libraries is the goal of evangelization; if anything, I think Rust is somewhat notorious for people writing lots of libraries but comparatively fewer full applications.

Independent of interop (which I'm not really sure is as important to understanding why languages are or aren't popular as you seem to imply it is), I don't think the tooling in Java is nearly as beginner friendly as Rust. It's not just about the code itself; handling dependencies and building an application that you can run outside of an IDE are not nearly as straightforward in Java as plenty of other languages nowadays.

My point isn't that Java is bad or that doing things in it is hard in the absolute sense, but that "it's possible to do this in language X" is not the same as "it would be easy for a beginner to figure out how to do this in language X". I think there's an inherent lossiness in trying to distill what people like in a programming language into a bullet-pointed list of features, and it's an easy trap to compare those lists and conclude that one language doesn't have anything novel to offer based on that rather than the entire experience of working in a language.

You can call into JS, Python, Ruby and other such languages from Java like this:

https://github.com/graalvm/graal-languages-demos/blob/main/g...

It's very easy and requires no build-time bindings generation or Python/JS/Ruby runtimes to be installed. You can add Pip dependencies via the Java build system you use, as if they are regular libraries. It will also JIT compile the different languages together as one so the boundaries are optimized, you get transparent exceptions, callbacks work transparently as the whole heap is GCd as one, you can using a debugger in a unified way across languages and so on.

But this is sort of beside the point. Java once had lots of evangelism, partly to help build out the library ecosystem, but that was done years ago and now there are lots of libraries to meet most needs. So as a consequence you don't hear about it as much. This thread is a case in point. Lots of people suggesting rarely used languages like O'Caml or Zig, nearly nobody suggesting more obvious candidates that are used for this task, every day by nearly every big company in the world.

> I'm not sure why you think that getting people to write more libraries is the goal of evangelization; if anything, I think Rust is somewhat notorious for people writing lots of libraries but comparatively fewer full applications.

Wouldn't that be expected then? Rust has had lots of evangelism which has successfully yielded lots of libraries?

> handling dependencies and building an application that you can run outside of an IDE are not nearly as straightforward in Java as plenty of other languages nowadays.

I think this may be based on an outdated idea of how things work nowadays. I have my beefs with Java build tools but if you just want to build and distribute a web app it's easy. Using the stack I'm most familiar with:

1. Starting from a blank computer, install IntelliJ or other IDE of your choice.

2. Go to https://micronaut.io/launch and use the little wizard to pick whatever languages and features you want to start with.

3. Download the generated project, open it in your IDE. All the dependencies are now downloaded automatically including the build system and the Java runtime itself. Likewise if you picked features that use JavaScript.

4. Tweak it, run it. To ship it you have several options, but an easy approach is to add this to your build.gradle file (if you're using Gradle):

    dockerBuild {
        images = ["[REPO_URL]/[NAMESPACE]/my-image:$project.version"]
    }

I think people want to write programs that run on an OS rather than an interpreter.

Not that installing Java is all that hard. apt-get install openjdk is sufficient.

Besides, GraalVM can produce a native executable for pretty much any JVM language/program.

And if free beer is your thing, GraalVM native image or OpenJ9 also produce a regular executable.

That's kind of the whole point I was trying to make above; if one language makes something super easy to do without having to look for instructions compared, that makes a difference in terms of how people will decide whether to learn it. Individually, lots of small quality of life things add up and can make a language that otherwise would be unapproachable way easier to get started with than languages that don't prioritize that sort of thing.

Scala is a great example where I've seen the "best" option being rewrapped libs with scala calls and types rather than a native solution and the dev XP just isn't as good overall.

The dev xp, I sorta agree on, but it has improved a lot.

It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one?

I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.

At this point, I think a new language is more likely to provide this niche than Rust, and I also don't think that has to be a bad thing. Having Rust scoped more to lower-level programming where you're more worried about things like minimizing heap usage and avoiding copying strings or whatever rather than trying to be all things to all users might end up with a better experience in the long run.

This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably.

Sure, rust is primarily a language aimed at systems programming. But it also is so much more (and also a cult).

* Its type system is excellent. Especially the lack of a "null". Even if, like me, you're fine with a GC, the type system alone is worth dealing with this insistent borrow-checker.

* Its multithreading is stellar. The borrow checker helps a lot in making it such.

* Its mutable/immutable model is highly practical. It's what makes the threading stellar and the type system more useful than in any other language I worked with.

* Its "oop" model is uncomfortable at first (coming from Ruby and Java) but forcing the "composition over inheritance" by not having inheritance is probably the best thing that can happen to "OOP". Every solution where I used inheritance, I shouldn't have.

* Its culture of "making the good way the easy way", being opinionated, and a community that adheres to this, is worth dealing with a thousand borrow-checker WTFs. cargo fmt, clippy, etc.

* Its build system that generates binaries that can just be "plopped" onto a server, "chmod +x" -ed, and ran is unprecedented.

I come from Ruby, Java, Javascript (typescript). I do a lot of Python, maintain some go services, have decades of PHP under the belt and occasionally dabble in some C and even C++. I can find my way around in a C# codebase and Objective-C. All have their strengths and weaknesses. Their place and use-cases.

But rust, for me, is the only "ecosystem" that ticks all checkboxes in nearly all situations. It has downsides, and I consider the borrow-checker to be one of them in a lot of my use-cases, but it's something I'm willing to deal with gladly, because rust's other benefits.

the argument was that in early dev and prototyping phases you don't want to write good, clean, correct code but move fast and break things while not caring about edge cases - and this, the author argued - is relatively hard in rust.

making the good way the _relatively_ easy way

But I do like that even in this stage, one is forced to at least make the decision to have terrible things, explicit. Like with 'unwrap()' and 'expect()' littering the code in PoCs and exploratory projects.

For me, a bigger problem in this stage is that I lack the information to make decisions on types. I have this same problem in TS and Java. It's guaranteed that I'll shape types in ways that will prove difficult, or slow me down a lot next week. I'll be spending time refactoring types when I should move on to the next feature.

I guess, but that's just my experience, that statically typed languages are just not well suited for early stage software. When we don't know the shape of the data we'll be pushing around, nor know anything about the shape of the layers, ports, modules and so on. Which is why I'll grab ruby for these kind of quick explorations often. And once the shapes emerge, rewrite it in rust :)

Arguably a louder “plop” due to size, but then you don’t have to chmod.

A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone!

My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.

But wasn't Go a lot more limited in the amount of targets it can build for than rust?

Way to lose readers with memeish statements like that. That said it's in good company of cultists like Smalltalk and Lisp community ;)

> * Its "oop" model is uncomfortable at first (coming from Ruby and Java)

It's OOP in the sense it has polymorphism, and "methods" . It's not OOP in almost every other conceivable way.

It doesn't fit with static OOP of Java. It doesn't fit with dynamic OOP of Smalltalk and Ruby.

> It has downsides, and I consider the borrow-checker to be one of them

I wouldn't want Rust without borrow checker, and never figured this complaint.

Yes, it's uncomfortable and will prevent you from making some legal code.

Guess what? So will a seatbelt. You move too fast to reach something and it snaps you in place.

I am not convinced that the mental overhead justifies the memory safety guarantees yet. At least for a general purpose language.

I didn't yet write a lot of Rust, perhaps more experience trivializes Rusts ownership model.

Wait. What? Neither Java nor Rust limit class/struct per file. You must mean public class per file.

As a fellow Java dev, no it doesn't look like Java at all. Maybe it looks a bit like Kotlin, but only superficially.

I wrote Rust on and off for 5 years, by that time you internalize the borrow checker.

I didn't mean syntax or core lib to be similar, I just generally meant that both languages impose restrictions on themselves which might seem sensible at first.

That said, a good way to think about programs is a series of restrictions, i.e. invariants. Truth be told, only Ada Spark so far really embraced invariants.

And thus, maybe if you're writing something that doesn't need to be screamingly fast absolutely all the time there's a register of Rust where putting lots of things in Rc<Box<T>> is completely acceptable, in much the same way that you might use a lot of impolite words around your friends but you don't in front of your employer.

Show HN: How to program in Rust as if it was old school C++ with pointers

https://news.ycombinator.com/item?id=34067924

This is not remotely a trade off I’m interested in making.

Kotlin is serious about null-safety.

    > I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story.

There is also Visual Studio and Rider.

That’s a dealbreaker in many situations.

F# can usually handle C# things - they put a lot of work into ensuring interop with new C# features - but the languages are from different paradigms so it is sometimes a bit awkward despite F#'s comprehensive OO support.

Personally I struggle a bit with F# because it doesn't have typeclasses, and a language that looks that much like Haskell but doesn't have typeclasses just feels weird to me.

Although it might get them... C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed), so F# could presumably piggyback on that if they wanted.

Why not name it Traits?

I'm in a startup using .NET. We deploy to a variety of targets including AWS t4g (Arm64) instances in AWS as well as x86/64 targets in GCP. All devs are on M1 Macs. Our build pipeline is GitHub Actions Linux runners. Our DB is either AWS RDS Postgres or GCP Cloud SQL Postgres with a mix of EF Core as ORM and Dapper (for more complex read queries).

C# has, over the years, converged with TypeScript so they are very similar[0] (though no Duck typing in C#). Good mix of OOP and FP paradigms borrowed from F#. F# interoperates with C# so it can tap into the larger C# ecosystem.

It's a good platform; very productive. CLI has a functional hot reload (much more limited than Node on JS as the granularity of module replacement isn't quite as good).

[0] https://github.com/CharlieDigital/js-ts-csharp

Don’t know if you intended this joke, but some time before Rust 1.0, @ was the sigil for garbage collection types (@T, like &T these days). Which I think was just reference counting, without even a cycle collector, because was shown to be undesirable before it could be improved.

I'd recommend Haskell as an alternative, but Rust "fixes" plenty of long term Haskell annoyances (especially around laziness by default, concurrency, unsafe std).

Being able to use Arc<Mutex<T>>, Rc<RefCell<T>> and other smart pointers gives you granularity and control over what happens to your memory. I think it's a nice feature to have to mentally reason about your memory usage (incidentally a weak point in Haskell); even if it were on-par with a GC implementation-wise, why use a GC over this?

I like to have control over my code (and I'm probably one of the few who think monad transformers in haskell were a good feature - despite their clunkiness) and I'd pick explicit code over "magic garbage collection in the background" any day. This is not to say I like verbosity for verbosity's sake (eg. think React Redux in JS vs the implementation of the same idea in Elm) but in some cases I think it's justified and it brings extra value.

Who changes their minds about what to do for fun because someone on HN thought it was unnecessary? Doing what some random person wants instead because they want to be “heretical” (because it’s a religion right) sounds like the opposite of fun to me.

But I’ll see you on the next thread about making a Rube Goldberg web server in C++ templates. Or some such very necessary and “approved for prod by HN” thing.

As someone running a fairly cpu heavy SAAS application for users who literally dog pile our whatsapp support forums if it goes down for even a second, Phoenix is pretty damn fast in production. I won't claim its as fast as rust but it will run circles around ruby or python and for IO bound tasks, competes perfectly fine with go. Its never been a bottleneck (database is another story)

The benefits are less obvious if you have less of those constraints: go is way way simpler to write large codebases for cloud applications in and still provide an excellent concurrency support. Python is way better for experimenting.

I guess that if all you do is hammer nails then a multitool is just a hammer.

You gave a long list of benefits of Rust - which should have answered your own question - and then suggested people use an ecosystem with almost none of those benefits.

I’m sure it made sense in your head.

That basically leaves you with Rust's type system. Rust's type system is pretty great, and if we pretend we can't hear the Haskell developers it's one of the best type systems out there. That might seem to get in the way of quick prototyping, but on the other hand it would mesh really well with a framework like Django. One of the great things of Django was that you define your data schema, and Django takes care of both the database and a passable admin area. I'm sure you could greatly expand on that principle, with data types driving a lot of behavior and conveniences that the framework just handles for you.

Maybe a bit like .NET, but without the enterprisy coat of paint and without putting dependency injection everywhere.

All of them with better ergonomics for Web development.

Last time I looked into OCaml, I struggled to find a way to interact with the database in a type-safe way, I never figured out which standard library I was meant to install, I was being encouraged to use 2-3 different project management tools (Dune + Esy + OPAM), and I gave up on writing tests. But at least there's a garbage collector!

I realise these are all problems that I'll wrap my head around over time, and eventually they'll seem completely trivial to me, but the introductory documentation on getting started as a professional (and not as a first-year student doing a French-language compsci degree, which is what most of the documentation assumes), is pretty dire.

Meanwhile, much as I'm sure I overuse `.clone()` and `[A]Rc<_>`, the ownership model of Rust is deeply useful. It's something I often find myself missing in Javascript - not necessarily because I want to produce the most performant code, but because it's useful to understand the lifetimes of the objects I'm keeping around. Am I accidentally storing a reference to something in a closure that I forgot about? When this object gets deleted, have I checked that it's the last possible reference to this object? Etc.

Like, I don't think everyone needs to learn Rust. It's a great language, but there's lots of other great languages out there, depending on your personal and business contexts. But I think this idea that Rust can and should only be a low-level language feels absurd to me. It is a fairly ergonomic language with a fantastic ecosystem, a powerful type system, and an ownership model that will be useful even if you do try and opt partly out of it with GC-like wrapper types.

Yes they do, unless you get your editor to magically type `.clone()` and `[A]Rc<_>` all over the place.

Not to mention they don't need unsafe, or 3rd party crates to handle graphs.

Additionally, all of them have interpreters and REPLs alongside their compilers, streamlining the code-develop-debug loop.

In fairness, I think a lot of this comes down to familiarity. I'm fairly familiar with `.clone()` and Arcs at this point, so they don't really change much in terms of ergonomics. Usually their usage is fairly obvious, and quite often my editor literally does magically type the `.clone()` calls through LSP fix commands. It's the same as, say, OCaml's insistence that recursion is better for complex loops than, say, `while` — it's not necessarily wrong, but if you're unfamiliar with the idea, it's going to feel weird.

More important to me is the ergonomics of the broader ecosystem, and that's something that Rust has done well, that other languages just don't seem to be interested in at all. Things like integrating testing into the standard workflow; working hard on getting the stdlib in good condition; having an excellent ecosystem of well-documented, usable libraries; or designing error messages and lints with a focus on getting people to understand how the language works and not just what they've done wrong this time. I've really missed that stuff whenever I've tried MLs. You mention, for example, REPLs, but a unit test is basically a saved REPL session that you can repeat every time you make a change.

I'm not trying to convince anyone that Rust is the best language in the world or something. I really like it, but I find it helpful to think in terms of object ownership even in non-Rust languages, and I can understand why for other people that sort of approach is unhelpful. But I would love to see other languages embrace its ergonomics more, or new languages created with that as their focus.

But... that's what I do in a unit test anyway. A unit test is essentially a REPL session that I've frozen in time, can replay whenever I want, can debug, can trigger a fresh run whenever changes occur (which isn't quite hot reloading, but often a darn sight more useful), and can keep track of and share with my team. Which means I'm not just able to explore things on my own, but I can see the explorations that other people have made with their code.

As for unit tests being more usefull, depends on how much one is willing to wait for them to run in Rust, given its compile times.

Albeit it makes the process easier compared to a really shittly written code without strict typing, but against good codebases, it takes the same amount of time.

If you think about correctness of a program, (i.e for any combination of given input , it changes a state in a determinstic way, including no state change for invalid input).

Strict typing is one way to accomplish this. The cpu does not give a shit about types. It cares about memory registers and locations. The unique code built into the compliers/transpilers is the thing that validates the correctness of the program in this case.

You can move that code into the testing suite without relying on the complier, and just do testing. Generally, given competent programming skills, this takes about the same amount of time as designing a well structured program - your tests are pretty much your design document for the thing itself.

I think you're arguing that tests and types can both be used to check a particular case for correctness. Sure, this is true. However "moving type checking code into the test suite" means nothing—that would just be type checking.

When you make a code change, there's a difference in the kinds of feedback you get from your tests and your types. Tests usually cover business logic or stories—things that you want or don't want. Types ideally cover everything. They check every operation applied to a given piece of data. Of course types are rarely precise enough that they can catch every logic bug (e.g. strings with semantics not encoded in types, like email addresses).

This is just scratching the surface. You might just have to try out both to get a better sense of how they feel to work with.

We basically ended up creating a tool+language spec that would let us define the mapping of input to output sequences. We wrote it in such a way where we sat with scientists and pretty much mapped all the possible cases that they could think of for valid inputs and what the code should produce.

Then this tool would basically write automated tests for us, in such a way as to not only test correct behavior, but also do combinations of inputs out of order, fuzz testing, and so on. We ended up making it also check memory state, to ensure that there was no memory leaks, and analyze the memory space for required data or data that should not be there.

In the end, whenever someone was developing anything for this software, they would basically just run the tests, and it would be very good at catching possible errors, mostly on the negative side (i.e for a fuzzed input, it would result in an output that should be an error).

We could have done the same thing with a typed language, but it would have to be very strict typing to the point of something like CoQ, and it would have taken us probably the same amount of time to write that.

[1] yeah, there are type systems like lean, coq that can do both, but the proving process is just currently not realistic for everyday applications

in my experience it doesn't

1. refactoring are in my experience still much faster (and reliable doable) with rust compared to e.g. Js/Python even in presence of a lot of tests. This is a bit less of an point with Java/TS/C# etc. through I had some very bad (and also some good) experiences with refactoring in TS. And to be clear I don't just mean pure refactoring but any larger changes affecting many places in code which might be needed to idk. impl. some feature.

2. especially with Js,Py and similar there are way to many edge cases you can have to test for all of them. Sure most times this mainly matters when writing libraries but on larger projects does apply too. Stupid stuff like you expecting a `list[int]` and someone (externally i.e. outside of your tests) passes a `dict[int, int]` and that happens to work as you current impl. is only linearly iterating it as if it's a `Iterable[int]` but then you change the impl to require a `Sequence[int]` as you access it by index in some corner case and now you customer has really strange subtle bugs. Can't be caught by your tests as the problem is the customer but still breaks the customer which is always bad and can't happen with rust. Sure also won't happen if everyone uses type annotations and mypy correctly and strictly. Through you can't rely on your customer using mypy, but you can rely on your customer running compiler checks (as it's the only way to build the code). Also while mypy is much much much better then pylance it is still prone to issues as both `cast` and `ignore[..]` are things you sometimes need but which easily can hide bugs if the code changes (cast doesn't pin the "from" type and ignore is scoped by place not by what is wrong)

Except you can’t test for correctness. Tests can’t prove the absence of bugs.

Rust has exceptions, they are just named Result and people just as frequently decide not to handle error results as not catch exceptions in my experience.

Typed exceptions are just as good as what rust offers IMO.

A simple example of the (many) things you can't do in TS:

    struct StateStart;

    struct StateEnd;

    impl StateStart {
      fn foo(self) -> StateEnd {
        StateEnd
      }
    }

    fn main() {
      let start = StateStart;
      let end = start.foo();
      let another_end = start.foo(); // this won't compile
    }

I miss more features of Rust in TS that features of TS in Rust. All the time.

But TS has so many dark magical patterns that I'm still hoping to be proven wrong.

How does TypeScript's type system prevent shared mutable state?

It doesn't.

Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over)

> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?

You can typically accomplish the same thing with enums/proc macros/traits of course—with the additional benefit that the type system is designed to be sound. Soundness is an explicit non-goal of TypeScript[1], so once you start layering on those kinds of overly-clever types, you soon reach a point where you're just lulling yourself into a false sense of security.

[1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency.

> usually

So, not always. That is - TypeScript's type system contains features that Rust's does not have.

If you ever put an await anywhere in your code, an arbitrary amount of random stuff might run between the time you await and the time the awaiting finishes.

Same applies to older mechanisms like callbacks and promises.

Race conditions are more rare there because as long as you aren't doing any IO, there is indeed no concurrency, so you can't e.g. get two threads trying to increment a single variable at the same time. They can still happen, though, especially if you accidentally do a partial change to an object, put it in an illegal state, and do IO before you finish that change.

Confidently asserted, but very debatable.

> The vast majority of errors caused by shared mutable state are related to concurrency.

Concurrency, like async-await, you mean?

> TypeScript's type system contains features that Rust's does not have

Sure, and likewise Rust's type system contains features TypeScript's does not have—for example, just try expressing anything close to traits with TS's type-erased generics. Since the feature sets aren't the same, I suppose it's a matter of opinion which type system is preferable. But I know which one is more helpful for me for sure (especially considering the aforementioned soundness issues).

Simply so untrue I’m not going to elaborate further

idk. many years ago through stuff like service workers, having shared memory through TypedArrays and similar.

But for the discussion more relevant is that shared mutability constraints do not only matter with threading, they matter with any form of concurrency (like JS async/await/promises and before that callbacks). And even without that you still have other single threaded and single tasked concurrency with the classic being changing a collection while iterating over it. So even without classical forms multi threaded concurrency still very helpful.

> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?

Rusts type system is mainly nominal typed while TS is mainly structural types so it's a bit hard to compare. Like if you nitpick then you could maybe argue that based on TS type system having "features rust types system doesn't have" it's more powerful (but you also could argue the other way around it depends on how you count them). But that would be misleading as it ignores that not only are they two fundamentally different approaches to typing it also ignores that some features are implemented through other means outside of the type system.

Practically having used both I can say that while TS has some things in the typing which are a bit cumbersome to do in rust when it comes to helping me having correct code in context of changes, especially larger changes, and especially libraries Rust still yields better results in my experience. Naturally assuming you don't abuse the TS in either case.

(and to technically answer the question, type unions == yes but different, intersection == no but also make little sense in rust, interfaces == yes but different, mapped types ~= depends on the aspect in some yes and better then TS in other no but implicitly through derives so worse then TS, conditional type ~= again handled through different features depending on usage either associated types or feature gates)

For everything else, there’s Go IMO.

For me, a clear advantage of rust (and also Go) over Python (or Ruby, or PHP) is not having to deal with runtimes. With Python, the server needs all sorts of setup. Exactly the right version and configuration of the runtime. Pip. Or Pipenv. Or Pyenv. Or Conda. Or... and so on. Then it needs the libraries installed. Some of which must be built natively; so just packaging them in some CI is often not even possible. These native builds need lib-something-dev packages. Then with an update of the underlying server, suddenly nothing works anymore.

Having a single binary that I can plop onto almost every linux box and which "just runs" regardless of the exact version of Ubuntu, cargo, rust-toolchain on the server/hosting machine is invaluable. I'm so done with maintaining the fragile card-house that my Ruby-on-rails apps require, or that my python/flask services need, that my nodejs insists upon: with rust this is no longer needed.

And yes, docker/containerization is a solution to it. And yes, I know about the options to package up a python app with runtime included. But all that adds extra complexity. It merely makes it easier sometimes. Not simpler. And it inevitably makes troubleshooting, upgrading, etc even harder in some future.

Eh, Rust's type system isn't one of the best out there. It's lacking higher kinded types, etc. It's abilities in type level programming are frustratingly limited as well.

So it's advanced aside from from Haskell, OCaml, Idris, Scala, etc. Compare to OCaml's effect system for an advanced type system feature.

And with that in mind, I do agree with the GP. Scala's type system, for example, is full of warts (well, Scala 2; I still haven't tried Scala 3). Rust's is cleaner and has fewer gotchas. I very rarely have to look up how to express something in Rust's type system, but I remember when I last did Scala, I often ran into weird type-system related errors that I just didn't understand and had to dig into to figure out. Some of that, sure, is likely due to Scala's type system having more features, but some of that is because it's just more complex. And I would usually rate something of lower complexity as better than something with higher complexity.

Lots of other small annoyances like the whole tuple situation have also been fixed.

EDIT: Plus: intersection types, sane macros/inlining, etc.

Unfortunately (for me), some of our projects still have to cross-compile to 2.x, but that's irrelevant for greenfield. I'd give it a whirl -- it's a great improvement over Scala 2.x.

> See, if I want to make something for the web, I could use Django but I don't want that. I mean, Django is for building serious businesses, not for building silly non-commercial things!

Personally, I spent the first decade of my career switching between languages, believing that I should use the best tool for any given job. I spent the last ~five years doing mostly Rust, and I've learned that there's a level of mastery of a language you can never quite reach if you're always context-switching between them, especially a language as “deep” as Rust. This means I write things in Rust that Rust is not the best language for.

In the past I’d try to justify why I’d done something a certain way when another way would’ve been faster / better / cheaper, but I now realise that (at least for personal pursuits) an acceptable answer to “why?” is simply “because I wanted to”.

If I were putting together a web development team, would I recommend Rust? ...probably not. But that's because I'm putting together a team, not a playground. I'm paying people. I want to use common, well-supported, time-tested methods, unless steering away from that is truly needed to make the project successful. For web dev, that assuredly ain't Rust ("yet," some may add).

But for me? Just for me? I think it's a language I'll always enjoy. Within that line of thinking, I do feel there's room for better web dev tooling in Rust, though what's already there is probably enough to at least get started.

Let's just say different people have different opinions on this one. Personally, I find Go to be a big regression in language design given modern PLT research, and wouldn't use it unless forced (e.g. terraform providers). Other people have other opinions: a friend I respect a lot has great success in the Go community.

I'm telling you that because if, as a Go enjoyer, you're baffled by the writings of a Rust enjoyer, it's very likely the result of different perspectives rather than silliness. And if your conclusion is "just use go", you're probably the one being silly.

The person likes writing in Rust, and would like to have a batteries-included web framework so they can tie together a web app quickly on the language they like to use... And I know they did not include https://rocket.rs/ in their 'existing ecosystem' section.

What you're asking for is a DSL built on top of Rust for the purpose of creating web apps.

It'd be cool to have an out of the box "90% of what a website needs" toolkit that means writing your 10% custom code/secret-sauce in a modern code security obsessed language. Even if it is opinionated and "batteries included" in ways that make some things annoying.

I have built many projects that start with a WordPress install, to piggyback it's CMS, user management, and admin backend. I then inevitably end up making a choice between writing the project in php, or jumping through hoops to use the WP features (like auth and user accounts) in some other language that's more appropriate to the task at hand.

> What you're asking for is a DSL built on top of Rust for the purpose of creating web apps.

I don't think that's necessary, personally, but if someone really wanted that, I'm sure they could come up with something that can be wrapped in a Rust macro invocation, that gets expanded to something smaller and faster (compiled-code-wise) than anything you can get in a Rails app.

In other words, I find it faster to produce working stuff in Rust and much faster to produce quality stuff.

Obviously I’m just one data point.

An explanation for "why bother try to have a low effort web server in Rust?" that I haven't seen mentioned: Once you're past the introductory phase of being familiar with Rust, if you don't need to pedantically handle every error case, it can be _very_ simple.

A low effort "doesn't have to be very flexible" web server would be terrific & easy to use in Rust.

Having said that, I'm not aware of the actual offerings available. Maybe there is one, other posts have suggestions.

That said, what exactly was the issue you had with Go?

(Not only because I think competition is good, but because I really do not enjoy writing Go.)

Go look at job boards. The competition for Go, Rust, Django or whatever is Java+Spring. That's pretty much the industry standard unless you're in a Microsoft-only shop.

Edit: I read other comments. Disregard my replies then, because this is likely intentional. Luckily, I had enough interactions with Java communities to know that many other people there are not biased.

I don't see how people can "love" writing rust either. I love a lot of things about Rust and its ecosystem, but the syntax day-to-day isn't one of those things.

Saying that and then use Rust is like saying, "I want hassle-free driving, that's why I drive a car with a 7-speed manual shift".

If you want a full-auto, then use it. "Minimal effort" is the reason why people wrote garbage collectors in the first place.

My problem wasn't so much dealing with memory management, but trying to put an upper bound on memory usage and failing nicely when that upper bound is met. I generally don't like working with garbage-collected languages, or having to use some niche application-specific language when I can just use a general-purpose language instead.

I've had a lot of fun playing with it, it was very nice & simple to use. It's also foundational in the Rust ecosystem, so it's well maintained.

“I like to play basketball but tbh I like to put in the minimal effort”

“Then why do you even play basketball? It’s a physical activity…”

The first thing takes precedence over the other.

> If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the standard library for what you want to do. Or… use Django as you suggest?

Just do what someone else dictactes. The surefire way to self-expression and Fun Town.

> Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?

You forgot to capitalize. The Cult. Since you apparently want to look silly.

There’s a difference between what you do in production (at a job presumably) compared to what someone does to be “silly”.

Rust is great, high level language that's super convenient for implementing arbitrary algorithms on arbitrary huge, complex data structures safely and quickly. Value semantics is absolutely unique and useful. The system of traits and standard library using traits like Ord or Hash means that it's enough for your type to implement one of those and suddenly it can be a key in a HashMap or BTreeMap and can be a part of even larger and more complex data structure. Adding a web to that easily could be super useful.

Seems like a good enough reason to use it to me, but perhaps I’m just another cult member.

> we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++

I think rust is just safer period, regardless of your level of expertise or background. Or are you saying that every memory safety bug was written in by someone inexperienced?

Not to mention the concept of “sharing code.” See I may write garbage tier rust code that basically glues together a bunch of libraries, many of those libraries are written by programmers way better than me, and I can gain performance and safety from using their work. The performance difference between languages like Rust and JS is huge, even if I, tainted by my background in Java, write dogshit code.

I think you're reading too much into that and creating conflict where there isn't any. GP just meant that they had a bunch of interpreted language OOP developers (probably Java or C# or something like that), and they wanted them to start writing code in an AOT-compiled language (yes, I know about Graal native image; not the point). And that teaching them Rust is probably going to result in safer code than if they were to teach them C or C++.

That shouldn't be a controversial statement.

JIT vs. AOT is not the same as being an interpreted language. For most applications, running on top of the virtual machine is a good thing, I don't see JVM developers turning to different languages just to escape the JVM, outside of some niche projects.

I was trying to out that wanting to take the easiest path was rather contradictory to working with Rust.

> I think rust is just safer period, regardless of your level of expertise or background.

Yes, I’m not sure how you think I was implying something different. We (specifically) adopted it because it was easier for our (specifically) developers who weren’t familiar with low level languages to work with compared to c/c++.

> many of those libraries are written by programmers way better than me

You shouldn’t sell yourself so short in my opinion.

If Rust had a good full-fledged web framework, it would enable more developers to justify why the business should use Rust. The culprit is that it would require a heavy education budget, but it would in turn enable the business to allow using Rust for other parts of the business which could benefit from Rust, e.g. middleware, small components, CLIs and systems programming in general.

Having a little bit of Python here, a little bit of Go there and a bit of Java elsewhere can become chaotic. There is a huge benefit for a small company to only have 1 programming language everyone agrees on using.

If your goal is easy web development, Django, Ruby on Rails and Laravel are frankly going be extremely hard to beat. I prefer Go with templates, but that’s still much worse than those options.

I really like the Rust tooling and I like exhaustive pattern matching. Python post-dev debugging time is probably 10x vs Rust. That's why I choose Rust.

Because you like the Rust ecosystem?

Because you enjoy developing in Rust?