Ну вот "евангелист" берет А и пытается запихнуть его в X. По ходу он выясняет, почему именно это не получается, и становится понятно, как развивать дальше А, чтобы он мог в X и был там желаемым. Либо что А никоим образом не применим в X и попытки впихнуть его туда — тщетны.
На мой взгляд проблема заключается в том, что многие языки действительно претендуют на некую универсальность, тогда как другие — созданы исключительно для узкого спектра задач. Крики "каждому инструменту — своя область применения" ничего нам в понимании не прибавляют, ведь проблема в том, что у ряда инструментов действительно их область применения широка и пересекается с другими. Это не вопрос чьих-то мнений, хотя на этом уровне ведутся очень горячие споры, по-сути это вопрос объективных тенденций, которые мы должны исследовать, чтобы понять ситуацию.
Реализация аналога конструкции match из Rust на PHP с помощью стрелочных функций.
It's not as nice as Rust's match keyword, but once you start using PHP for functional programming (yep, that's a thing) I expect it will come in quite handy.
Match работает с паттернами сопоставления, не представляю, как подобное можно реализовать в языке без АТД и паттернов.
Я просто хотел уточнить, а в синтаксисе ли дело? Ну то есть вам не нравится синтаксис паттерн-матчинга в Rust (допустим) или сам паттерн-матчинг вам не знаком и непонятно зачем нужен? Просто Rust и Go по своим общеязыковым возможностям сильно в разных категориях ИМХО.
Смотря какие приложения. Что-то я все время сталкиваюсь с такими, для которых скорость работы и безопасность весьма важны. Ну и плюс язык с хорошей системой типов всегда предпочтительнее языка с плохой. Так что думаю, что Rust вполне конкурент для Java.
Когда-то я работал Java-разработчиком и во время прокрастинации писал код на Rust.
Теперь я работаю Rust-разработчиком и во время прокрастинации… пишу код на Rust.
Ну вот, например, как я решаю подобную задачу в Rust. У нас есть структура User, у которой поля приватные и отсутствует публичный конструктор. Соответственно сконструировать объект мы можем только в его модуле, где есть специальная функция, которая это делает. Функция осуществляет запрос к базе и соответственно либо конструирует объект по полученным данным, либо завершается с ошибкой. То есть, результат функции — это Result<User, DbError>. Теперь, получается, что при вызове этой функции мы обязаны запрограммировать обе возможные ветки (Result — это тип-сумма), и если где-то у нас есть структура Foo с полем типа User, я могу быть уверен, что пользователь всегда валидный, потому что получить его экземпляр возможно только если исполнение прошло по корректной ветке. Это при условии, что саму базу никто не меняет еще извне.
Интересно, что то же самое относится и к быстрому прототипированию. Мне, например, хорошая система типов в этом сильно помогает, ускоряет процесс и дает уверенность в работе написанного кода. Но для этого нужно сразу мыслить решение в категориях системы типов. А сторонники отсутствия типизации говорят, что типы им мешают при прототипировании и замедляют разработку. Потому что они мыслят решение в категориях операций с отдельными объектами, а не в отношении типов.
В том-то и дело, что он по-факту стал основным. Было ли это целью автора? Я думаю что да, хотя доказать этого не могу. И я думаю, что считаться с мнением сообщества — в котором ты ответственен за некий важный для него компонент — это нормально и даже необходимо. Возможно, Николай был другого мнения и продолжал считать, что только он вправе решать, как должен работать фреймворк, потому его и выбешивали "указки со стороны". Ну что же, жизнь все расставила по своим местам.
Автор имеено что счел решение скучным и некреативным, потому что использовать стандартный RefCell вместо собственного костыля — это очень скучно:
Being on the edge of your abilities is super fun. So uncreative change felt boring (oh! And author gave up copyright claims for that patch (a bit irony and sarcasm)). I’ve never used unsafe unintentionally, I use it because I believe usage is safe. There was no any malicious intentions. I believed it held mutable aliasing invariant and I was very happy that someone found real problem. I wanted to solve the problem, just with a bit of creativity. And use RefCell solution only if it would be not possible to solve it with any other way. Btw, I like the solution I found, it is in master and solves the problem at least one from the issue. If you want to push boundaries you have to touch this boundaries and sometimes you push too hard.
А зачем тогда он лез в комьюнити и позиционировал свой фреймворк как основной для Раста? Что он этим добивался? Хотел просто заработать себе очков на хайпе в молодой экосистеме? Назвался груздем — так полезай в кузов.
А с чего вы решили, что этого там небыло? Вот вам цитата:
Examples of behavior that contributes to creating a positive environment include:
Using welcoming and inclusive language
Being respectful of differing viewpoints and experiences
Gracefully accepting constructive criticism
Focusing on what is best for the community
Showing empathy towards other community members
В удаленном issue в обсуждениях вроде бы было сказано, что для воспроизведения UB там достаточно, чтобы некие две функции выполнялись одновременно и не важно, вызываются они напрямую, или нет. То есть сокрытие там проблему не рашало.
Именно. Удалять issue и затирать историю — это вообще свинство, где я потом буду знать о проблемах, когда у меня actix-web навернется? А у нас он уже два раза навернулся как минимум: первый раз сделали патч, который приняли. Второй раз — не успели. Я предложил свою помощь по исправлению некоторого бага, но ответом мне было молчание.
Сообщество выиграет. Сделает форк ну и просто поляна расчищена теперь для других, более community friendly. А до этого все говорили: "Зачем ты пилишь очередной веб-фреймворк, есть же Актикс". Ну вот.
Лучше бы она не улыбалась..
Ну вот "евангелист" берет А и пытается запихнуть его в X. По ходу он выясняет, почему именно это не получается, и становится понятно, как развивать дальше А, чтобы он мог в X и был там желаемым. Либо что А никоим образом не применим в X и попытки впихнуть его туда — тщетны.
На мой взгляд проблема заключается в том, что многие языки действительно претендуют на некую универсальность, тогда как другие — созданы исключительно для узкого спектра задач. Крики "каждому инструменту — своя область применения" ничего нам в понимании не прибавляют, ведь проблема в том, что у ряда инструментов действительно их область применения широка и пересекается с другими. Это не вопрос чьих-то мнений, хотя на этом уровне ведутся очень горячие споры, по-сути это вопрос объективных тенденций, которые мы должны исследовать, чтобы понять ситуацию.
Match работает с паттернами сопоставления, не представляю, как подобное можно реализовать в языке без АТД и паттернов.
Я просто хотел уточнить, а в синтаксисе ли дело? Ну то есть вам не нравится синтаксис паттерн-матчинга в Rust (допустим) или сам паттерн-матчинг вам не знаком и непонятно зачем нужен? Просто Rust и Go по своим общеязыковым возможностям сильно в разных категориях ИМХО.
Смотря какие приложения. Что-то я все время сталкиваюсь с такими, для которых скорость работы и безопасность весьма важны. Ну и плюс язык с хорошей системой типов всегда предпочтительнее языка с плохой. Так что думаю, что Rust вполне конкурент для Java.
А Rust чем вам не подошел? Предвижу, что скажете — плохой синтаксис. Но чем именно он плох?
Когда-то я работал Java-разработчиком и во время прокрастинации писал код на Rust.
Теперь я работаю Rust-разработчиком и во время прокрастинации… пишу код на Rust.
(Основано на реальных событиях)
Ну вот, например, как я решаю подобную задачу в Rust. У нас есть структура
User, у которой поля приватные и отсутствует публичный конструктор. Соответственно сконструировать объект мы можем только в его модуле, где есть специальная функция, которая это делает. Функция осуществляет запрос к базе и соответственно либо конструирует объект по полученным данным, либо завершается с ошибкой. То есть, результат функции — этоResult<User, DbError>. Теперь, получается, что при вызове этой функции мы обязаны запрограммировать обе возможные ветки (Result — это тип-сумма), и если где-то у нас есть структураFooс полем типаUser, я могу быть уверен, что пользователь всегда валидный, потому что получить его экземпляр возможно только если исполнение прошло по корректной ветке. Это при условии, что саму базу никто не меняет еще извне.Интересно, что то же самое относится и к быстрому прототипированию. Мне, например, хорошая система типов в этом сильно помогает, ускоряет процесс и дает уверенность в работе написанного кода. Но для этого нужно сразу мыслить решение в категориях системы типов. А сторонники отсутствия типизации говорят, что типы им мешают при прототипировании и замедляют разработку. Потому что они мыслят решение в категориях операций с отдельными объектами, а не в отношении типов.
В том-то и дело, что он по-факту стал основным. Было ли это целью автора? Я думаю что да, хотя доказать этого не могу. И я думаю, что считаться с мнением сообщества — в котором ты ответственен за некий важный для него компонент — это нормально и даже необходимо. Возможно, Николай был другого мнения и продолжал считать, что только он вправе решать, как должен работать фреймворк, потому его и выбешивали "указки со стороны". Ну что же, жизнь все расставила по своим местам.
Автор имеено что счел решение скучным и некреативным, потому что использовать стандартный RefCell вместо собственного костыля — это очень скучно:
А зачем тогда он лез в комьюнити и позиционировал свой фреймворк как основной для Раста? Что он этим добивался? Хотел просто заработать себе очков на хайпе в молодой экосистеме? Назвался груздем — так полезай в кузов.
А с чего вы решили, что этого там небыло? Вот вам цитата:
https://github.com/fafhrd91/actix-web/blob/master/CODE_OF_CONDUCT.md
В удаленном issue в обсуждениях вроде бы было сказано, что для воспроизведения UB там достаточно, чтобы некие две функции выполнялись одновременно и не важно, вызываются они напрямую, или нет. То есть сокрытие там проблему не рашало.
Насколько я знаю в MS он и так работал над этим проектом фулл-тайм. Может быть как раз в этом причина выгорания.
Здесь вопрос не о технической возможности сообществу продолжать разработку, а об отношении самого автора к сообществу.
Именно. Удалять issue и затирать историю — это вообще свинство, где я потом буду знать о проблемах, когда у меня actix-web навернется? А у нас он уже два раза навернулся как минимум: первый раз сделали патч, который приняли. Второй раз — не успели. Я предложил свою помощь по исправлению некоторого бага, но ответом мне было молчание.
Как я понял, его цель продолжать пилить проект в одиночку но как закрытый. О какой передачи сообществу при таких целях может идти речь?
Сообщество выиграет. Сделает форк ну и просто поляна расчищена теперь для других, более community friendly. А до этого все говорили: "Зачем ты пилишь очередной веб-фреймворк, есть же Актикс". Ну вот.