# Elasticsearch Rust Client: Update 02 Jun 2017
**URL:** https://discuss.elastic.co/t/elasticsearch-rust-client-update-02-jun-2017/88014
**Category:** Community Ecosystem
**Created:** [June 2, 2017, 2:57am UTC](https://discuss.elastic.co/t/elasticsearch-rust-client-update-02-jun-2017/88014 "2017-06-02T02:57:19Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@KodrAus](https://discuss.elastic.co/u/KodrAus)
#### Post date: [June 2, 2017, 2:57am UTC](https://discuss.elastic.co/t/elasticsearch-rust-client-update-02-jun-2017/88014/1 "2017-06-02T02:57:19Z")
Hi everyone!
I've just pushed out a new release for the Rust client I work on that comes with a bunch of ergonomic improvements when making requests.
# See
- [GitHub Repo](https://github.com/elastic-rs/elastic)
- [Docs](https://docs.rs/elastic/0.12.2/elastic/)
# What's it about?
Rust is a native language without a garbage collector, that's targeting the same spaces as C/C++ but comes with a lot of nice modern features.
The goal of this Rust client is to offer a nice, high-level API like you'd expect from any language but also give you full control when you need it so you can talk to Elasticsearch in any way you need.
# Changes
- Added some initial builder methods for common client endpoints that are easier to use and easier to read. Builders for the Query DSL itself is still a non-goal at this stage though.
```auto
// A simple query string to search on
let query = "match me";
// The Query DSL body, just plain old json that interpolates locals
let body = json!({
"query": {
"query_string": {
"query": query
}
}
});
// Do the search request on all indices
let res = client.search::()
.index("_all")
.body(body.to_string())
.send()?;
// Iterate through the returned hits
for hit in res.hits() {
println!("{:?}", hit);
}
```
- Lots of documentation and some more examples. The client design should hopefully be much clearer now
- Got the groundwork in place for a proper async client
- Lots of API cleanup, bug fixes
- Some dedicated infrastructure around `_bulk` responses, because they're proportional in size to the number of items in the request and there's potentially a lot of duplicated data. So you can configure the allocating types to avoid a few new `String`s for each bulk item, or only keep bulk items that failed
# Up next
- There's plenty of the document API that needs implementing; range types, date math etc
- Start thinking about connection pooling
If anyone has any feedback I'd love to hear it 🙂
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 5, 2017, 9:46pm UTC](https://discuss.elastic.co/t/elasticsearch-rust-client-update-02-jun-2017/88014/2 "2017-07-05T21:46:21Z")