У - удобно: `cargo install cargo-tree`

Rust обгоняет Go: https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.ofup3wz68 Hashtests time: Rust 135 seconds, Go 290 seconds Rust: 82.5 seconds, Go 165 seconds, Pypy 310 seconds

Новый вид гриппа, заразившийся им переписывает ПО на Rust: http://www.wilfred.me.uk/blog/2017/01/11/announcing-remacs-porting-emacs-to-rust/

Сижу, ем кактус. Что за ошибка такая failed to write output file 'bin.v2\libs\metaparse\example\calculator_with_parens_and_unary_ops\msvc-15.0\release\address-model-64\debug-store-database\debug-symbols-on\pch-off\threading-multi\calculator_with_parens_and_unary_ops.exe.rsp'! ? Место на диске есть.

мій страх: випадково закоммітити та запушити лінку на порнуху

http://forum.simutrans.com/index.php?topic=15843.msg155972#msg155972 Эпичная история про гонки: "I have been working of late on the multi-threading of the passenger and mail generation in an attempt to make it network safe, and have encountered some complexities on which I should appreciate others' views as to possible solutions, and on the solutions that I propose below. Firstly, I have dealt with the RNG problem by making the random seed and associated variables thread local, and re-initialising them on each thread when the threads are initialised. This will, however, have the effect that a single-threaded build will not stay in sync with a multi-threaded build. I will therefore need to have the option of keeping the multi-threading of passenger generation single threaded in network mode in case anyone wants to connect a single threaded client to a multi-threaded server or vice versa. There will need to be an explanation in the comments to simuconf.tab that disabling multi-threading of the passenger and mail generation will be necessary if single and multi-threaded clients/servers are to be connected together. I have already changed config.template to make enabling multi-threading the default. Secondly, I have also changed the way in which the amount of mail and passengers to generate each step is calculated again to make it network safe. It is somewhat difficult to make this as accurate when done in parallel than when it was single-threaded, but the overall results should be deterministic and scale properly. Again, however, this will make single threaded clients incompatible with multi-threaded servers and vice versa. I do wonder whether it might be worthwhile indicating in the splash screen whether a given build is single-threaded. The further issues are more complex. The next issue relates to the generation of pedestrians and private cars. Both of these are generated during the stepping of mail and passengers when passengers take a private car to their destination (in which case, a city car graphic is created) or when passengers walk either to their destination or to a stop, in which case pedestrian graphics are created. Pedestrians are more straightforward, as, once created, they do not interact with any other objects. They do, however, call simrand() in various places when they are sync-stepped; but am I correct in deducing that, because they will always be sync-stepped from the main thread, simrand() will always be called in the same order even if each individual pedestrian object may be created in a different order (and therefore in the sync list in a different order) on each client? Private cars are more tricky. They have the same issues as pedestrians, but also another issue: they interact with each other and with player vehicles on the roads. A particular problem might occur if one particular building during any one step creates multiple city cars. These would potentially be created in a different order on different clients. When multiple city cars are generated on a single tile in a single step, they form a stack, and the cars drive off the stack one by one, each waiting for the last to leave the next tile before moving, until none remains. I infer that the order in which they leave the stack will depend on the order in which they are inserted into this stack. This will lead to desynchronisations if different cars have different destinations (which will affect the probability with which they turn in any given way at junctions), different maximum speeds and different "time_to_life" durations (which, in experimental, are all based on the actual expected journey time of the particular packet of passengers taking the car rather than being a fixed number)..."

В GTK системный трэй считают устарешим, а в QML (сама Qt в rust не поддерживается) трэй просто не поддерживается.

Rustonomicon http://killercup.github.io/trpl-ebook/

Странно, в комментариях к статье нет секты свидетелей Оберона: http://habrahabr.ru/post/262295/ "Как можно заметить, несмотря на различный синтаксис, структура остается той же. Код на Go состоит из операторов на С, однако структура выглядит как Oberon. Это неудивительно: Go использует квинтэссенцию удачных концепций языка, при этом развивая ее. Наследие Oberon проглядывает в Go в той же степени, что и наследие С за счет таких концепций, как пакеты, импорты, строгая безопасность памяти, GC и динамическая проверка типов."

http://publications.lib.chalmers.se/records/fulltext/219016/219016.pdf "Parallelization in Rust with fork-join and friends Creating the ForkJoin framework Master’s thesis in Computer Science and Engineering"

TIL https://en.wikipedia.org/wiki/Planning_poker