Программы на Расте, которые мы заслужили: https://github.com/MonkeyLog/BrewStillery "BrewStillery is a brewer's, vintner's, and distiller's calculator. It has a multitude of great functions, such as calculating ABV, determining carbonation, and total sparge water needed."

Нашёл единственную работающую библиотеку для XMPP: https://github.com/astro/tokio-xmpp Но её даже на crates.io нет

Ещё одна purerust GUI библиотека. На этот раз даже работающая со stable версией: https://christolliday.github.io/limn/limn/index.html

https://www.mercurial-scm.org/wiki/OxidationPlan "Using Rust in Mercurial This page describes the plan and status for leveraging the Rust programming language in Mercurial. Why use Rust? Today, Mercurial is a Python application. It uses Python C extensions in various places to achieve better performance. There are many advantages to being a Python application. But, there are significant disadvantages. Performance is a significant pain point with Python. There are multiple facets to the performance problem: Startup overhead General performance overhead compared to *native* code GIL interfering with parallel execution It takes several dozen milliseconds to start a Python interpreter and load the Mercurial Python modules. If you have many extensions loaded, it could take well over 100ms just to effectively get to a Mercurial command's main function. Reports of over 250ms are known. While the command itself may complete in mere milliseconds, Python overhead has already made hg seem non-instantaneous to end-users. A few years ago, we measured that CPython interpreter startup overhead amounted to 10-18% of the run time of Mercurial's test harness. 100ms may not sound like a lot. But it is enough to give the perception that Mercurial is slower than tools like Git (which can run commands in under 10ms). There are also situations like querying hg for shell prompts that require near-instantaneous execution. Mercurial is also heavily scripted by tools like IDEs. We want these tools to provide results near instantaneously. If people are waiting over 100ms for results from hg, it makes these other tools feel sluggish. There are workarounds for startup overhead problems: the CommandServer (start a persistent process and issue multiple commands to it) and CHg (a C binary that speaks with a Mercurial command server and enables chg commands to execute without Python startup overhead). chg's very existence is because we need hg to be a native binary in order to avoid Python startup overhead. If hg weren't a Python script, we wouldn't need chg to be a separate program. Python is also substantially slower than native code. PyPy can deliver substantially better performance than CPython. And some workloads with PyPy might even be faster than native code due to JIT. But overall, Python is slower than native code. But even with PyPy's magical performance, we still have the GIL. Python doesn't allow you to execute CPU-bound Python code on multiple threads. If you are CPU bound, you need to offload that work to an extension (which releases the GIL when it executes hot code) or you spawn multiple processes. Since Mercurial needs to run on Windows (where new process overhead is ~10x worse than POSIX and is a platform optimized for spawning threads - not processes), many of the potential speedups we can realize via concurrency are offset on Windows by new process overhead and Python startup overhead. We need thread-level concurrency on Windows to help with shorter-lived CPU-bound workloads. This includes things like revlog reading (which happens on nearly every Mercurial operation). In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial's development velocity. Today, when performance is an issue, Mercurial developers currently turn to C. But we treat C as a measure of last resort because it is just too brittle. It is too easy to introduce security vulnerabilities, memory leaks, etc. On top of vanilla C, the Python C API is somewhat complicated. It takes significantly longer to develop C components because the barrier to writing bug-free C is much higher..."

https://blog.rust-lang.org/2017/11/22/Rust-1.22.html "What’s in 1.22.0 and 1.22.1 stable The headline feature for this release is one many have been anticipating for a long time: you can now use ? with Option<T>! About a year ago, in Rust 1.13, we introduced the ? operator for working with Result<T, E>. Ever since then, there’s been discussion about how far ? should go: should it stay only for results? Should it be user-extensible? Should it be usable with Option<T>? In Rust 1.22, basic usage of ? with Option<T> is now stable. This code will now compile: fn try_option_some() -> Option<u8> { let val = Some(1)?; Some(val) } assert_eq!(try_option_some(), Some(1)); fn try_option_none() -> Option<u8> { let val = None?; Some(val) } assert_eq!(try_option_none(), None); However, this functionality is still a bit limited; you cannot yet write code that mixes results and options with ? in the same function, for example. This will be possible in the future, and already is in nightly Rust; expect to hear more about this in a future release. Types that implement Drop are now allowed in const and static items. Like this: struct Foo { a: u32 } impl Drop for Foo { fn drop(&mut self) {} } const F : Foo = Foo { a : 0 }; static S : Foo = Foo { a : 0 }; This change doesn’t bring much on its own, but as we improve our ability to compute things at compile-time, more and more will be possible in const and static. Additionally, some small quality-of-life improvements: Two recent compiler changes should speed up compiles in debug mode. We don’t have any specific numbers to commit to with these changes, but as always, compile times are very important to us, and we’re continuing to work on improving them. T op= &T now works for primitive types, which is a fancy way of saying: let mut x = 2; let y = &8; // this didn&#39;t work, but now does x += y; Previously, you’d have needed to write x += *y in order to de-reference, so this solves a small papercut."

