Shulou(Shulou.com)06/03 Report--

This article mainly explains "Why Rust is not suitable for the development of Web API", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "Why Rust is not suitable for the development of Web API" bar!

Rust is an amazing programming language with excellent CLI tools such as ripgrep and exa. Companies like Cloudflare are using and encouraging people to write Rust to run microservices. Software written by Rust may be safer, smaller and simpler than C++ or C #.

Rust works best if I'm writing a geocoder, a routing engine, a real-time messaging platform, a database, or a CLI tool.

But last year, when I tried to write a pure API service for a traditional website in Rust, Rust was not appropriate.

Missing a lot of small functions.

Rust has a large number of Web services frameworks, database connectors, and parsers. But there are only very low-level components in building authentication services. Node.js has passport.js,Rails, devise,Django and out-of-the-box authentication model. In Rust, you need to learn how to convert shared Vec to the underlying encryption library to build this system.

Translator's note that Vec is a dynamic array that only grows automatically, not shrinks automatically. Different from Array,Vec, it has the ability to add and delete elements dynamically, and can access randomly with O (1) efficiency. All the content items of Vec are generated on the heap space, so you can easily move Vec out of a stack without worrying about memory copy affecting execution efficiency. After all, it is just a pointer on the stack.

Some libraries try to solve this problem, such as libreauth, but it is only just beginning to be developed. There are many similar Web framework issues.

Where's SDK? In mainstream programming languages, you can access Google cloud services, AWS or Stripe through an official library. Most of these official libraries are great. For example, the aws-sdk-js and Stripe libraries are well designed and maintained.

This is not the case with Rust, with only a few third-party libraries, but at the speed of development of these services, can they really provide a high-quality experience?

Some people will say, well, the X programming language is so good that you can write your own SDK on weekends! I have to answer, no.

Rust's ecosystem is very rich in other areas. The crates for building CLI, managing concurrency, using binary data, and the underlying parser is impressive and great.

The Rust compiler is faster than before, but still slow

I've been reading Nicholas Nethercote's blog, describing how the Rust team optimizes the compiler to make it faster!

But compared with other programming languages, building a website with it can be slow. It is much slower than the compiled programming language Go, and much slower than the interpreted programming languages JavaScript, Ruby, and Python.

Once the code is compiled, everything becomes great! But in my case, even the basic API function is incomplete, an uncomplex system-- it took more than 10 minutes to compile. The hardware configuration of the Google code build is poor, it times out every time, and I can't compile anything.

Caching makes sense as long as the cache dependency is not rebuilt. Perhaps reducing dependencies will speed up the compilation of Rust projects. But like serde, JSON and other serializers / deserializers used by almost everyone take up a lot of compilation time. Should we replace serde with something that compiles faster but lacks a lot of documentation and ecosystem support? The trade-off is very bad.

Rust is very complicated.

Rust allows you to think from the code dimension, which is very important for system programming. It makes you think about how to share or copy memory, think about real but unlikely low-probability events, and ensure that they are handled properly to help you write all kinds of efficient code.

These concerns are justified, but for most Web applications, they are not the most important concern, and popular inertia can lead to incorrect assumptions.

Take the security of Rust, for example. This is an important part of its propaganda, and it is absolutely true that Rust promises both security and underlying security-it can work without a garbage collector while preventing memory-based vulnerabilities. When you read "safe", think of Rust's competitor C. Code in the C language can refer to arbitrary memory and is easy to overflow and error. Rust code can be as fast as C code, but it protects memory access without the need for a garbage collector or some kind of run-time check.

However, the memory rules of Rust are not more secure than Node.js or Python, and Web applications written in Rust are not more secure than Python or Ruby applications on the system. High-level programming languages with garbage collectors often pay performance losses to avoid such exploits and errors. Uninitialized memory cannot be referenced in JavaScript because there are no inter-memory references in JavaScript.

Side note: this describes the design goals of Node.js and other systems-they do occasionally have bug. The cache object of Node.js is worth reading.

If you ask some people, they will say that if you use insecure code, Rust is insecure compared to programming languages with memory recycling-- including the most popular Web framework, Actix, which is Rust's Actor asynchronous concurrency framework based on Tokio and Future. Out-of-the-box has asynchronous non-blocking event-driven concurrency capabilities, which implements a low-level Actor model to provide lock-free concurrency models, as well as synchronous Actor. It is fast, reliable, and easily extensible https://actix.rs/), because unsafe code allows the delay of the original pointer.

If you are writing a video game, it is not good to suspend garbage collection. If you are writing microcontroller code, any memory "overhead" or waste is very bad. But most Web applications can save a little bit of memory overhead in exchange for production performance.

The other attributes of Rust face almost the same controversy. Its concurrency feature is amazing, and it's great if you're doing something complex and need to respond quickly. But what if that's not the case? To say the least, Rust's asynchronous ecosystem faces big challenges: there are different asynchronous implementations in a variety of unrelated areas, such as tokio.

By comparison, Python's Tornado and Twisted asynchronous implementation is very strange, Node.js asynchronous implementation is very good, but the syntax is ugly.

I'm sure the async of Rust will be stable and uniform, and it will be easier to operate in the future, but I need to use it now.

The Rust ecosystem is not Web centric.

A lot of people are learning Rust, writing CLI applications or underlying code in Rust, and having a lot of fun. Significantly fewer people use Rust to write ordinary Web applications.

This is an important part of the technology choice: is anyone using the tool? Are they roughly in the same field? Unfortunately, many of the incredibly exciting jobs in the Rust ecosystem have nothing to do with Web application servers. There are some promising Web frameworks-- even higher-level frameworks-- but there is no doubt that their market is small. Even the major Web framework, Actix, has only a few top contributors.

If Rust grows at its current rate, then the Web portion of the community will reach a tipping point, but I don't think enough people are using Rust as a utility for the site. Compared with other communities, there are many companies that are committed to building Web applications using existing tools that are not cutting edge, but sufficient to distinguish mature technologies from new ones.

1 query of Juniper

This part is not just Rust, it also involves the GraphQL ecosystem, and Rust's participation in this ecosystem is an example.

The Number1 problem is something that everyone who builds a Web application should know. The main point is: you have a page of photos (a query), how many queries will you have to show the author of each photo: 1, merge the photo with the author, or query each photo to get the author after retrieving the photo? Or twice, the second time to query the user.id in ids, once to get all the authors, and then reset their photo properties.

Number1 queries usually give priority to the use of databases: for example, changing Number1 queries to a single query results in significant performance optimizations. There are many ways to try and solve these problems: you can write SQL and try to do a lot of work in a single query using CTE and JOIN, as we did in Observable, or a quick way to convert a Number1 query into a predictable query using an ORM layer like ActiveRecord.

Juniper is a GraphQL service for Rust applications. GraphQL is basically defined by the front-end application, not the back end. Give it a series of things to query, and then the application (React or others) sends any query to the back end.

This complicates the back end. No SQL-level optimization is possible-your server is writing dynamic SQL, and optimization can only rely on GraphQL services, but it won't always work. For example, Juniper executes Number1 queries by default, and the solution dataloader is rough and needs to be maintained separately. So eventually you'll have a very fast application layer, but it spends all its time on extremely inefficient database queries.

In summary, GraphQL works very well with the NoSQL database, and it can quickly serve these types of requests. I'm sure there are some specific databases within Facebook that work well with GraphQL, but other companies in the industry rely heavily on Postgres and similar products.

Thank you for reading, the above is the content of "Why Rust is not suitable for the development of Web API", after the study of this article, I believe you have a deeper understanding of why Rust is not suitable for the development of Web API, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.