Предположение о том, как работает EmDrive — двигатель на магнитной тяге

Вы привели ссылку на вики, и там же приведена критика этой теории. Позволю себе процитировать:

Критики теории Лесажа отмечали множество её слабых мест, особенно с точки зрения термодинамики. Джеймс Максвелл показал, что в модели Лесажа энергия непременно перейдёт в теплоту и быстро расплавит любое тело. Анри Пуанкаре подсчитал (1908), что скорость корпускул должна быть на много порядков выше скорости света, и их энергия испепелила бы все планеты[31]. Были отмечены и непреодолимые логические трудности[32]:

Если тяготение вызвано экранированием, то Луна в те моменты, когда она находится между Землёй и Солнцем, должна существенно влиять на силу притяжения этих тел и, соответственно, на траекторию Земли, однако ничего подобного в реальности не наблюдается.
Быстро движущееся тело должно испытывать спереди избыточное давление со стороны корпускул.

Попытка Джорджа Дарвина заменить корпускулы на волны в эфире оказалась также неудачной. В обзоре 1910 года модель Лесажа уверенно характеризуется как несостоятельная[31].

Ещё больше аргументированной критики приведено на английской википедии. На мой взгляд, проблем у этой теории гораздо больше, чем у ТО.

Пример решения типичной ООП задачи на языке Haskell

data Figure a = forall a. Paint a =>  Figure a

Мне кажется, или это должно быть

data Figure = forall a. Paint a => Figure a

т.е. у тайпконструктора Figure не должно быть параметра? Ведь он квантифицируется forall'ом, следовательно, это связанная типовая переменная внутри самого определения типа.

Почему Go и Rust не враги, а друзья

Спасибо за статью!

На самом деле, в коммьюнити Rust и Go очень доброжелательные отношения как внутри, так и друг с другом. Фриков, которые обсирают «противоположный» язык, не любят ни там, ни там. Такие статьи, как эта — это очень здорово.

По коду.

#[no_mangle]
pub extern "C" fn hello_from_rust(name: *const libc::c_char) {
    let buf_name = unsafe { CStr::from_ptr(name).to_bytes() };
    let str_name = String::from_utf8(buf_name.to_vec()).unwrap();
    println!("go\t: {}", str_name);
}

Здесь много лишних действий. Вот так (для данного конкретного случая) будет проще:

use std::str;

pub extern "C" fn hello_from_rust(name: *const libc::c_char) {
    let c_name = unsafe { CStr::from_ptr(name) };
    let str_name = str::from_utf8(c_name.to_bytes()).unwrap();
    println!("go\t: {}", str_name);
}

В данном случае лишних аллокаций делать совершенно не нужно, и код получается чуть проще.

Почему Go и Rust не соперники

На Rust писать без рантайма проще, чем на Go. Для поддержки всех фич Go нужен рантайм. Каналы, встроенные типы данных, горутины — всё это без рантайма работать не будет, а без этих фич Go — это крайне неудобный C. В Rust практически весь язык доступен вообще без какого-либо внешнего кода, и, кроме того, он «модульный», если это так можно сформулировать. Например, вы хотите написать программу для Pebble. Там свои скрипты сборки, своя архитектура и своя сишная библиотека, сильно урезанная по сравнению, например, с glibc. Не проблема — отключаете std, подключаете то, что можно, например, liballoc (и, как следствие, станет возможно взять libcollections и ещё кучу всего), который можно подключить, обернув сишный malloc/free, компилируете свою программу как статическую библиотеку и скармливаете её нативным для Pebble скриптам сборки — и всё будет работать.

В Rust писать низкоуровневый код, например, работу с сырыми указателями, гораздо проще. Goшный unsafe.Pointer очень неудобен по сравнению с его обычными указателями. В Go нет inline assembly, в Rust есть, и есть планы по его улучшению.

Почему Go и Rust не соперники

Да, всё так.

На Rust удобно написать программу для микроконтроллера гораздо проще, чем на Go.

