От C++ Junior-а обычно ожидают то, что когда он вредит (а вредит он постоянно), он с первого раза хотя бы пытается запомнить что ему сказали про то, как делать правильно. Ну и как-то более-менее знает язык «по книжке». На Qt скорее вредно, чем полезно ориентироваться, там довольно архаичное использование C++, так как библиотека очень древняя и имеет долгую и тяжелую наследственность.
В Autodesk (Maya, Autocad и т.д.) система лицензирования написана на комбинации из Go (сервис/демон с логикой), C++ (то что по тем или иным причинам было нельзя сделать на Go) и JavaScript (собственно сам UI). Довольно удобно в разработке, если делать на Go исключительно то, для чего язык предназначен – сервис, а UI писать на JavaScript.
А еще стоит участвовать в митапах на всех этапах карьеры. Пусть и в отличие от конференций там, обычно, уровень докладов ниже, но это компенсируется более живой атмосферой.
Самый доступный способ сделать так, что бы просто и без вопросов можно быть набирать код и отлаживаться на всех платформах (ну, в разумных пределах, но как минимум Linux+macOS+Windows) – это взять CLion. Он даст и интеграцию с CMake и очень хорошую поддержку C++. Не бесплатно, но мы вроде тоже не за интерес работаем.
Отказываться от CMake очень неосмотрительно, так как он де-факто стандарт современной C++ разработки. В купе с тем же VCPKG можно очень быстро и просто подключить нужную библиотеку, обкатать идею, быстро и просто запустить юнит-тесты, подготовить бинарники к дальнейшей запаковки инсталлятором. Так же CMake позволит не думать об IDE в принципе, все возьмут то, к чему привыкли и будут работать. На всех платформах.
Основная ценность митапов не в полезных докладах, а в возможности поговорить с людьми, которым интересно то же самое что и тебе с одной стороны и выступить с чем-то не шибко длинным, т.е. не требующим долгой подготовки как в случае с конференцией, с другой стороны. Доклад на митапе часто вторичен.
На данный момент, часть тестов реализована и лежит в папочке с исходниками. Добавлять же на benchmarksgame, до выхода Rust 1.0 и стабилизации API никто не будет, т.к. на данный момент ломающие изменеиня возникат по нескольку раз в неделю.
Моделью памяти, в первую очередь. Так же отсутствием необходимости в GC. Библиотеки с нуля писать не нужно, т.к. Rust имеет отличную практически бесшовную интеграцию с Си библиотеками.
Еще Rust лучше тем, что он пишется не как хобби пары чуваков, а как язык для решения конкретных задач парой корпораций (Мозилла и Самсунг) и как следствие, есть надежда что язык в скорости обретет стабильность. В отличие от уже лет 10 как «почти стабильного» D, который, тем не менее, большинство PM-ов не допускает в продашн как раз из за опасений связанных с развитием языка.
Данный релиз вообще крайне интересный в первую очередь рефакторингом библиотек. Если раньше в драйверах была возможность использовать только сам компилятор без libstd и libextra, то теперь, теоретически, появляется возможность использовать libstd и для драйверов, правда шлифовка напильником все равно требуется.
Обо всем остальном можно будет говорить тогда, когда поддержку «всего остального» реализуют. На данный же момент не возможно или не возможно без приседаний синхронизировать: Calendar, Notes, Contacts, Reminders, Messages. Все это активно работает в рамках экосистемы от Apple и без нормальной поддержки как минимум Calendar, Notes, Contacts изначальное утверждение «Nokia Lumia + MacOS X = Дружба и взаимопонимание» не более чем сотрясание воздуха.
А что делать с Notes, Calendar, Contacts из iCloud? Без них ценность телефона при условии что основной рабочей ОС является OSX оказывается, к сожалению, не велика :(
Планировщик Rust «выполняет» обычный машинный код. По умолчанию Rust поддерживает вызовы Си кода. Ну а через Си ты уже можешь вызвать что угодно.
Хотя возникает вопрос — зачем? Ты же понимаешь, что такой код должен быть помечен как unsafe и проверка работы с памятью времени компиляции к нему применяться не будет.
Да, такая фича там была с самого начала. Есть возможность использовать разные планировщики с разными принципами раздачи задач по ядрам (на данный момент, версия 0.8-pre, вроде как остался только один, т.к. заменили ядро планировщика).
Да, в рускоязычной литературе managed обычно переводится как «Управляемый». В то же время, в Rust есть несколько типов управляемых указателей, поэтому переводить какой-то один из них как «управляемы» было бы не совсем корректно. К тому же, при подборе русского названия я еще исходил из поведения указателя.
Да они и так конкурируют. КМК, Мозилла решила, что имея в своем распоряжении движок написанный на языке типа Rust, у них будет конкурентное преимущество над разработчиками с C++ движками. Подобное ожидание выглядит довольно разумно, т.к. многопоточный код на Rust писать быстрее и проще чем на C++. А если еще и производительность будет не больше чем 1,5-2 раза ниже чем у плюсового кода, то это вообще победа :)
Отказываться от CMake очень неосмотрительно, так как он де-факто стандарт современной C++ разработки. В купе с тем же VCPKG можно очень быстро и просто подключить нужную библиотеку, обкатать идею, быстро и просто запустить юнит-тесты, подготовить бинарники к дальнейшей запаковки инсталлятором. Так же CMake позволит не думать об IDE в принципе, все возьмут то, к чему привыкли и будут работать. На всех платформах.
Еще Rust лучше тем, что он пишется не как хобби пары чуваков, а как язык для решения конкретных задач парой корпораций (Мозилла и Самсунг) и как следствие, есть надежда что язык в скорости обретет стабильность. В отличие от уже лет 10 как «почти стабильного» D, который, тем не менее, большинство PM-ов не допускает в продашн как раз из за опасений связанных с развитием языка.
Хотя возникает вопрос — зачем? Ты же понимаешь, что такой код должен быть помечен как unsafe и проверка работы с памятью времени компиляции к нему применяться не будет.