evans VS rust-analyzer

Note: gRPC services can also be tested from CLI using tools like evans-cli. But for that reflection needs (if not enabled the path to the proto file is required) to be enabled in gRPC servers. This compare link shows the way to enable reflection and how to enter into evans-cli repl mode. Post entering repl mode of evans-cli, gRPC services can be tested from CLI itself and the process is described in evans-cli GitHub page.

Do you mean this one https://github.com/ktr0731/evans ?

I use Evans, it supports gRPC and gRPC-web and also supports reflection protocol.

https://github.com/ktr0731/evans it's the best cli tool I've ever used

Over the holidays, 2021, Postman gifted a fine upgrade to its users: beta support for the gRPC protocol in its API platform. As a Product Manager for Lightbend and helping out on its new gRPC native PaaS for building and running APIs and microservices, I was excited, to say the least. In another, recent blog post, I mentioned my desire to leverage UI test-and-try tools for APIs (my time in the REST API world of Mashery and PubNub was the source of such desire). In that same post though, I noted the lack of several important gRPC features, like server reflection and more robust import capabilities, as blockers; hence, my deep dive, in that post, into the CLI tool, Evans.

And who am I kidding? I'm a CLI-type person. Which is why I was super excited to stumble about Evans. Within minutes, I had gone from installation to trying out TLS-secured APIs and microservices running in the cloud on Lightbend's new serverless offering.

If everything is set up correctly, you should now be able to use evans to access your web server at the load balancer url or even the url for your ec2 instance directly e.g.

After running the server with cargo run, I needed a way to test that the server works. I had heard of an interesting tool called evans, so I decided to use this. It took me a while to figure out the right parameters to query the server, especially because tonic doesn't seem to support gRPC reflection right now, and there are few examples out there.

For testing gRPC we can use evans and need add reflection:

go build 3.62s user 0.76s system 171% cpu 2.545 total

I was looking forward to parallel front-end[4], but I have not seen any improvement for these small changes.

[1]: https://github.com/rust-lang/rust-analyzer

For example, intelephense can show diagnostics in real time, there is no need to save the file to get new diagnostics. But rust-analyzer, the language server for rust, can only update diagnostics after saving the file.

6. Rust Analyzer

The rust-analyzer readme suggests you go here for support request. But even there, you'll need to provide more details to get useful help.

For example: https://github.com/rust-lang/rust-analyzer/blob/master/docs/...

> If you create an LSP, it will work best in VS Code.

Any editor can work just as well as (or even better than) VS Code.

So, apparently the reason why rust-analyzer, the LSP server for Rust does not have persistent caching is because it would make "optimizing initial passes less important".

All I want to know is: Will it have a build configuration pulldown?

I am not a Rust dev. It surely looks great.

However, from what I understand it seems to supply just a parser separate from the Rust compiler (https://github.com/rust-lang/rust-analyzer/tree/master/crate...) trying to keep up with Rust‘s development. So, in principle, it could have been just another treesitter parser plugin, too.

So, again, the LSP framework does not directly provide any magical benefit over a static parsing framework. All the semantic analysis capabilities stem from a good parser.

rust-analyzer > manual > helix > binary > rustup component add rust-analyzer