ну да, к сожалению.. я за "the right tool for the right job", но порой это жуткий context switch, другие библиотеки, другие парадигмы, другие инструменты, сильно понижает продуктивность поэтому зачастую языки использую не по назначению, чисто ради сохранения продуктивности и воизбежание просадки

На работе регулярно использую 3 языка, ещё 2 языка использую как хобби. Брат жив, зависимость есть.

так зачем тебе питон, если JavaScript тебе роднее да ещё и V8 зачастую быстрее питонского runtime'а

да и вообще, если один только Javascript тебе как родной, при этом тебя заставляют писать бэк - то с тобой что-то не так, ну либо с менеджментом :)

да и вообще, если один только Javascript тебе как родной, при этом тебя заставляют писать бэк - то с тобой что-то не так, ну либо с менеджментом :)

всё зависит от проекта. Если там пукалка какая-то то бизнес задача будет решена в срок, коряво, но решена. Если вы каждую бизнес задачу будет решать "идеально" то вы обанкротитесь) но таки да, в перспективе стоит учить Go и медленно и постепенно на него переходить для повышения квалификации

На работе регулярно использую 3 языка, ещё 2 языка использую как хобби. Брат жив, зависимость есть.

вот я тоже планирую Rust постепенно параллельно изучать, ибо возвращаться в C++ совсем не хочу для тех задач для которых Go не подходит, мурашки по телу от такой мысли

вот я тоже планирую Rust постепенно параллельно изучать, ибо возвращаться в C++ совсем не хочу для тех задач для которых Go не подходит, мурашки по телу от такой мысли

дождаться когда Rust выстреллит и все

дождаться когда Rust выстреллит и все

Если бы все только ждали, то он бы никогда не выстрелил.

дождаться когда Rust выстреллит и все

😂 если на стене висит руст, то к концу пьесы он обязательно выстрелит

Если бы все только ждали, то он бы никогда не выстрелил.

а что проблему Пуанкаре на Rust решили?😂 Doker ,кубернетес ,эластик?

Go'шная продуктивность порой скорее иллюзия продуктивности. Потому-что Go далёк от "безопасносго" языка. Можно впилить в программу segfault'ов, data race'ов, необработанных ошибок и прочие прелести, которые потом сожрут много времени на дебагинг. Да, можно и нужно использовать линтеры и анализаторы кода (errcheck, megacheck etc.). Mожно и нужно использовать race detector, но кто же использует его в продакшне учитывая его неимоверный performance & memory overhead? Нужно следовать правильному стилю (не допускать mutable shared state и т.д.) Но порой таки жить легче и продуктивность повышается, когда ты можешь быть уверен, что всего этого не будет в продакшне, если компиляция прошла успешно

Go'шная продуктивность порой скорее иллюзия продуктивности. Потому-что Go далёк от "безопасносго" языка. Можно впилить в программу segfault'ов, data race'ов, необработанных ошибок и прочие прелести, которые потом сожрут много времени на дебагинг. Да, можно и нужно использовать линтеры и анализаторы кода (errcheck, megacheck etc.). Mожно и нужно использовать race detector, но кто же использует его в продакшне учитывая его неимоверный performance & memory overhead? Нужно следовать правильному стилю (не допускать mutable shared state и т.д.) Но порой таки жить легче и продуктивность повышается, когда ты можешь быть уверен, что всего этого не будет в продакшне, если компиляция прошла успешно

А я юнит тесты пишу....😞

А я юнит тесты пишу....😞

Go'шная продуктивность порой скорее иллюзия продуктивности. Потому-что Go далёк от "безопасносго" языка. Можно впилить в программу segfault'ов, data race'ов, необработанных ошибок и прочие прелести, которые потом сожрут много времени на дебагинг. Да, можно и нужно использовать линтеры и анализаторы кода (errcheck, megacheck etc.). Mожно и нужно использовать race detector, но кто же использует его в продакшне учитывая его неимоверный performance & memory overhead? Нужно следовать правильному стилю (не допускать mutable shared state и т.д.) Но порой таки жить легче и продуктивность повышается, когда ты можешь быть уверен, что всего этого не будет в продакшне, если компиляция прошла успешно