Как красиво оформить публикацию на Хабре

В смысле — ещё парсер кастомных тегов? Он уже есть сейчас у хабра. Markdown сам по себе предназначен для работы в виде преобразователя в HTML. Поэтому сделать Markdown-based редактор для хабраразметки, которая есть надмножество HTML, очень просто — надо всего лишь прогнать входной Markdown через преобразователь, и полученный HTML будет полностью совпадать с тем, что сейчас можно написать вручную при создании поста.

Как красиво оформить публикацию на Хабре

Если вдруг его захотите интегрировать, было бы неплохо это сделать удобно — например, не забыть сделать поддержку code fences:

```some-language
code in some language
```

преобразуется в

<source lang="some-language">
code in some language
</source>

Как красиво оформить публикацию на Хабре

Markdown изначально разработан так, чтобы позволять вставлять произвольный HTML-код. Если вам нужен <spoiler>, то и пишите его непосредственно:

Абзац *c разными* [фичами][1] Markdown'а

<spoiler>скрытый абзац, тоже с *фичами* **Markdown'а**</spoiler>

Следующий абзац.

Как красиво оформить публикацию на Хабре

+1, очень не хватает маркдауна.

Сборщик мусора в Go: решение проблемы отзывчивости в Go 1.5

Ну на самом деле ниши у Go и Rust, хоть и пересекаются, всё же различные. У всего есть своё применение, и во многих случаях сборщик мусора очень удобен, гораздо удобнее чего бы то ни было ещё.

Вице-президент Lenovo приглашает помочь с ретро-ThinkPad

Кажется, вот такая ссылка правильнее: youropinioncounts.lenovo.com/s/RetroThinkPad/survey1

Пишем свой упрощенный OpenGL на Rust — часть 2 (проволочный рендер)

Ну на счёт «приучаться правильно» я с вами, в принципе, согласен, но не согласен с тем, что это «обход» модели ошибок. Паники — такая же часть модели ошибок, как и Result.

Пишем свой упрощенный OpenGL на Rust — часть 2 (проволочный рендер)

from_str() удалили не из Rust 1.1, его нет уже давным-давно. Стандартным способом сконвертировать строку во что-то как минимум полгода является метод parse().

Пишем свой упрощенный OpenGL на Rust — часть 2 (проволочный рендер)

Я думаю, что для кода приложения, а не библиотеки, использовать &str для имени файла — вполне нормально. Если понадобится что-то другое, всегда можно будет исправить; а использование AsRef никак не поможет, если опять же в самом начале передавать строку.

То же самое, в общем-то, справедливо и для обработки ошибок, с учётом «игрушечности» рендерера и целей, с которыми он делается.

Рейтинг ВУЗов стран БРИКС. Россия на втором почётном месте. Ликвидации фонда «Династия» посвящается

В нескольких местах видел информацию, что негласно в муниципальные и государственные учреждения вроде библиотек и прочего спустился мораторий на работу с иностранными агентами. С учётом области деятельности Династии (госвузы, библиотеки и т.д.) можно представить, насколько это большие палки в колёса.

Пишем свой упрощенный OpenGL на Rust — часть 1 (рисуем линию)

Нет, просто удалить extern crate недостаточно.

extern crate «погружает» указанный crate в глобальное пространство имён как модуль. Чтобы обращаться к нему, вам по-прежнему нужно его импортировать с помощью use:

use sdl2;
use sdl2::Sdl;

Пишем свой упрощенный OpenGL на Rust — часть 1 (рисуем линию)

Да, кстати.

В книге раста не было статей с названием Classes/Objects/Constructors и т. п.

Ну так это и неудивительно, Rust не является объектно-ориентированным, поэтому ни классов, ни объектов в смысле ООП здесь нет :) есть trait objects, но это про другое.

Пишем свой упрощенный OpenGL на Rust — часть 1 (рисуем линию)

