Очень кратко так: Go — это замена Java, а не замена C++. По моему мнению, вопреки мнению людей в интернетах, Go не является аналогом Rust.
В Go есть глобальный соборщик мусора, что делает Go неприменимым для большого числа задач.
Там, где надо в процессе выделять 50 Гб памяти, где важна реалтаймовость, и где нельзя потерять 20% памяти на служебные нужды, Go работать не будет. А Rust — будет.
Если программа на C++ падает, начните тестировать свой код, хотя бы TDD.
Вы используете примерно такие же аргументы, какие используются в спорах «статически-типизированные против динамически-типизированных языков программирования»: статическая типизация не нужна, хороший программист пишет и без типов и покрывает всё тестами.
Мне кажется, статическая типизация нужна: она делает код более понятным, читаемым, поддерживаемым и т. п. А Rust ещё более типизированный язык программирования, чем C++.
Ничего не даётся даром, С++ даёт полный контроль над памятью, взамен требует квалифицированного обращения
Мой поинт в том, что Rust позволяет писать программы такие же быстрые, как и C++, но при этом освобождает голову программиста от ненужных знаний о том, кто владеет памятью.
Mutex внутри Rust точно такой же, как и в любой другой современной среде программирования. Точно так же там захват без contention делается через атомики.
Mutex обычно используется там, где его нельзя не использовать. Если несколько потоков должны обращаться к общему ресурсу, или если потокам надо спать ожидая какие-то условия, то без мьютексов (или каких-то подобных механизмов) обычно никуда не деться. На каждую переменную Mutex не вешаетcя. Mutex может закрывать сложную структуру, например, хеш-таблицу.
компилятор банально глупости делает, например, берёт и выкидывает ненужные, с его точки зрения блоки, которые на деле использовались для получения хорошей энтропии
20 минут потерянного времени программиста только на сборку
Надо увольнять таких программистов, которые не способны настроить себе
— компиляцию только того, что реально изменилось
— компиляцию на сервере
— распределённую компиляцию
— компиляцию с кешированием результатов
Зато не приходится заполнять никакие текстовые поля (как-минимум login, e-mail, password; в худшем случае — подтверждение по e-mail). Это напрягает гораздо больше, чем пара лишних кликов мышкой.
В Go есть глобальный соборщик мусора, что делает Go неприменимым для большого числа задач.
Там, где надо в процессе выделять 50 Гб памяти, где важна реалтаймовость, и где нельзя потерять 20% памяти на служебные нужды, Go работать не будет. А Rust — будет.
В Rust очень не хватает IDE, и авторы Rust разработкой IDE, насколько мне известно, не занимаются.
Однако, я сомневаюсь, что разработчики языка C++ это сделают. До сих пор они добавляли в язык и стандарт не самые нужные фичи.
Вы используете примерно такие же аргументы, какие используются в спорах «статически-типизированные против динамически-типизированных языков программирования»: статическая типизация не нужна, хороший программист пишет и без типов и покрывает всё тестами.
Мне кажется, статическая типизация нужна: она делает код более понятным, читаемым, поддерживаемым и т. п. А Rust ещё более типизированный язык программирования, чем C++.
Ничего не даётся даром, С++ даёт полный контроль над памятью, взамен требует квалифицированного обращения
Мой поинт в том, что Rust позволяет писать программы такие же быстрые, как и C++, но при этом освобождает голову программиста от ненужных знаний о том, кто владеет памятью.
Mutex обычно используется там, где его нельзя не использовать. Если несколько потоков должны обращаться к общему ресурсу, или если потокам надо спать ожидая какие-то условия, то без мьютексов (или каких-то подобных механизмов) обычно никуда не деться. На каждую переменную Mutex не вешаетcя. Mutex может закрывать сложную структуру, например, хеш-таблицу.
prooflink е?
Так гораздо проще в стандартных клиентах SSH, плюс спасает от кучи проблем.
Надо увольнять таких программистов, которые не способны настроить себе
— компиляцию только того, что реально изменилось
— компиляцию на сервере
— распределённую компиляцию
— компиляцию с кешированием результатов
Так думают оптимисты.
Т. е. для каждого человека вводится параметр — R. Этот R изначально равен нулю.
Дальше при «плюсе» R изменяется по формуле
R := R + 1 — 1 / (1000 — R + 1)
А при «минусе» R изменяется по формуле
R := R — 1 + 1 / (1000 + R — 1)
Т. е. при R ~= 0 вес плюса и минуса примерно равен единице (надо чуть-чуть нормализовать формулу, но тут это непринципиально).
При R -> 1000 (при R стремящемся к 1000) вес плюса -> 0, а вес минуса -> 1.
При R -> -1000 вес плюса -> 1, а вес минуса -> 0.
Вот картинка для наглядности: screencast.com/t/IqUk7yUg
Похоже, что вы не разделяете идеи OpenID.