Forwarded from Melt!
В США FAANG, а в России ВСРАТОСЛАВ:
ВК + Сбербанк + Рамблер + Акронис + Тиньков + Озон + Суперджоб + Ланит + Авито + ВТБ
ВК + Сбербанк + Рамблер + Акронис + Тиньков + Озон + Суперджоб + Ланит + Авито + ВТБ
Forwarded from RustCon - конференция по языку программирования Rust
А в программу RustCon проходит ... Вафель!
Вот что он сам пишет про свою тему "Неочевидные прелести Rust":
В Rust много неочевидных, но очень приятных фич, особенностей, функций. Я спросил у людей, что их приятно удивило при изучении раста и собрал все ответы в один список.
Теперь я хочу рассказать об этих прелестях, чтобы как можно больше разработчиков о них знали и могли ими пользоваться :)
Несколько примеров пунктов из списка:
👉 Result: FromIterator (.collect:<Result<_, _>>())
👉 Возможность использования паттернов везде (например в аргументах функций, let)
👉 Создание массивов через [CONST; N] для T: !Copy
Тезисы других докладов смотрите на сайте
Билеты там же😉
Вот что он сам пишет про свою тему "Неочевидные прелести Rust":
В Rust много неочевидных, но очень приятных фич, особенностей, функций. Я спросил у людей, что их приятно удивило при изучении раста и собрал все ответы в один список.
Теперь я хочу рассказать об этих прелестях, чтобы как можно больше разработчиков о них знали и могли ими пользоваться :)
Несколько примеров пунктов из списка:
👉 Result: FromIterator (.collect:<Result<_, _>>())
👉 Возможность использования паттернов везде (например в аргументах функций, let)
👉 Создание массивов через [CONST; N] для T: !Copy
Тезисы других докладов смотрите на сайте
Билеты там же😉
#prog #rust #article
Статья о
Статья о
#[derive(Clone)] и о том, почему стандартный дерайв-макрос ставит ограничение Clone на тИповые параметры, а не на типы полей.Stegosaurus Dormant
Understanding #[derive(Clone)] in Rust
This post assumes that you have an entry-level familiarity with Rust: you’ve fought with the borrow checker enough to start to internalize some of its model; you’ve defined structs, implemented traits on those structs, and derived implementations of common…
#prog #cpp
Данила снова пишет интересное. На этот раз — про то, как можно оптимизировать работу приложений, подогнав под конкретную нагрузку реализации mem{cpy, set, cmp}.
P. S.: насчёт того, что всё написано на C++, авторы немного лукавят:
Данила снова пишет интересное. На этот раз — про то, как можно оптимизировать работу приложений, подогнав под конкретную нагрузку реализации mem{cpy, set, cmp}.
P. S.: насчёт того, что всё написано на C++, авторы немного лукавят:
__builtin_memcpy_inline и __restrict не являются частью стандарта C++. Но это уже, по большому счёту, придиркиTelegram
Experimental chill
Этот пост я написал ещё в июле, но он мне показался скучным. Сегодня я его случайно рассказал паре людей и им понравилось, поэтому вот.
В распределённых приложениях и даже на обычных серверах невероятно сложно мерить перформанс mem* функций (например, memcpy…
В распределённых приложениях и даже на обычных серверах невероятно сложно мерить перформанс mem* функций (например, memcpy…
#prog #rust #rustreleasenotes
Вышла версия Rust 1.56! На этот раз Вафель меня опередил, так что читайте его о нововведениях этой версии.
Вышла версия Rust 1.56! На этот раз Вафель меня опередил, так что читайте его о нововведениях этой версии.
Telegram
Мне не нравится реальность
# Rust 1.56.0
Вчера вышел Rust 1.56, включающий в себя многие вкусные плюшки, по большей части связанные с новой, 2021 редакцией. Подробнее про 2021 редакцию можно прочитать в edition guide, но я постараюсь кратко просуммировать изменения:
— В prelude добивили…
Вчера вышел Rust 1.56, включающий в себя многие вкусные плюшки, по большей части связанные с новой, 2021 редакцией. Подробнее про 2021 редакцию можно прочитать в edition guide, но я постараюсь кратко просуммировать изменения:
— В prelude добивили…
Только что ко мне в БК подошёл чел и предложил мне тысячу рублей, если я установлю TikTok 😐
#prog #article
В последние годы в употребление вошло словосочетание software engineer. Само это словосочетание подразумевает, что работа разработчиков программного обеспечения сравнима с деятельностью инженеров из более традиционных областей индустрии. Много копий было сломано на тему того, можно ли разработчиков и впрямь называть инженерами. К сожалению, эти умствования были малополезны, поскольку все из них были написаны разработчиками без опыта работы в традиционном инженерном деле. Как следствие, их авторы исходили не из реальных представлений о работе инженеров, а из своих стереотипов, которые имели к практике весьма опосредованное отношение.
Hillel Wayne избрал более надёжный подход: признав, что он не в состоянии самостоятельно рассуждать на эту тему, он провёл на эту тему интервью с полутора десятком людей, которые сейчас работают разработчиками, но были ранее инженерами (в их число с неожиданностью для автора вошёл Nick Coghlan, который сейчас больше известен, как один из разработчиков CPython, но до этого работал инженером системной интеграции в Boeing). Этих людей автор в дальнейшем называет "crossovers". Информацию их интервью с этими людьми автор в итоге суммировал в трёх эссе. Если вы спешите, то вот заключение из последнего из них:
To summarize my ultimate conclusions:
First of all, We software engineers are “really” engineers. All the differences people give between software and “real” engineering don’t accurately reflect what “real” engineering looks like. And the biggest difference, licensure, is a political construct, not a technical one. At the same time, there is a difference between the different ways people make software, and it makes sense to think of software developers and software engineers as distinct concepts. But even then, it’s very easy for a software developer to become a software engineer and vice versa.
Second, we are not special. There are some aspects of software engineering that are unique to software, such as the speed of iteration, loose constraints, and the consistency of our material. But software engineering has far more in common with the other forms of engineering than it has differences. The same ideas that engineers use to advance their craft are equally useful in our own domain.
Finally, there is a lot we can both teach and learn. Engineering processes are more sophisticated than ours in ways that we can extract lessons from. Traditional engineers have a stronger sense of professionalism and responsibility than we tend to. In contrast, our culture is much more open and our communities much stronger than what exists in trad engineering. And our developments in version control have the potential to revolutionize traditional engineering.
Тем не менее, сами эссе, разумеется, раскрывают тему более развёрнуто, так что всячески рекомендую их к прочтению:
Are We Really Engineers?
We Are Not Special
What engineering can teach (and learn from) us
В последние годы в употребление вошло словосочетание software engineer. Само это словосочетание подразумевает, что работа разработчиков программного обеспечения сравнима с деятельностью инженеров из более традиционных областей индустрии. Много копий было сломано на тему того, можно ли разработчиков и впрямь называть инженерами. К сожалению, эти умствования были малополезны, поскольку все из них были написаны разработчиками без опыта работы в традиционном инженерном деле. Как следствие, их авторы исходили не из реальных представлений о работе инженеров, а из своих стереотипов, которые имели к практике весьма опосредованное отношение.
Hillel Wayne избрал более надёжный подход: признав, что он не в состоянии самостоятельно рассуждать на эту тему, он провёл на эту тему интервью с полутора десятком людей, которые сейчас работают разработчиками, но были ранее инженерами (в их число с неожиданностью для автора вошёл Nick Coghlan, который сейчас больше известен, как один из разработчиков CPython, но до этого работал инженером системной интеграции в Boeing). Этих людей автор в дальнейшем называет "crossovers". Информацию их интервью с этими людьми автор в итоге суммировал в трёх эссе. Если вы спешите, то вот заключение из последнего из них:
To summarize my ultimate conclusions:
First of all, We software engineers are “really” engineers. All the differences people give between software and “real” engineering don’t accurately reflect what “real” engineering looks like. And the biggest difference, licensure, is a political construct, not a technical one. At the same time, there is a difference between the different ways people make software, and it makes sense to think of software developers and software engineers as distinct concepts. But even then, it’s very easy for a software developer to become a software engineer and vice versa.
Second, we are not special. There are some aspects of software engineering that are unique to software, such as the speed of iteration, loose constraints, and the consistency of our material. But software engineering has far more in common with the other forms of engineering than it has differences. The same ideas that engineers use to advance their craft are equally useful in our own domain.
Finally, there is a lot we can both teach and learn. Engineering processes are more sophisticated than ours in ways that we can extract lessons from. Traditional engineers have a stronger sense of professionalism and responsibility than we tend to. In contrast, our culture is much more open and our communities much stronger than what exists in trad engineering. And our developments in version control have the potential to revolutionize traditional engineering.
Тем не менее, сами эссе, разумеется, раскрывают тему более развёрнуто, так что всячески рекомендую их к прочтению:
Are We Really Engineers?
We Are Not Special
What engineering can teach (and learn from) us
Hillel Wayne
Are We Really Engineers?
This is part one of the Crossover Project. Part two is here and part three is here. A conference talk based on this work is now available here.
I sat in front of Mat, idly chatting about tech and cuisine. Before now, I had known him mostly for his cooking…
I sat in front of Mat, idly chatting about tech and cuisine. Before now, I had known him mostly for his cooking…