☕️ Мерлин заваривает τσάι 🐌
1.12K subscribers
3.52K photos
63 videos
94 files
2.42K links
💊
Download Telegram
Podlodka #209 – Операционные системы

Долго представлять эту тему не нужно, ведь выпуск входит в «золотой фонд фундаментальных выпусков» Podlodka и занимает место рядышком с "базами данных". Все, как вы любите – погружение в историю, разбор базовых компонентов и детские вопросы «а как загружается ОС?» с подробнейшими ответами на них. Под конец немного философских размышлений об упадке архитектуры ОС и стагнирующем настоящем, а также вероятности наступления светлого будущего. Осторожно, выпуск щедро приправлен байками!

Managed Kubernetes от Selectel для современных проектов: https://slc.tl/Gz62X, промокод Podlodka дает 1000 рублей на услугу. Вводить сюда: https://my.selectel.ru/vpc/

Сайт: https://podlodka.io/209
Soundcloud: http://bit.ly/podlodka-209
iTunes: https://apple.co/2vCBRcs 
Я.Музыка: https://bit.ly/32lGgNC

Поддержи лучший подкаст про IT: https://www.patreon.com/podlodka
В go{1.16, 1.15} сломаны циклы (не везде и не всегда, но всё же!).

Ждём минорного обновления.


UPD: пофиксили в свежем go1.16.3, не забудьте обновиться

https://github.com/golang/go/issues/45192
☕️ Мерлин заваривает τσάι 🐌
Время от времени приходится создавать типы-фасады, которым нужно часть методов «бэкенда» реализовывать, часть переопределять, а часть — затенить. Может быть это велосипед, но я тут сообразил для себя простой способ контролировать доступ к методам «родительского»…
#go
Ещё один велосипед -- если вам нужно унаследовать всё поведение от какого-то типа, но скрыть реализацию, то можно встраивать приватные алиасы к типам.

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

Ещё один пример: https://play.golang.org/p/V6XFhZ6UmLm
I was going to make a bullshit analogy to a programming language being like a hammer, but that’s too simplistic. The purpose of the software defines the stack you end up using, and there are far more considerations than “this is a nice language to use”. In fact, I’d wager that the niceness of the language is probably the least important part of choosing a language. Just ask everyone who bet the farm on coffeescript.

But the “you should use language X because it’s great” mantra doesn’t stop there. It’s a symptom of a larger problem: Thinking of programming as a worthwhile pursuit on its own, and focusing on the act of programming while ignoring how that software will be used.

https://georgestocker.com/2021/03/28/no-one-gives-a-shit-what-programming-language-you-use/
Forwarded from oleg_log (Oleg Kovalov)
Вчера запилил долгожданный и вечнооткладываемый диалог с @alexdemchenko о языках, и вот его текстовая версия.
Все начинается с вопроса: зачем создавался язык Х ?
Возьмем пхп. Автор его делал для работы с швблонами, про веб-сервера и прочие свистелки речи не шло, да и не было возможности и необходимости. Зачем создавался питон? Для обучения студла с минимальной мозговой активностью. О создании на нем дропбокса и гугла речи не шло(как и о сплите экосистемы на 2 и 3 лол). Зачем делалась ява? Да чтобы закрыть костыли плюсов, решив, что давайте все абстрагируем и сядем на этот кактус. Зачем была создана скала? Да еще проще - защитить пхд и забить на реализацию компилятора, спасибо жвм. Речи об инженерных вещах тоже не было. А выстрелила только потому, что жава убога и медлительна в развитии(даже сейчас), но экосистема обширна. Зачем был груви? Да от балды, ведь это проблема жвм интерпретировать эти байты. Из всего, что я видел - груви хорош для тестов, из-за текучего синтаксиса. Кложура туда же, делалась любителем лиспа cause I can. Котлин был решением проблем жавы: а давайте больше фич, а почему бы не сделать кофескрипт для жвм. Ну и расширить этим аудиторию медлительного редактора от той же конторы. Кстати, я отчетливо помню хайп по кофескрипт в 2010-11. Он нужен был везде и всегда. Сейчас о нем и писка нет. Ничего это язык-решение не решал, да. Хаскелл это песочница ученых. О бизнес-пользе можно не заикаться даже.
Но что насчет языков поновее? Возьмем всеми любимый и уютный раст. Язык решал проблему написания безопасного, низкоуровневого кода, к примеру как драйвер или даже браузер. И в этой нише он хорош и таки решает боль. Зачем делался тайпскрипт и/или дарт? Просто избавить нас от ежедневного рака под названием жс. Зачем был эликсир? Дать хорошую и читабельную обертку над ерлангом, который ох как неплох. Свифт? - убрать очередной рак ака обж-с и улучшить жизнь разрабов яблочной фирмы. Моя любимая гошечка? - начать использовать ядра проца с максимальной эффективностью и уменьшить латенси новых сотрудников(за счет маленького количества фич).
Оставив факты о фичах и прочем на след статью, хочу упомянуть, что сравнивать языки по синтаксису это как спорить что лучше: французский или все же японский. Дело не в написании слов, а в том, какие проблемы язык может решить и таки решает.
Forwarded from Bortlog
Great article that shows what will happen if you do not design asynchronous programming features in low-level language from scratch https://tomaka.medium.com/a-look-back-at-asynchronous-rust-d54d63934a1c

It turns out that everything is kind of works, but there are a handful of annoying nuances that you have to put up with or fix with some dirty hacks. And it is similar in most languages and most runtimes. It seems to me that the industry is trying to solve the problem of expensive OS threads and context switches, not where it needs to be solved. Why can't we make OS threads more lightweight? That would be great, and we already know how to use treads in our streams and work with queues, semaphores, and mutexes. All our tooling content understands streams, then what's the problem?

In 2013, people from Google delivered this talk https://www.youtube.com/watch?v=KXuZi9aeGTw
Where they demonstrate how to reduce the overhead of context switch 100 times or more.
If I understand correctly, in 2013, they already used this solution for services written in C ++ using "regular" threads.

In 2020, they even offered 3 patches for Linux, but didn't finish the discussion and did not merge these patches, and it may take another 5-10 years to get back to this idea.