Хорошая статья, вы молодцы. «Огреть тяжёлым» не хочется :)

любое объявление extern crate package_name в библиотеке должно быть также продублировано в main.rs приложения

Не совсем так. Для подключения внешней библиотеки достаточно написать extern crate whatver; только в корне crate'а, т.е. в вашем случае в main.rs. В остальных модулях внешнюю библиотеку можно просто use'ать, как любой другой модуль.

Особого упоминания заслуживает такая штука, как время жизни (lifetime) в Rust. С ней я долго боролся. Вообще говоря в Rust у каждой переменной и ссылки есть свой lifetime. Просто он выводится компилятором автоматически на основе определенных правил. Однако иногда его требуется указывать явно. Чтение статьи про время жизни из книги раста ничего для меня не прояснило. (хотя я ее 3 раза перечитал) Я так и не понял, почему же в моем случае Rust попросил указать lifetime. По сути я просто добавил эти странные <'_> везде, где компилятор указывал на ошибку с неуказанным lifetime, так и не разобравшись, зачем же ему это от меня было надо. Если есть знающие люди, буду рад, если просветите в комментариях. Почему именно подчерк, а не какой-то другой знак после апострофа? Просто в сообщении об ошибке про несоответствие типов было sdl2::render::Renderer<'_>. Поначалу я пытался обозначать поле как просто renderer: Renderer, но компилятор меня ругал: error: wrong number of lifetime parameters: expected 1, found 0

'_ — это обозначение анонимного lifetime-параметра, используемое внутри компилятора. На самом деле то, что сейчас можно писать '_ и всё будет работать — это в некотором роде недосмотр, и есть RFC на эту тему, которое, если будет принято, изменит семантику '_. Именно подчерк просто потому, что так компилятор обозначает анонимные lifetime'ы.

Конкретно в данном случае вам вообще не нужны lifetime-параметры — см. ниже.

У rust-sdl2 действительно проблема с документацией. Та, что доступна по ссылке на rust-ci, очень устаревшая. В этом случае самый правильный способ получить актуальную документацию — склонировать репозиторий и запустить там cargo doc:

% git clone https://github.com/AngryLawyer/rust-sdl2
% cd rust-sdl2
% cargo doc
% open target/doc/sdl2/index.html

И уже из документации будет понятно, зачем вообще нужны все эти лайфтайм-параметры.

sdl2::init().video().unwrap() возвращает значение типа sdl2::Sdl, которое позволяет, в частности, создавать новые окна. sdl_context.window(...).....unwrap() возвращает значение типа sdl2::video::Window. Из окна можно создать renderer для этого окна, и это делает window.renderer().build().unwrap() — этот код возвращает значение типа sdl2::video::Renderer<'static>. Внимание на lifetime-параметр — он равен 'static. Это специальный lifetime, обозначающий нечто, что может жить до конца всей программы. В данном случае 'static используется из-за того, что полученный renderer самодостаточен — он получен из поглощённого значения Window (есть другой случай, когда renderer создаётся из поверхности (surface), и тогда он связан с этой поверхностью с помощью этого lifetime-параметра) и не зависит от жизни никакого другого значения.

Таким образом, вы можете описать вашу структуру как

pub struct Canvas {
    renderer: Renderer<'static>,
    sdl_context: Sdl,
    xsize: u32,
    ysize: u32,
}

и убрать все параметры из ваших функций.

Почему Go превосходит посредственность

Вау, не знал о такой штуке. Это реально круто, но было бы гораздо круче, если бы эти ссылки вели не на исходники, а на документацию. Понятно, что можно прочитать в комментариях в сорцах, но это тупо неудобно, и возможность дальнейшего перехода по таким ссылкам теряется.

Почему Go превосходит посредственность

Да, я понимаю, как формируется кривая спроса.

И мне кажется, что я даже представляю себе в целом ваш аргумент в пользу вашего утверждения. Я не согласен с ним (с утверждением), но, прошу вас, продолжайте :)