Geekly Articles each Day
📜 ⬆️ ⬇️

Rust: "Back to the roots"

Many different goals for Rust come to my mind in the current 2018, by the way, 2017 passed for me very quickly, so I asked myself the following question: if I could choose one single goal for Rust in 2018, then what I chose?


I will be partial, and here is my opinion:


2018 should be the last year when you have to start writing a new project in C or C ++


I am a system programmer ( HPC ) and now, if I have to choose a programming language for work, I can only choose between C and C ++. Rust is not good enough for me, even if I use it every day for all small projects and prototypes.


Why is this goal, and not any other? Indeed, Rust is well suited for many tasks that lie outside the system programming plane. However, this is a very wide area, where there are already quite a number of other PLs, and since
they are sharpened for different tasks - some, for example, use GC - then for some specific tasks they will be better suited than Rust.


On the other hand, the area of ​​system PL is quite narrow and there are only two established relative languages: C and C ++. The communities they form are huge (millions of developers), and these programmers want Rust to be able to
successfully solve the same tasks that they solve, using the two aforementioned PLs.


It's great that the language allows you to safely work with memory without GC, but for C and C ++ developers, using Rust still forces you to make some compromises. So 2018 should be a year of safe memory management without compromise: so that in 2019 none of those who professionally write unsafe code could say: "I cannot use Rust because of X" and at the same time be right . We already have a safe language, this year we have to do this work so that those who need such security have no excuse not to use Rust. Writing a new low-level project in 2019 in C or C ++ should make people raise their eyebrows in surprise and nothing else.


In order to achieve this goal, we need to find out which areas of system programming (financial transaction processing, computing on supercomputers, writing device drivers, programming OS kernels, programming for embedded systems, game development, computer-aided design (CAD),
browsers, compilers, etc.) have problems, evaluate them and fix them to make Rust
most appropriate language for these areas.


We should definitely improve Rust in parallel for use in WebAssembly,
for writing scripts, web development and other areas. However, if I had to
choose one main goal for development this year, then I would choose the system area
programming.


PS: I don’t want to focus on any particular features as the main focus of this note.
language. There are many possibilities of the language, work on which is already underway, but which are still in an incomplete state or unstable.


Related to language:



Related to libraries:



Tools:



IDE (C / C ++):



Cargo:



Platforms:



I note that each of these problems was given many hours of work in the Rust community.
I did not mention ABI-compliant, since relatively little attention was paid to this.


In particular, working on a memory model and undefined behavior is something that can advantageously distinguish Rust from C and C ++, which also have their own memory models, but have no way of detecting undefined behavior (UB). It can even be said that the lack of a memory model makes the language much less secure and predictable than C and C ++, in my opinion.


Many thanks to everyone from the Rustycrate community who participated in the translation, proofreading and editing of this article. Namely: mkpankov, ozkriff, Revertron.


')

Source: https://habr.com/ru/post/346644/

More articles:


All Articles