Hacker News Reader

Comment by chimen | Hacker News Reader

Is Rust that important that you have to place "built in Rust" in the title? Is this like a cult following that we only bet on traffic and interest coming from other evangelists where Rust is the only feature that matter?

4 months ago: " Meilisearch, open-source alternative to Algolia in Rust lands a $15M Series A"

It's not the first time I see, there are at least 2-3 daily submissions reaching the FP in this manner so I'm curious: "built in Rust" = marketing these days?

View on HN

As some people mentioned: I generally expect a higher standard of software when I see "build in Rust".

That expectation includes a few things such as stability and operational UX (ie how easy it is to run and maintain).

And these (in my experience as a Rust developer) stems from the fact that it's much easier to get the MVP and business logic taken care of becau I'm not bogged down by the drudgery of menial tasks that C++ imposes.

There's also a much lower "devtime" cost to adding UX in Rust than C++

Of course, this all holds equally true when comparing Rust to a higher level language like TypeScript and its rich ecosystem, but it does come at higher resources utilisation for the same task too (on average, maybe not always, especially after the code gets JITed).

While I can agree on the argument that rust offer many ergonomics and keep us away on many classes of security and memory management related issues. The quality of UX/DX is more defined by product and design requirements, not much to do with language of choice. Similar like restful api, good or bad is on the designer hand most of the time, not because it's implemented on some esoteric language.

OP said "devtime cost", ie, time to implement. They made no mention or insinuation of quality.

Yeah, but there's usually more time to put an emphasis on UX, as well as the fact that the ergonomics of the language again make it easier to implement the UX.

An argument that I didn't see mentioned: when I see "search engine", I immediately think of ElasticSearch, which is Java, which requires a JVM.

Knowing Meilisearch is written in Rust makes me confident I can probably just run `./meilisearch` and get something working. I can also guess it'll be more resource efficient (CPU, memory) than ElasticSearch. I also *hate* ElasticSearch developer experience, and have had extremely good DX with Rust tools, so I can guess maybe their query language is saner. Maybe all this is wrong, but this is what I'm feeling when I see "written in Rust". So yeah, writing it conveys some meaning.

Hello!

For me, "built in Rust" can be a real marketing argument. Indeed, Rust is a language that has proved its safety in the past. Building a technical product in Rust guarantees stability and safety (no memory issues in general) and performance (no garbage collector issue), so it brings more trust to the users.

FWIW milli does use unsafe in places.

Also I would recommend not conflating no GC and performance. There are lots of reasons for Rust being fast and many have nothing to do with no GC. The main reasons a lot of languages with GC are slower is due to allocating on the heap as opposed to the stack, and in general Rust does a lot of static linking and the compiler has the full amount of information to optimize calls without needing to move stuff to the heap. That's the main perf win.

Actually there are times when GC is more efficient than than automatically freeing memory because GC can batch cleanup work.

I am the co-founder and maintainer of the engine, and I confirm we have some localized unsafe blocks for when we interface with the C library: LMDB.

However, I prefer having a few unsafe blocks that I can review carefully than a single one encapsulating the primary function.

> Actually there are times when GC is more efficient than than automatically freeing memory because GC can batch cleanup work.

Where can I read about these details of software performance? Can you recommend a book?

Safety yes, but stability? It's crash early model wrt stack overflows and out-of-memory errors seems to trade off availability for safety. Not proficient in Rust as a user nor as a developer, so an honest question.

So Zig then?

I'd have chosen JVM for safety, ease of deployment, stability and performance, and Java for maturity of the toolchain (fully aware that required memory would be a concern). With that in mind, can you pitch Zig to me?

> It's crash early model wrt stack overflows and out-of-memory errors seems to trade off availability for safety

It's worth noting that while you can catch these kind of errors in C, very little software actually does so. The only software I'm aware of that does this is SQLite. Your C software will more than likely crash in OOM and StackOverflow situations too.

> while you can catch these kind of errors in C

Tbh C would have never crossed my mind as an alternative for Rust in this case. I guess that says something.

It's important, yes. If it was written in C/C++ I'll fully expect to have my servers pwned due to a memory safety bug that these (and many other) languages don't protect against.

There's a number of technical people with decision-making powers that pay attention. And a part of them prioritize Rust-written projects.

It's a sound (literally) and safe investment.

I don't get the people getting ticked off by the "written in Rust" clarification. Can we finally stop pretending that all programming languages are equal? They absolutely are not.

Milli uses unsafe for what it's worth so it's not as safe as you may think.

I do assume any post with "written in rust" does better on hacker news.

A little unsafe is better than all unsafe.

Question is: do you realize that Rust's `unsafe` is still not as unsafe as C without bound checks, double `free`-s, and others?

Point is, it's still an improvement. I am regularly amazed as to why that factually correct and (more and more) time-proven argument is always skipped when criticizing Rust.

