безопасники новые потенциальные дырки в коде придумали

Они же кстати ещё и напрягали костыли для каждой версии каждого поддерживаемого файрвола ваять, а с неподдерживаемыми отказываться работать, и всё чтобы та сторона вообще ни о чём не могла догадаться %)

а 5% редких ты проверишь руками

Что? Там и unsafe, и #![feature(asm)], и #![deny(warnings)]

unsafe там точечно, а не как компьютерные аболиционисты предлагают весь код в unsafe заворачивать

вот и вся история

unsafe там точечно, а не как компьютерные аболиционисты предлагают весь код в unsafe заворачивать

я такое когда предлагал?

я такое когда предлагал?

С++ код - это один большой unsafe

я такое когда предлагал?

сишечьку пропагандировали? ну вот это оно и есть

Они же кстати ещё и напрягали костыли для каждой версии каждого поддерживаемого файрвола ваять, а с неподдерживаемыми отказываться работать, и всё чтобы та сторона вообще ни о чём не могла догадаться %)

а что эти безопасники охраняют?

сишечьку пропагандировали? ну вот это оно и есть

Си намного проще раста в освоении

а что эти безопасники охраняют?

Клиентские данные, надо понимать %)

Си намного проще раста в освоении

а php еще проще

Си намного проще раста в освоении

в освоении да, в эксплуатации – "ну извините"

Вот только кто у них клиенты - это и самим безопасникам не ведомо %)

и в эксплуатации, си не стоит на пути и не требует читерской архитектуры

Короче

Спокойно

дайте скажу)

и в эксплуатации, си не стоит на пути и не требует читерской архитектуры

Пиши на С

когда накушаешься глобальных мутабельных стейтов поймешь, зачем раст придумали

А может и ведомо, но скрывают %) Безопасники такие безопасники

и зачем там эти все приседания с unsafe нужны

а пока не накушался ты просто не понимаешь, зачем это

хорошо, о великий гуру

Раст — это лекарство, его бесполезно принимать без симптомов болезни: не увидишь разницу и не поймёшь, зачем он нужен, от чего лечит и почему он такой. Но если ты болел и принял нужное лекарство, то всё встает на свои места

хорошо, о великий гуру

я не великий гуру, я просто говён немножко накушался)

хорошо, о великий гуру

не, уважаемый, это вы – гуру. очередной.

Что же в Lisp'е такого прекрасного? Если он такой замечательный, почему его не используют все? Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы. Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих. И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений. Я начну с шокирующего утверждения: языки программирования отличаются друг от друга своей мощностью. По крайней мере мало кто будет спорить, что высокоуровневые языки более мощные, чем машинный язык. Большинство программистов согласятся, что, как правило, программировать стоит не на машинном языке, а на каком-нибудь языке высокого уровня, переводя программу в машинный код с помощью компилятора. Сейчас эта идея получила даже аппаратное воплощение — с восьмидесятых годов команды процессоров разрабатываются скорее для компиляторов, чем для программистов. Каждый знает, что писать всю программу вручную на машинном языке — ошибочно. Но гораздо реже понимают то, что существует и более общий принцип: при наличии выбора из нескольких языков ошибочно программировать на чем-то, кроме самого мощного, если на выбор не влияют другие причины. Все языки одинаково мощные, если рассматривать их с точки зрения эквивалентности машине Тьюринга, но это не та мощь, которая важна программисту. (Никто ведь не хотел бы программировать машину Тьюринга). Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это. Но, скажем, если язык A поддерживает рекурсию, а B — нет, это нечто, что нельзя исправить написанием библиотечных функций. Есть много исключений из этого правила. Если вы пишете программу, которая должна тесно взаимодействовать с программой, написанной на определенном языке, возможно, окажется разумным писать новую программу на том же языке. Если вы пишете программу, которая должна делать что-то очень простое, вроде численной обработки больших массивов данных или манипуляций с битами, можно использовать язык не самого высокого уровня абстракции, тем более что программа будет слегка быстрее. Если вы пишете короткую программу, которую используете один раз и выбросите прочь, возможно, следует использовать тот язык, который имеет лучшие библиотечные функции для данной задачи. Но в целом для программного обеспечения нужно использовать самый мощный (и приемлемо эффективный) язык из всех доступных. Отличный от этого выбор — это ошибка такого же рода, как упор на программирование в машинных кодах, хотя и с меньшими негативными последствиями. Понятно, что уровень машинного языка очень низок. А высокоуровневые языки часто рассматриваются как одинаковые, по-крайней мере, так принято считать. Но это не так. Технический термин "язык программирования высокого уровня" не обозначает ничего определенного. Не существует четкой границы между множеством "машинных" языков с одной стороны, и множеством "высокоуровневых" с другой. Языки распределены в континууме (возможно, не просто континуум, а некая структура, уменьшающяяся кверху; важна здесь не форма, а сама идея о том, что существует по крайней мере частичный порядок) абстрактности, начиная от самых мощных "языков высокого уровня" вниз к "машинным языкам", которые, в свою очередь, тоже отличаются друг от друга по мощности.

