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

Meilisearch 1.0 – Open-source search engine built in Rust

blog.meilisearch.com

Post reply on HN
Print view View original

131–140 of 186 posts

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#131

Post by tialaramex »

pdimitar wrote: post #42
rockwotj wrote: post #33

Earlier quoted context omitted.

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.

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.

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.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#132

Post by pdimitar »

megous wrote: post #130
pdimitar wrote: post #93

Earlier quoted context omitted.

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?

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…

> 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...

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#133

Post by pdimitar »

tialaramex wrote: post #131
pdimitar wrote: post #42

Earlier quoted context omitted.

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.

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 abstract…

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.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#135

Post by zX41ZdbW »

You can query Meilisearch directly from ClickHouse with the integrated table function: https://github.com/ClickHouse/ClickHouse/pull/33332

This feature was a student project, and I'm not sure if it will find its usage. If you are using Meilisearch with ClickHouse, or if you think this feature is worth something, please let me know.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#136

Post by Keats »

hu3 wrote: post #74
adamnemecek wrote: post #69

Earlier quoted context omitted.

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.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#137

Post by dividedbyzero »

adamnemecek wrote: post #69
dividedbyzero wrote: post #18

Earlier quoted context omitted.

Compared to what?

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

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

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#139

Post by kmac_ »

tempest_ wrote: post #13
kacy wrote: post #7

We’ve been using a Meilisearch for the last six months or so and have been delighted with its performance and usability. It uses a fraction of the resources as Elasticsearch, and the language support is extensive and very active. That being said, our cluster is much smaller than other ones I’ve worked with in the past, so I can’t comment on its reliability at massive scale. I’ve also been very impressed with how acti…

This is the thing I find when people post "ElasticSearch Alternative". 80% of ElasticSearch's value add (wrt search anyway) is all the clustering and frame work that allows you to span the search over tens or hundreds of machines "easily". I think the same is true here. Probably the comparison should be with the underlying search libraries that ES sits on. I suppose this comparison makes sense in a world where most p…

Yeah, Elastic also brings advanced aggregates and filters, Kibana, nice UI where you can explore data and create dashboards easily and tons of bigger and smaller features. But in some areas both products are comparable.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#140

Post by scop »

Congrats! Question for the team as I see a possible discrepancy on the website.

The "Comparisons" page says there is no limit for number of indices (https://docs.meilisearch.com/learn/what_is_meilisearch/compa...)

However, the "Limitations" page says there is a limit of ~180 indices (https://docs.meilisearch.com/learn/what_is_meilisearch/compa...)

Can you clarify what, if any, are the limitations of # indices?

Post reply on HN