Не прошло и ста лет https://github.com/nc4rrillo/indigo

https://twitter.com/sdroege_/status/916357166088511488 "Naively re-implemented some @gstreamer C code in @rustlang for fun & result was ~1.7x faster. Zero-cost abstractions? I&#39;d say negative-cost Now optimizing the C code. There&#39;s no reason why it should be slower. But Rust apparently made it easier in this case to write fast code"

https://www.factorio.com/blog/post/fff-206 "Step 3 - Getting rid of boost Boost is a special kind of demon. It lures you in by giving you all these cool and simple to use features, and then it beats your soul from you by increasing compilation times absurdly. There are two main problems. Problem one is that they don&#39;t care much about compile times and two, they want to have everything nice and generic ad absurdum, and they even defend it as the correct style. The result is, that changing boost::mpl::vector66 to std::variant can improve the compile time from 1:44 to 1:20 and getting rid of templates completely by using unions can decrease the compile time to 0:53. I&#39;m talking about changing 2 headers of 2 classes in a project with 3390 files, 410k lines of code and 15Mb of source code. Everything that was compiled to Factorio, GUI, graphics library, networking, entity logic, scripting, modding, logistic system... all these things together took the same time to compile as two instances of boost::mpl::vector. Our current goal is to get rid of the boost library completely."

https://blog.rust-lang.org/2017/08/31/Rust-1.20.html "Rust 1.20 adds the ability to define “associated constants” as well: struct Struct; impl Struct { const ID: u32 = 0; } fn main() { println!("the ID of Struct is: {}", Struct::ID); } That is, the constant ID is associated with Struct. Like functions, associated constants work with traits and enums as well. Traits have an extra ability with associated constants that gives them some extra power. With a trait, you can use an associated constant in the same way you’d use an associated type: by declaring it, but not giving it a value. The implementor of the trait then declares its value upon implementation"

Красота, через три месяца в релизе: https://play.rust-lang.org/?gist=80cf2488c9daaedf43c73181a9bf2edb&version=nightly

https://twitter.com/navalny/status/326243610418884610 "Хочу, чтоб все создатели Java, требующей постоянных обновлений, и те, кто использует ее в приложениях, горели в аду на сковородках"

https://twitter.com/l0ldbl00d/status/895396894192668673 "Тридцать три коммита (x2) В каждом изменялась Лишь одна строка Тридцать три коммита С мастер-веткой слиты Говнокод тупого мудака"

НИ ЕДИНОГО СЕГФОЛТА!!!! https://habrahabr.ru/company/erlyvideo/blog/334912/ "А чего там про Rust Вот как раз стример у нас ржавый. Целая пачка unsafe кода, автогенеренного из сишного кода SDK с помощью bindgen, подпатченый биндинг к libc (постараемся залить патч в апстрим) и дальше реализация RTSP на tokio. Даже уже есть возможность посмотреть видео с камеры в обычном браузере — это недостижимая роскошь для китайских камер, которые поголовно требуют установку ActiveX. Структура очень непривычна после эрланга: ведь тут нет процессов и сообщений, есть каналы, а с ними всё становится немножко по-другому. Как я уже выше писал, современно написанный код с правильной организацией дает возможность раздавать видео не 2-3 клиентам, а более 50 без какой-либо просадки производительности. Важный момент: за время разработки пока не случилось ни единого сегфолта. Пока есть стойкое ощущение, что Rust заставляет писать так, как в принципе пишут хорошие поседевшие сишники, повидавшие всякого нехорошего. Так что пока всё нравится. В течение августа есть планы закончить работу по базовому сценарию, так что есть вопрос к аудитории, который идет в опросе. Ну и задавайте вопросы, которые возникли."

https://habrahabr.ru/post/333346/ "К примеру, недавно я изучал проблему дженериков (generics), и пока что я не вижу в голове чёткой картины подробного и детального примера проблемы, для решения которой пользователям Go нужны дженерики."

https://spb.hh.ru/vacancy/21894554 "Требования Опыт backend-разработки на Rust не менее 2 лет."

Коротко о том, почему Rust лучше: https://play.golang.org/p/JKWn84wsXL package main import "fmt" func main() { Printer(nil) var x *int = nil Printer(x) } func Printer(it interface{}) { if it == nil { fmt.Println("got a nil!") return } fmt.Println("got a non-nil:", it) }