Что: ed693888bf3e69596e743dfdce4df7dff5b93149
Когда: 2024-02-02 16:56:35+03:00
Темы: go hate python
Качество курсов и книг по программированию
https://habr.com/ru/articles/790758/
За последний месяц мне знакомые скидывали примеры вопросов и ответов на
курсах всяких (бывают открытые/пробные части). На курсе стоимостью в 40k₽
спрашивают какие права доступа будут на файле если сделать umask и сами
же совершенно некорректно высчитывают значение, хотя ведь можно просто
взять и руками выполнить umask+touch например. Показывали книгу, в
которой названы преимущества Go перед Python почти уровня "в нём
фигурные скобочки вместо отступов".
А тут вот статья на Хабре. Знаю что кто-то приемлет, но меня как бесило
использование "golang", так и продолжает, особенно когда люди причисляют
себя к Go-программистам -- при этом не знают официальное название языка
и инструмента (ведь даже сайт официальный уже не "golang.org"). Но это
мелочи, ладно.
С самого начала идёт "лучше избегать defer". Когда-то это точно было так
-- стоимость defer ощутима. Только и прежде нельзя это воспринимать как
мантру и аксиому: если функция редко вызывается, то не стоит вредить
удобочитаемости и простоте кода в угоду мизерной экономии. Но с какой-то
версии Go, defer стал крайне дешёвым и где-то я видел что официально
рекомендуют забыть про его стоимость, не париться, ибо он частенько
помогает человеку избегать ошибок и делать код проще.
Нужно правильно использовать make. Нужно изначально создавать структуру
нужного размера, чтобы не требовалось потом выделять для неё место в
runtime, задерживая тем самым остальные процессы.
"Нужно"? "Нужно" и "желательно" это две большие разницы. В комментариях
статьи сразу же отметили что из-за этого нужно можно сложнее код
написать. Плюс каким процессам make будет мешать? Может горутинам,
нитям? Причём тут runtime? make в любом случае тоже в runtime
выполняется. И я не считаю что придираюсь к словам -- по моему тут
грубейшие ошибки в использовании терминов.
Лучше использовать буферизированные каналы. Как всем известно, когда мы
пишем в небуферизированный канал, пишущая горутина блокируется до того
момента, пока другая горутина не прочитает из этого канала. Чтобы
избежать этой блокировки, можно использовать буферизированный канал на 1
элемент.
Тут меня просто бомбит. "Лучше" использовать буферизованные, говорят.
Чтобы избежать блокировок. А... а если канал именно для блокировки и
синхронизации и используется? Буферизованный и небуферизированный канал
это просто тупо две совершенно разные сущности, для разных задач. Это
как "лучше" использовать автомобиль вместо велосипеда?
for i, v := range slice
в переменную v попадает копия слайса
Копия slice в переменную? Может быть всё же значение элемента slice?
Чтобы опровергнуть миф о производительности при передачи аргумента в
функцию по значению или по ссылке, они решили просто посмотреть как
меняется производительность передавая один жалкий int. Видят что в этом
случае разницы почти нет и делают вывод это миф. Далее решили
протестировать анонимную функцию для инкремента этого же int-а. Вот
только они в цикле делают функу... но не запускают её вообще. Вот именно
здесь я бы захотел уволить человека за такое. За то как он решил
проверить и какие выводы сделал, а также просто за вообще нерабочий код.
Далее тестируют производительность switch и... map. Я прям вот реально
впервые вообще вижу что сравнивалась структура данных и код для
генерирования if-ов (грубо говоря). Вроде бы можно и вообще не
разбираться в сложности алгоритмов, но чтобы додуматься до тестирования
скорости switch и map...
То ли прежде люди (включая меня) просто не особо интересовались курсами
и книгами и всегда так плохо всё было. То ли на фоне бума тренда и hype
на ИТ сферу, на фоне развития телекоммуникаций особенно после COVID, на
фоне дефицита ИТ-кадров стали учить полнейшей безграмотнейшей дичи. Одно
дело давать мало, немного, поверхностно, а другое дело давать ошибочные,
некорректные и безграмотные вещи.
Сгенерирован: SGBlog 0.34.0