Возьмем Cobol. Cobol — язык высокого уровня, так как компилируется в машинный язык. Но станет ли кто-нибудь утверждать, что по мощности Cobol эквивалентен, скажем, Python'у? Возможно, он ближе к машинному языку, чем Python. А как насчет Perl четвертой версии? В Perl 5 в язык были добавлены лексические замыкания (lexical closures). Большинство Perl хакеров согласятся, что Perl 5 мощнее, чем Perl 4. Но раз вы это признали, вы признали, что один высокоуровневый язык может быть мощнее другого. Из этого неизбежно следует, что использовать нужно самый мощный язык. Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли. Программисты очень привязываются к своим любимым языкам, а я не хочу оскорбить ничьи чувства, поэтому я объясню свою позицию, используя гипотетический язык с названием Блаб. Блаб попадает в середину континуума абстрактности. Это не самый мощный язык, но он мощнее, чем Cobol или машинный язык. И на самом деле, наш гипотетический программист на Блабе не будет использовать ни Cobol, ни машинный код. Для машинных кодов есть компиляторы. Что же касается Cobol'а, наш программист не знает, как на этом языке вообще что-то можно сделать. В Cobol'е даже нет некой возможности X, присутствующей в Блабе. Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе. Когда мы поменяем точку обзора программиста, используя любой язык программирования выше по континууму мощности, мы обнаружим, что теперь программист смотрит на Блаб сверху вниз. "Как же можно что-то сделать, используя Блаб? В нем отсутствует даже конструкция Y!" Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык, в состоянии осознать полную картину разницы в мощности между различными языками (видимо, именно это имел ввиду Эрик Реймонд, когда говорил о том, что Lisp сделает вас лучше как программиста). Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.

Scientist почитай пасту выше, тут много интересного

http://www.nestor.minsk.by/sr/2003/07/30710.html - тут полная версия статьи

по-моему мы спорим о чем-то, о чем нет смысла спорить

ТЫ НЕ ПОНИМАЕШЬ СУТЬ РАСТОЧАТА

Раст — это лекарство, его бесполезно принимать без симптомов болезни: не увидишь разницу и не поймёшь, зачем он нужен, от чего лечит и почему он такой. Но если ты болел и принял нужное лекарство, то всё встает на свои места

"Во-первых, Rust - это красиво"

У меня дежа-вю

Пиши на С

да не в С даже дело. я на питоне жрал гавно мутаьельных глобалстейтов. by design такое было в архитектуре

а что эти безопасники охраняют?

О! Вы таки будете смеяться, но они уже дошли до того, что "вы можете использовать аппаратное ускорение блочного шифрования, но при условии чтобы с некоторой средней периодичностью производились рандомные проверки на корректность, и если где не будет чуть совпадать результат - бить тревогу сразу в отдел К, а сервер изолировать в сэндбоксе до выяснения обстоятельств")

да не в С даже дело. я на питоне жрал гавно мутаьельных глобалстейтов. by design такое было в архитектуре

ну человек сравнивает с С, я и говорю про С)

так-то я не знаю других языков с защитой от мутабельности на уровне типа

это же киллер-фича именно раста вроде

так что можно подставить любой язык Х

кроме каких-нибудь чисто-функциональных хаскеллей, где все равно в IO можно навертеть всякого

Типа бэкдоров в аппаратном ускорении AES боятся %)

О! Вы таки будете смеяться, но они уже дошли до того, что "вы можете использовать аппаратное ускорение блочного шифрования, но при условии чтобы с некоторой средней периодичностью производились рандомные проверки на корректность, и если где не будет чуть совпадать результат - бить тревогу сразу в отдел К, а сервер изолировать в сэндбоксе до выяснения обстоятельств")

я бы там не работал)

Типа бэкдоров в аппаратном ускорении AES боятся %)

а все другие уязвимости попроще уже закрыли?

я бы там не работал)

А если там salary бы была в стопицот раз выше чем средняя по больнице? %)

А если там salary бы была в стопицот раз выше чем средняя по больнице? %)

так же

Си намного проще раста в освоении