I'm not criticizing Rust, I really like Rust and think it's great, along with the trend of more things written in it.

At the same time assuming you'll never get a memory issue is over the top.

Dunno, I think it should be clear for all experienced devs that the "never" part is still not achieved.

Personally though -- and in my work -- I'll take any improvement that I can. I am sick of reading about yet another important piece of software having yet another memory safety zero day pwnage bug.

Yes, but do you realize you don't have to write C code without bounds checks? You can add your own.

No, I never would have imagined. /s

Point is, many don't do it. And they don't tell anyone. And they deploy important software. And then we get unpleasantly surprised years (or decades) later.

Same argument as with C++: proponents say that the modern C++ is almost like Rust which is cool and I am happy for them, but there are literal hundreds of millions of C++ coding lines out there that will never get upgraded. Having a cop-out like "yeah but the modern version is better" doesn't help legacy code.

Rust on the other hand is super strict for a long time now. They did the right thing.

Sorry, I don't know any important C codebase that omits necessary bounds checks casually. Often times it would not even make any sense. (If you want to iterate over an array, you don't just iterate until infinity, lol.) String manipulation is often wrapped in functions that handle length/storage size/reallocation/etc in the background.

Nobody is saying they do it casually. People genuinely believe they are without fault, which leads to stuff like Heartbleed (and many others; from 2017 to 2020 there was a number of HN submissions about various well-known pieces of software having buffer under/over-flows).

I heard the ideal theory you cite, many many times. Yet many people still do mistakes. How does that fit in your world-view?

For context, an obligatory reference (slash shameless self-promotion) to definitions of safety and safe languages.

https://yoric.github.io/post/safety-and-security/

Not sure what ideal theory you mean. I didn't state any.

Most of the code in my Linux distro is written in C, yet I don't see many segfaults or data corruption in my favorite tools, even those exposed to the internet. It just works. Supposed buffer overflows and double-frees don't affect me daytoday despite 95%+ code I run being written in C, "catastrophic" issues like heartbleed notwithstanding.

People make mistakes, sure. They'll make them with "safe" languages, too. Rust programs are not immune from mistakes. They'll just be of a different kind.

