Ну тогда проблема возникает со стороны продавца: как получить деньги, если товар уже дошел, но покупатель отказывается перечислять деньги (подтверждать отсутствие претензий)?
в современных условиях продуктивность работы зависит главным образом от имеющихся библиотек/фреймворков
Я правильно понимаю, что мы до скончания веков теперь прокляты писать на C++ и Java, раз они популярны? (кстати, почему не кобол тогда, он ведь тоже был популярен?)
необходимость изобретать Kotlin, когда уже есть Java… сомнительно
А я вот не соглашусь. Не пишу ни на том, ни на другом, но как минимум котлин стоило "изобретать" только ради Null safety. Да и синтаксический сахар сильно повышает читаемость кода. И вообще странно предъявлять за котлин, ведь как раз тут совершенно великолепная совместимость с джавой, при том что язык, как по мне, лучше.
Те же усилия, потраченные на улучшение библиотек/фреймворков или инструментария дали бы куда больший прирост производительности
Ага, есть у нас такой "инструментарий", уже черт знает сколько лет дорабатывается, а в итоге получается такое, что борешься уже не с задачами, а с инструментом.
Это такое себе кодерское SJW
Ну уж нет, сравнивать "давайте заменим слова потому что обидно" и "давайте делать новые инструменты, исследовать новые подходы/концепции" не стоит. Даже если новый язык не взлетит, вполне возможно, что хорошие концепции из него потом будут позаимствованы более популярными языками. И их стоит создавать только ради этого.
А что плохого? Если я буду не в настроении общаться с кем-то, или тема будет явно не интересна, то я просто скажу "отстань". Но в целом я не против посраться подискутировать на техническую тему, будь то Rust/Go/очередной web фреймворк для питона или хз еще что. Нельзя же только обсуждать, у кого как тугосеря покак сделал. Ну и не понимаю, почему нельзя одновременно быть маркетологом и инженером?
Да какой пример то? Отключить borrow checker нельзя. Вам уже сказали — borrow checker продолжает работать в unsafe секциях, но он не предназначен для указателей by design. Но при этом продолжает проверять ссылки. Хотите пример — держите https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=29e9aef02a12d840b81919c83166a31f. А ваша аргументация — это что-то в стиле "я отключил ПДД, так как лечу на самолете".
А вас я во лжи и не обвинял нигде. Давайте восстановим, как было дело:
Но когда люди стоят перед выбором "а не начать ли нам новый проект на Rust?", а им попадается доклад Антона, тогда получается уже не очень хорошо.
Переформулирую: плохо, когда люди будут делать выбор, основываясь на неточной информации (и здесь я сделал вывод, что неточность в докладе была намеренная, так что — ложь).
Далее вы пишите:
Получается хорошо. Чтобы люди брали проверенные временем и поддерживаемые десятилетиями технологии. Всё так.
То есть поддерживаете позицию, что можно говорить что угодно, главное — чтобы выбрали вашу любимую ("проверенную временем") технологию. И вот эту позицию я не разделяю.
Rust-community насаждает Rust
Вы преувеличиваете. Люди просто рассказывают про хороший инструмент. Но вы воспринимаете это как-то в штыки, будто вас насильно заставляют на нем писать. Просто многим зашел этот инструмент, поэтому складывается ощущение, что "он везде". Возможно, это как раз свидетельство того, что он "взлетел" и действительно не так плох. А может и нет, не знаю.
Прочитал. Все еще придерживаюсь позиции, что по большей части, все перечисленное в статье — так.
А про дезинформацию: возьмем конкретный пункт "Плюсы Rust только в анализе времени жизни объектов." Это откровенная, явная неправда в такой формулировке, потому что как минимум раст похволяет не только контролировать лайфтаймы, но и отсутствие 2-х мутабельных ссылок на данные (ownership), в отличии от C++. Более того, ниже автор доклада явно повторил эту формулировку "Поэтому да — только lifetime", так что вопросы некорректной интепретации видео снимаются.
Так что да, я все еще считаю, что здесь есть "ложь во благо". И я считаю ее неприемлемой для технической дискуссии, даже если это всего лишь один раз за все выступление.
Можно даже сделать более интересный вывод: эта функция всегда возвращает b просто потому что
сама функция возращает значение типа T (не ссылку);
ничего не известно про тип T (в том числе и о том, что его можно копировать/клонировать) + как указано в статье, сконструировать его нельзя по той же прчине;
только аргумент b передается по значению.
То есть функция не сможет вернуть что-либо, содержащееся в a (так как передан по немутабельной ссылке), и не сможет сконструировать сама значение типа T. Остается b.
А с компьютерами что не так? Сами будете собирать системник, и там ничего, кроме железа, и не будет. Да и у ноутбуков почти всегда есть вариант модели с DOS.
Эх, а что ж вы самое интересное то не приложили, то есть скриншоты (которые у вас видимо приложение 1 и приложение 2).
P.S.
Отдельно спасибо за формулировку, использованную в описании приложений: скриншоты рассылаемых администраторам доменных имен, находящихся на обслуживании ....
Скриншоты чего? Наверно, конечно, писем. Видимо так торопились написать хоть что-то, что даже не перечитали потом.
8 гигов памяти, все нормально, FF набрал на 6.6 гигов в весе, потом постепенно освободил память, музыка на соседней вкладке даже не прекратилось, только интерфейс тормозил немного
Да ладно, стандарты выходят раз в три (?) года, да и чем-то прям глобальным был только 11й, осилить несколько фич раз в три года не настолько невозможно же, да?
FreeOTP+. По сути форк с доп. фичами. Больше всего нравится возможность входа в приложение по отпечатку/PIN.
Опять малопродуктивные и не вовлеченные ¯\_(ツ)_/¯.
А интернет все помнит: http://web.archive.org/web/20201224152054/https://habr.com/ru/company/ruvds/news/t/534644/. Что ж вы так решили переписать то новость, хммм, непонятно, неясно ...
Ну тогда проблема возникает со стороны продавца: как получить деньги, если товар уже дошел, но покупатель отказывается перечислять деньги (подтверждать отсутствие претензий)?
Я правильно понимаю, что мы до скончания веков теперь прокляты писать на C++ и Java, раз они популярны? (кстати, почему не кобол тогда, он ведь тоже был популярен?)
А я вот не соглашусь. Не пишу ни на том, ни на другом, но как минимум котлин стоило "изобретать" только ради Null safety. Да и синтаксический сахар сильно повышает читаемость кода. И вообще странно предъявлять за котлин, ведь как раз тут совершенно великолепная совместимость с джавой, при том что язык, как по мне, лучше.
Ага, есть у нас такой "инструментарий", уже черт знает сколько лет дорабатывается, а в итоге получается такое, что борешься уже не с задачами, а с инструментом.
Ну уж нет, сравнивать "давайте заменим слова потому что обидно" и "давайте делать новые инструменты, исследовать новые подходы/концепции" не стоит. Даже если новый язык не взлетит, вполне возможно, что хорошие концепции из него потом будут позаимствованы более популярными языками. И их стоит создавать только ради этого.
Действительно, почему всем так не нравится писать на ассемблере?
А что в этом смешного?
P.S. Кому интересно, запуск в ~11:30 мск
А что плохого? Если я буду не в настроении общаться с кем-то, или тема будет явно не интересна, то я просто скажу "отстань". Но в целом я не против
посратьсяподискутировать на техническую тему, будь то Rust/Go/очередной web фреймворк для питона или хз еще что. Нельзя же только обсуждать, у кого как тугосеря покак сделал. Ну и не понимаю, почему нельзя одновременно быть маркетологом и инженером?Комитет, принимающий простые изменения по несколько лет ¯_(ツ)_/¯
Да какой пример то? Отключить borrow checker нельзя. Вам уже сказали — borrow checker продолжает работать в unsafe секциях, но он не предназначен для указателей by design. Но при этом продолжает проверять ссылки. Хотите пример — держите https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=29e9aef02a12d840b81919c83166a31f. А ваша аргументация — это что-то в стиле "я отключил ПДД, так как лечу на самолете".
"Все" действительно лишнее, вы правы.
А вас я во лжи и не обвинял нигде. Давайте восстановим, как было дело:
Переформулирую: плохо, когда люди будут делать выбор, основываясь на неточной информации (и здесь я сделал вывод, что неточность в докладе была намеренная, так что — ложь).
Далее вы пишите:
То есть поддерживаете позицию, что можно говорить что угодно, главное — чтобы выбрали вашу любимую ("проверенную временем") технологию. И вот эту позицию я не разделяю.
Вы преувеличиваете. Люди просто рассказывают про хороший инструмент. Но вы воспринимаете это как-то в штыки, будто вас насильно заставляют на нем писать. Просто многим зашел этот инструмент, поэтому складывается ощущение, что "он везде". Возможно, это как раз свидетельство того, что он "взлетел" и действительно не так плох. А может и нет, не знаю.
Прочитал. Все еще придерживаюсь позиции, что по большей части, все перечисленное в статье — так.
А про дезинформацию: возьмем конкретный пункт "Плюсы Rust только в анализе времени жизни объектов." Это откровенная, явная неправда в такой формулировке, потому что как минимум раст похволяет не только контролировать лайфтаймы, но и отсутствие 2-х мутабельных ссылок на данные (ownership), в отличии от C++. Более того, ниже автор доклада явно повторил эту формулировку "Поэтому да — только lifetime", так что вопросы некорректной интепретации видео снимаются.
Так что да, я все еще считаю, что здесь есть "ложь во благо". И я считаю ее неприемлемой для технической дискуссии, даже если это всего лишь один раз за все выступление.
То есть вы поддерживаете позицию "ложь во благо"? Ну, не очень инженерный подход, прямо скажем.
На самом деле из этой сигнатуры
Можно даже сделать более интересный вывод: эта функция всегда возвращает b просто потому что
То есть функция не сможет вернуть что-либо, содержащееся в a (так как передан по немутабельной ссылке), и не сможет сконструировать сама значение типа T. Остается b.
P.S.
Отдельно спасибо за формулировку, использованную в описании приложений: скриншоты рассылаемых администраторам доменных имен, находящихся на обслуживании ....
Скриншоты чего? Наверно, конечно, писем. Видимо так торопились написать хоть что-то, что даже не перечитали потом.