Лол.

а все другие уязвимости попроще уже закрыли?

Типа известные (им) закрыли, а если кто знает неизвестные - не стесняйтесь, говорите, тоже закроем, и даже спасибо скажем)

Типа известные (им) закрыли, а если кто знает неизвестные - не стесняйтесь, говорите, тоже закроем, и даже спасибо скажем)

за сколько спасибо?

Про вменяемые баунти-программы они кажется не слышали %))

А если там salary бы была в стопицот раз выше чем средняя по больнице? %)

it depends

например я с зп в 150 собеседовался в crossover на зп 480

Возьмем Cobol. Cobol — язык высокого уровня, так как компилируется в машинный язык. Но станет ли кто-нибудь утверждать, что по мощности Cobol эквивалентен, скажем, Python'у? Возможно, он ближе к машинному языку, чем Python. А как насчет Perl четвертой версии? В Perl 5 в язык были добавлены лексические замыкания (lexical closures). Большинство Perl хакеров согласятся, что Perl 5 мощнее, чем Perl 4. Но раз вы это признали, вы признали, что один высокоуровневый язык может быть мощнее другого. Из этого неизбежно следует, что использовать нужно самый мощный язык. Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли. Программисты очень привязываются к своим любимым языкам, а я не хочу оскорбить ничьи чувства, поэтому я объясню свою позицию, используя гипотетический язык с названием Блаб. Блаб попадает в середину континуума абстрактности. Это не самый мощный язык, но он мощнее, чем Cobol или машинный язык. И на самом деле, наш гипотетический программист на Блабе не будет использовать ни Cobol, ни машинный код. Для машинных кодов есть компиляторы. Что же касается Cobol'а, наш программист не знает, как на этом языке вообще что-то можно сделать. В Cobol'е даже нет некой возможности X, присутствующей в Блабе. Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе. Когда мы поменяем точку обзора программиста, используя любой язык программирования выше по континууму мощности, мы обнаружим, что теперь программист смотрит на Блаб сверху вниз. "Как же можно что-то сделать, используя Блаб? В нем отсутствует даже конструкция Y!" Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык, в состоянии осознать полную картину разницы в мощности между различными языками (видимо, именно это имел ввиду Эрик Реймонд, когда говорил о том, что Lisp сделает вас лучше как программиста). Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.

Лучше б эту пеленку через телеграф кинул

и не пошел

Лучше б эту пеленку через телеграф кинул

я кинул полную статью

ctrl+f и вперед

)

Каждый раз одно и тоже

например я с зп в 150 собеседовался в crossover на зп 480

а crossover это что за контора?

типа toptal

жесткий аутсорсер

например я с зп в 150 собеседовался в crossover на зп 480

Это тыр/месяц или килобакс/год?

первое

ctrl+f и вперед

Я контрол потерял

http://www.nestor.minsk.by/sr/2003/07/30710.html - тут полная версия статьи

click -> ctrl+F "Блаба"

и не пошел

Чому?

условия нечеловеческие

По результатам планирования года мы взяли в работу 5 задач и отвергли одну. Подробнее здесь: https://goo.gl/1saVrQ #rustycrate

ну и проекты уровня delphi + .Net 1.1

Это тыр/месяц или килобакс/год?

это мифических тысяч в месяц. Потому что в кроссовере, насколько я знаю, платят по фактическим часам, вплоть до слежения за десктопом. Соответственно 480 превращаются в 240, потому что никто 8 часов не вырабатывает. Минус больничные, праздники, отпуск и у тебя выходит уже 200

Выдавать килопроект в месяц на брейнфаке?

> РЕГЛАМЕНТ

чо пацаны никаких обнимашек?

прям как у фряхи

это мифических тысяч в месяц. Потому что в кроссовере, насколько я знаю, платят по фактическим часам, вплоть до слежения за десктопом. Соответственно 480 превращаются в 240, потому что никто 8 часов не вырабатывает. Минус больничные, праздники, отпуск и у тебя выходит уже 200

не, как раз-таки все по 8 часов и работают

но насчет выходных/праздников все верно

не, как раз-таки все по 8 часов и работают

по 8 часов без отрыва пишут код? я таких людей не видел еще

это мифических тысяч в месяц. Потому что в кроссовере, насколько я знаю, платят по фактическим часам, вплоть до слежения за десктопом. Соответственно 480 превращаются в 240, потому что никто 8 часов не вырабатывает. Минус больничные, праздники, отпуск и у тебя выходит уже 200

Ну 240 тоже неплохо я б сказал

4 часа, перерыв 4 часа