любое частное мнение имеет право на жизнь, хоть я и не согласен в корне с иллюзиями и тд - все легко меряется и кто хотел уже померял

А я юнит тесты пишу....😞

testing более подвержен ошибкам, нежели концепция ownership & borrowing, но писать код в таком стиле то ещё "удовольствие", к этому надо привыкнуть)

Юнит тесты для частей. Чтобы быть уверенным, что они не сломаны + короткий дебагинг для целого.

Я не люблю баги в продакшн отправлять.

Я не люблю баги в продакшн отправлять.

никто не любит. но тесты пишут люди, а люди не алгоритмы) 1. тесты могут содержать ошибки 2. тесты могут упустить некоторые критичные ситуации о которых тестировщик не знал/забыл

никто не любит. но тесты пишут люди, а люди не алгоритмы) 1. тесты могут содержать ошибки 2. тесты могут упустить некоторые критичные ситуации о которых тестировщик не знал/забыл

1. Процент в квадрате уменьшается. 2. Есть такая хрень как покрытие

никто не любит. но тесты пишут люди, а люди не алгоритмы) 1. тесты могут содержать ошибки 2. тесты могут упустить некоторые критичные ситуации о которых тестировщик не знал/забыл

Чтобы неправильный тест прокатил, надо, чтобы и код был неправильный и тест. И при этом код давал тот же неправильный ответ, что и тест.

и этио распространенная ситуация, кстати

и этио распространенная ситуация, кстати

Для этого можно писать допустим два теста на ветку

и этио распространенная ситуация, кстати

С таким вообще не встречался. Но раз вы встречались, возможно, я не прав

обычно тест и реализацию пишет один человек

и если он неправильно понял спеку - он напишет одинаково неправильные и реализацию, и тест

и если он неправильно понял спеку - он напишет одинаково неправильные и реализацию, и тест

Для этого небольшой дебагинг после

и если он неправильно понял спеку - он напишет одинаково неправильные и реализацию, и тест

легко писать: - не правильный тест, к правильной реализации спеки - правильный тест, к не правильной реализации спеки - не писать тест, который покрывает "граничные условия" правильно реализованной спеки, но условия в спеке не описали - писать тест, который покрывает граничные условия и правильно реализует спеку, но имеет "сайд эффект", который возможно выявить в интеграционном тесте, но которого часто нет если компилятор ЯП не позволяет сделать какие-то критичные ошибки - это всегда лучше потому что человек даже при условии наличия тестов, наличия код ревью, наличия QA всегда может сделать ошибку, которая совсем не очевидна и проявляется только в продакш и только при определенных условиях (входных данных, только определенных ответах внешнего сервиса, тольк в строго определенное время/период и т.д.) . чем больше компилятор "поможет не сделать ошибку", тем лучше, это вполне очевидно.

1. Процент в квадрате уменьшается. 2. Есть такая хрень как покрытие

Даже 100% покрытие не даёт никаких гарантий. Тесты нужны только для поиска ошибок. Как средство доказательства их отсутствия тесты никуда не годятся.

Даже 100% покрытие не даёт никаких гарантий. Тесты нужны только для поиска ошибок. Как средство доказательства их отсутствия тесты никуда не годятся.

еще тесты нужны, как средство написания кода для правильной спеки и удобного/быстрого запуска/отладки этого кода

Там где действительно нужна безопасность обычно используется формальная верификация. Если же у вас из средств отлова ошибок только тесты, то безопасность вам нужна только где-то сбоку и только для галочки.

посмотрел что такое "формальная верификация"... и понял, что "жизнь прожита почти зря" :)

