fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

9.8K
active users

#GoLang

132 posts76 participants14 posts today

Yeah, it's about security in Go.
No, I'm not a security expert.
Yes, it's still a good starting point:

- A list of three lists of security measures you can take to make your Go apps less vulnerable
- Plus a list of further readings -> Here be experts!

appliedgo.net/spotlight/securi

#golang
appliedgo.net/spotlight/securi

Applied Go · Security: The Habits That Matter MostSecurity is more crucial than ever. Making security an afterthought is a footgun. Learn how to write secure Go code from the start.
Replied in thread

@takeonrules there is a difference between "legible code" and "legible happy path only". I've had numerous discussions with teams on the topic and we literally went through the GH issue describing different error handling proposals for #golang and.. We somehow found a way to live with the current tradeoffs.

For me personally legibility means that I can tell at a glance (in a PR!) which call can fail and what happens in an error scenario. I want my colleagues to think about failures upfront and not just rethrow on autopilot. Code that fits on the screen and in my head.

Having said that, I wish that there was a way to call five functions and if any fails, I want the same time of error handling (or adding context to the err). But even if there was something like this, how do I prevent less experienced devs from just using this everywhere? And then coming up with smart solutions /s and generic functions etc?

In the end I rather have ugly code and the occasional if-err salad - prime example being sending SMTP, than sacrificing unhappy path visibility.

Часть 3. Векторизация на Go: CGo, транзакции, компиляторы, поддержка, байтовые инструкции

В первой части статьи мы рассмотрели , как можно вручную ускорить Go-код с помощью векторизации и SIMD-инструкций, реализованных через Go-ассемблер. Написали простую, но показательно быструю реализацию sliceContains и увидели, что даже базовая векторизация может дать ускорение в 10–14 раз по сравнению со стандартной реализацией. Во второй части статьи погрузились в практическое применение SIMD в Go-ассемблере, реализовали функцию SliceContainsV1 и изучили, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач. Но возможности оптимизации Go-программ на этом не заканчиваются. В этой части мы пойдём дальше: рассмотрим другие техники низкоуровневой оптимизации — от использования C-кода и альтернативных компиляторов с поддержкой векторизации до работы с аппаратными транзакциями памяти на Intel. Поговорим о том, как внедрять ассемблер в продакшен-код, не боясь за его поддержку, и как обойти ограничения стандартного Go-компилятора. Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества, веду телеграм-канал и youtube-канал. Если вы уже знакомы с базовыми техниками векторизации, эта часть поможет глубже понять, как устроены продвинутые способы ускорения Go-кода и на что стоит обратить внимание при работе с архитектурно-зависимыми оптимизациями.

habr.com/ru/companies/oleg-bun

ХабрЧасть 3. Векторизация на Go: CGo, транзакции, компиляторы, поддержка, байтовые инструкцииВ первой части статьи мы рассмотрели , как можно вручную ускорить Go-код с помощью векторизации и SIMD-инструкций, реализованных через Go-ассемблер. Написали простую, но показательно быструю...