выходные же)

я абсолютно согласен что лучше просто взять C++ / Rust и не париться! Но тем не менее размышляю над тем как оправдать титул "general purpose programming language", поскольку на Go гораздо легче писать чем на C++ / Rust С гошным GC в принципе можно жить поскольку он оптимизирован не на throughput а на latency, главное мусора не создавать и всё будет окей.

Зачем general purpose

Вон Си++ метил в эту область

Удалось?)

Каждой задаче свой инструмент

Удалось?)

вполне, на нём можно что угодно написать (насколько это разумно это уже другой вопрос, главное что можно) 3D rendering, GUIs, APIs, DSPs, drivers, an operating systems kernel (maybe?)

вполне, на нём можно что угодно написать (насколько это разумно это уже другой вопрос, главное что можно) 3D rendering, GUIs, APIs, DSPs, drivers, an operating systems kernel (maybe?)

++, как и многое на GO? , хоть и без системного уровня

вполне, на нём можно что угодно написать (насколько это разумно это уже другой вопрос, главное что можно) 3D rendering, GUIs, APIs, DSPs, drivers, an operating systems kernel (maybe?)

Кто-то и на C умудряется все что угодно написать. Но нам то это зачем?

Кто-то и на C умудряется все что угодно написать. Но нам то это зачем?

суть была в том, что при титуле "general purpose" - Go для некоторых задач применять просто незовможно, не решает задачу, поэтому скорее не general purpose

Так что не получается нормально писать на Го?

Чем он не general purpose

суть была в том, что при титуле "general purpose" - Go для некоторых задач применять просто незовможно, не решает задачу, поэтому скорее не general purpose

а для каких задач НЕВОЗМОЖНО(если не системные)?

Так что не получается нормально писать на Го?

любая time-critical задача

написать то можно, но работать будет так-себе

любая time-critical задача

помещаете в рутину обьявляете переменные заранее ,никаких вызовов функций, не давайте пищи Гколлектору

а для каких задач НЕВОЗМОЖНО(если не системные)?

например, задачи с периодическими тасками, критичными по времени

помещаете в рутину обьявляете переменные заранее ,никаких вызовов функций, не давайте пищи Гколлектору

это если изолировать бинарь только под 1 задачу.. как только начинается работа с I/O и подобное - всё рушится из-за collective concurrency

Так можно отключить GC, если его задержки мешают

дело не в gc, дело в отсутствии гарантий по времени

Так можно отключить GC, если его задержки мешают

в продакшне отключить GC в языке который был designed for GC?))

Так можно отключить GC, если его задержки мешают

restart: always?

дело не в gc, дело в отсутствии гарантий по времени

верно, это не страшно если у вас 10k одновременных клиентов и один запрос можно затянуть на секунду и это терпимо..

в продакшне отключить GC в языке который был designed for GC?))

Если у вас такая задача то видимо да

верно, это не страшно если у вас 10k одновременных клиентов и один запрос можно затянуть на секунду и это терпимо..

в целом да

Если у вас такая задача то видимо да

если задача, для которой критичны задержки gc - то го не нужен

если задача, для которой критичны задержки gc - то го не нужен

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

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

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

например, джаваскрипт на сервере

например, джаваскрипт на сервере

да, вполне))

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

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

для очень маленьких проектов это лучше, чем тащить Go на бэкэнд, серьёзно, потому-что: продуктивность. но как только всё это начинает расти - можно спокойно выбрасывать Node.js сервер и писать backend на Go.

для очень маленьких проектов это лучше, чем тащить Go на бэкэнд, серьёзно, потому-что: продуктивность. но как только всё это начинает расти - можно спокойно выбрасывать Node.js сервер и писать backend на Go.

для очень маленьких проектов есть питон и какой-нибудь Flask/Bottle

с куда более взрослой экосистемой

для очень маленьких проектов есть питон и какой-нибудь Flask/Bottle

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

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

А если не роднее

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

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

А если не роднее

мы говорили про "1 language for both stacks"

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

ладно, не будем спорить, не про питон группа))

Ну лан

ну да, к сожалению.. я за "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. тесты могут упустить некоторые критичные ситуации о которых тестировщик не знал/забыл

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

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

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

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

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

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

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

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

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

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

ERROR: S client not available

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в шаббат? ?

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

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

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

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

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

Привет

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

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

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

Там уже негде облучаться

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

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

там же где go.pro

это спам go pro?

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

уже нигде

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

pro.go закрыт

Груздь жеж

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

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

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

тут