посмотрел что такое "формальная верификация"... и понял, что "жизнь прожита почти зря" :)

Статическая типизация - тоже сорт оф

В будущем, когда в IT появится какая-то инженерная культура, формальной верификации, я уверен, станет намного больше.

1. Процент в квадрате уменьшается. 2. Есть такая хрень как покрытие

полное покрытие кода тестами это порой иллюзия отсутствия багов. самые страшные баги, которые могут годами проходить незаметно - определяются скорее не тем что "все строчки были вызваны", а скорее в совокупности того "какие строчки были вызваны в каком порядке", но такой информации покрытие, насколько мне известно, не предоставляет.

полное покрытие кода тестами это порой иллюзия отсутствия багов. самые страшные баги, которые могут годами проходить незаметно - определяются скорее не тем что "все строчки были вызваны", а скорее в совокупности того "какие строчки были вызваны в каком порядке", но такой информации покрытие, насколько мне известно, не предоставляет.

Для такого необходимо проверить программу со всеми возможными входными данными. Что в подавляющем большинстве случаев, конечно, невозможно.

тесты не могут 100% гарантировать абсолютное отсутствие багов. Да, хорошо написанные тесты значительно сокращают их вероятность, но всегда стоит иметь ввиду, что сокращение количества путей к достижению определённых ошибок - эссенциально

Интересуешься блокчейном, его разработкой и уязвимостями? Есть уникальная возможность обсудить все вопросы с ведущими хакерами мира. Все они будут 9 октября в Чернобыль-туре в рамках конференции HackIT 4.0 в Киеве, которая пройдет с 10 по 11 октября. Promo code telegramfollower даст тебе скидку -30% Поспеши! Осталось всего три дня до закрытия регистрации в Чернобыль - https://hacken.live/2OcJTAd

HackIT

в шаббат? 🙂

хоть бы проблему описал

шабат уже по средам?

шабат уже по средам?

Так суббота же

с 9 по 11 октября?

Привет

немного обновил "статейку" https://twitter.com/romshar/status/1046073533967859712

HackIT

И потом облучишься, и проживёшь пару лет. Хотите хайпа, но с чувством юмора плохо?

Как говорил знакомый прапорщик, лучше перебздеть...

слушайте, а где pro.go?

там же где go.pro

это спам go pro?

слушайте, а где pro.go?

уже нигде

слушайте, а где pro.go?

pro.go закрыт

Груздь жеж

слушайте, а где pro.go?

умерло то сообщество, с голоду

слушайте, а где pro.go?

тут

слушайте, а где pro.go?

его закрыли, потому что владелец пропал и канал поддеживать нельзя без него

хм, странно

его закрыли, потому что владелец пропал и канал поддеживать нельзя без него

я это и написал выше

надо было на j2e писать :)

я это и написал выше

надо. больше. подробностей

в следующий раз 🙂

его закрыли, потому что владелец пропал и канал поддеживать нельзя без него

А я думал потому что там люди были неадекватные

а все люди которые там были, они тут

поэтому машинное масло в компот уже завтра

А какой язык какой характер даёт? Если, допустим (я не уверен), Go даёт зло, а Haskell (опять же, я не уверен) даёт добро (потому, что "учите хаскелл во время добра"), то в каком соотношении это проявляется? А Python как влияет на человека?

Извините, я совсем нуб

Мне кажется, python даёт тягу к флуду

питонист! хватайте его

очень даже от группы, в этой группе стараются порядок поддерживать, а в той был ад и спарта

Что обсуждают?

Скинь чат заодно )0

Сенкс

Ну с сишешкой конечно же!

по сравнению со спидами

на расте апишка - боль)

На расте - боль.

:)

https://habr.com/post/338268/

там дальше всё понятно становится)

rust быстрее на совсем чуть чуть

еще не особо понятно как там этот hyper устроен в плане асинхронности - один тред, много тредов, много грин тредов