PHP is memory safe, and there were many easily exploited (not just exploitable) vulnerabilities in software written with PHP. (and it doesn't even have escape hatches out of its memory safety)

> If you want to iterate over an array, you don't just iterate until infinity

And yet I am sure we all have witnessed code bases where this was done. At least I and no less than 40 other colleagues I knew have.

The "ideal theory" refers to the old adage of "just be a good programmer, duh" which historically has been proven to be a complete BS.

> Rust programs are not immune from mistakes. They'll just be of a different kind.

Glad we agree on something. I want memory safety problems out of the equation.

Also please don't fight straw-men -- all Rust discussions seem to always spiral from the very reasonable premise of "Rust eliminates a class of bugs" to "But with Rust you can still make logical mistakes!!!!!", and nobody ever claimed the opposite anyway...

Out of curiosity, do you know projects with C code and bounds checks?

Actually Unsafe Rust is arguably more fraught than C because the rules in Unsafe Rust are just as tough as they are in Safe Rust - much tougher than C - but in Safe Rust the language and libraries promise to take care of that, whereas in Unsafe that's on you. So choices which are in fact harmless in C will result in UB in Unsafe Rust.

The benefit is that unsafe passages of Rust are rarer and should be safely abstracted from APIs for use by Safe Rust. Mellisearch seems to often (but not always) provide safety rationales for unsafe code, explaining why whatever is done is OK. I don't understand this domain in enough detail to comment on the quality of the rationales.

Yes and no, unsafe Rust still holds a number of invariants, wherever if you just go on your own writing C you have zero.

I prefer the number of guarantees / invariants that's above zero.

Built in Rust tells me a certain bar has been reached. Tells me the team went through a lot of effort to do their best. And the mature tooling makes it easy for me to evaluate and confirm my assumptions. So yes, positive marketing in my case.

I believe that there is a good reason.

Rust is currently in the process of trying to eat some of C++'s cake (as well as that of Java, C# or Go). The usual response from C++ (Java, etc.) devotees is that Rust hasn't been tried on large projects so it cannot be compared. Which absolutely makes sense.

Each large scale project that demonstrates that Rust can be used successfully in a domain where C++ (Java, etc.) traditionally rules is a step forward for the Rust community.

Also, as with every language, there is a hype period. We're currently in the Rust honeymoon. My personal honeymoon has stopped a while ago, but Rust remains my favorite language for the foreseeable future.

People overreact to hype and anti-hype. Rust is already a useful tool and has momentum. But it's not trivial to get into and it won't replace C++ codebases overnight either.

Based on historical data, a good lower bound for its future could be Ruby. According to TIOBE, Rust overtook Ruby in popularity, while Ruby has maintained roughly the same popularity for years. At worst, I expect Ruby to stay about as relevant as Ruby on Rails. But it doesn't look that way...

I’ve come to see it this way:

If a set of users are using a product only because it is built in X, that user base is most likely the early adopter audience for X and it dangerously masks whether that product has product-market fit or not.

So if a product markets itself as built in X, it is appealing to early adopters of X.

The long-tail of users on the other hand, care more about what painful problem the product is solving for them.

Now, some of the features of X might provide benefits to end users, but the long tail of users care more about those benefits they get rather than the fact that X provides those benefits, and that the product uses X.

An open source project also has to attract contributors. Rust is a competitive advantage in terms of appeal relative to languages such as C, C++, Java, empirically speaking.

This info helps me decide to check out a project. I am familiar with Rust, so any project in Rust gets my attention quickly. If the title didn’t mention the language, I would first check the language used!

It’s an open-source search engine which one could self-host. Language and tooling matter a lot to me and is often deciding factor.

As someone who primarily writes rust for work, it appeals to me because I feel much more confident I can fix an issue myself if I need to. Same with python (which I'm equally familiar with), although I have much less confidence when modifying python code that I won't break something unrelated.

I’ve found that there are a confluence of factors that make “built in rust” important to me.

First of all, Rust is relatively new so this tells me that the codebase is likely new.

Secondly, I think rust tends to attract smart people who like programs to be small and fast. Case-in-point meilisearch is a simple, single binary download.

Both of these together indicate that a project has a higher chance of being freshly written code, by smart people, that is small and fast.

Before I get a bunch of we’ll actually’s, I’m not saying these things are true 100% of the time.

"Built in Rust" carries with it a few positive connotations:

- It's fast. - It's safe. Or more specifically, memory safe, which implies that it will be harder to compromise than similar products written in a different language.

Also, these two points are not hype.

When I see built in Rust I know the software is well built, easy to further extend if it is open source, and probably won't crash or bug out on me.

> cult following

Seems unnecessary to jump right to cult following. Not "cult" but RSS following is often the case where keyword in title makes the difference. I wonder why does it bothers you if it is not relevant for you. What is your problem? Why can people let others be?

> It's not the first time I see

Obviously and your comment is not first complaining about that title contains "implemented in X".

I'm not a Rust dev, but I am the target market for this product and I kinda care that it's written in Rust. That gives me some (possibly entirely wrong) confidence that it's likely to be a single binary, easily installed, fast and relatively safe.

More broadly, if there had been two headlines on the front page today and the other said "Open source search engine written in Node / JS" I would make assumptions about the 7 million dependencies and endless security updates in every single one of them that I'd have to monitor. Obviously I would also skip straight past that one. So yes, the technology choice is important.

For context (and I say that as a Rust developer), please note that Rust has the same strength/weakness as Node in terms of dependencies.

There is ongoing work to strengthen this. I do not know the status.

Thanks. Would I be correct in assuming that there should be less of a burden on me as an end user with Rust though as I only need to update the one binary that I installed?

How did you install the binary? If you installed it from source, you'll need to `cargo update && cargo build`.

If you downloaded a binary or installed it from your distro's repo, generally you just need to update that one binary, yes.

Thanks for clarifying. Yes, I'd typically install a Rust program from the distro's repos.

Usually you would only need to update a single binary, as the dependencies are compiled in.

You may get some libc-issues if you try to run a binary built for a newer Linux on an older Linux, unless it is built to target musl - don’t remember the details 100%

Yes and no - deploying a Node project, I need to install all its dependencies. Deploying a Rust project, I still typically only need to pull down the binary. The general attitude is still to pull in dependencies to do a job instead of inventing your own solution, which I consider a good thing, but not everybody agrees.

Why would this not matter?

Built in Rust means no annoying GC pause, and that's important for a database.

And it also hopefully means less on-heap abuse.

For some reason "built in Rust" resonate with "unbloated" to me, which can be quite appealing for this kind of software.

It is important. Rust projects are infinitely easier to contribute to.

Compared to what?

Python?

For me: compared to projects in languages with less mature tooling and compilers less capable of preventing entire classes of errors by default.

Anything. Legit no language comes even close in terms of how easy it is to git clone something and get it to build.

I'd argue Go projects tend to be easier to build since they require nightly Go builds much less frequently (I don't even remember a project that ever required nightly Go tbh).

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Maybe it's better now with Go modules but the last couple of repos I wanted to contribute a few years back just didn't build. They both were relying on the master branch of some other projects that had breaking changes.

I've had the absolute opposite luck with go. There's a lot of good things made in it but I prefer to not be involved in them. A nightly toolchail for rust is trivial to acquire to the point of it taking only a few seconds

But contributing takes a lot more than just a working build environment.

Correct but getting a build environment easily is such a quality of life improvement.

For those of us who like editing our source code, it's useful to know. And since this is HN, that's a lot of us.

This is Hacker News, where people are ostensibly interested in the technology used to build projects.

Reply on news.ycombinator.com