Как же меня задолбали собеседования. Пытался устроиться...

У меня более 10 лет реального опыта в веб программировании

Вы уверены, что именно в программировании, а не в вёрстке? Это очень разные вещи... даже если иногда тыкать в JavaScript. И неверным это может быть в обе стороны - либо Вы пишите о себе хуже чем есть на самом деле, либо Вы себя знатно переоцениваете.

я не знал (или забыл) ни одного способа заменить Math.Sqrt без использования гугла или исходников функции

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

я ни разу даже не использовал библиотечную Math.Sqrt функцию в рабочих задачах

Вы написали страшное. Какая разница? Math.Sqrt - просто заведомо понятная простая функция, вместо неё можно взять любую другую. И любой язык вместо C#. Не видеть этого...

Большое заблуждение, что все должны знать какие то элементарные вещи.

Кому должны? Выживание - опция.

Какие то - это какие? Некоторая грань точно существует.

Кто такие все? Видал я как раз верстальщиков что в программировании, и вообще в размышлениях, были чистый ноль - и ничего, прекрасно работали, высоко ценились, иногда приходили и спрашивали что и как - делов то. Исходная история как раз о том, что искали не таких.

Как же меня задолбали собеседования. Пытался устроиться...

На данный момент оценка поста -2. Эти минимум двое, у которых на дурь откуда-то хватило кармы, они точно уверены что человек нуждается именно в минусах а не в помощи?

Они делают софт для своих жильцов: приложения для взаимодействия с домофоном, сервисы дома и всё такое.

Возможно. Но откуда Вы знаете, что и Вы им нужны для того же самого? Не было у Вас данных такое предполагать. А у меня нет цензурных слов такое оценивать.

А давай ты решишь задачу на полный квадрат

Это что за задача? Гугол, например, своим ИИ полагает, что это

Гугла

Тогда я вообще не понимаю откуда возникла Math.Sqrt. Возможно, что Вы уже понанесли такую пургу, что и до неё добрались. А возможно, что это была не вполне задача на полный квадрат, а типа на решение уравнения, и тогда да, корень полезен.

Замечу, что никакой алгебры в обоих случаях не нужно, арифметики за второй класс достаточно. А без арифметики за второй класс в коллектив человека не пустят - бухгалтер не позволит, уж больно такой опасен. Платёжку с таким замучаешься обсуждать...

Вы объяснили на собеседовани, что

• не понимаете вообще что такое функция и за пределами библиотек ничего никогда не вычислите

• не способны менять точку зрения вообще никак - если заметили, что можно Math.Sqrt, значит нужно Math.Sqrt и ничего больше

• не способны работать в ситуации когда Вами придётся поруководить - если без Math.Sqrt, значит без, приказ обсуждается после выполнения

Какого чёрта я должен это знать и уметь?

А чего тут знать и уметь? Ничего сколь либо существенного, и реакция говорит, что Вы склонны впадать в панику при возникновении любой проблемы. Любой. Это раз. И заменить Math.Sqrt можно не одним, и не двумя, а сотней способов и незнание ни одного - гарантия нулевого реального опыта в программировании. Нулевого, речь то о реальном. Это два.

И тут, очень мне подозревается, Вас ждала засада - по выбору способа можно, как в точности не знаю - не психолог, судить о личности. Типа если человек хочет показать себя с лучшей стороны, то какую сторону он действительно считает лучшей? Например, задачу можно приближенно решить в целых числах, а потом показать, что нахождение поправки - та же самая задача, что даёт рекурсивную функцию... и что я такого о себе сказал этим выбором? Психолог разберётся... увы.

После этого они попытались впарить ещё одну задачу, но тут я уже просто послал их нафиг и ушёл.

Что здесь самое неверное? Не тривиально... Ага! Просто. Вы не просто послали их нафиг, Вы показали, что не способны ни почувствовать ни оценить того, что с Вами продолжают возиться, хотя менее доброжелательные строители послали бы Вас сами знаете куда сразу, строители это умеют. Особенно строители.

Искренне надеюсь помочь с извлечением положительного опыта из отрицательного результата.

Массивы и слайсы в Golang

Зачем вы меня так обижаете? :(

Не "зачем", а "почему". Так получилось, от текста названного ужасным оказалось просто перейти к ужасу на go.dev/doc.

Это моя первая статья и писал я её я, а не нейронка.

А что бы с Вами сделали если бы Вы её публиковали позже? И вообще, первый раз за рулём - не повод посещать центр Москвы... А вот отказ от возможности спрятаться за нейронку - это достойно.

Я сидел и искал материалы разных менторов(что бы выбрать задачи и их объяснить).

Это ужасно. Я подозревал, что с менторами не просто, но что до такой степени... Так мы и до мышей инструкции по открытию капота джипа на 15 страницах в картинках, реально было в Интернете и армии США, докатимся.

Я помню, что когда читал текст по Go, детали массивов и слайсов заинтересовали. Теперь или этот текст исчез, или это эффект Манделы. Но заметки по поводу сохранились. Вроде всё конкретно, понятно и никаких объяснений на словах не нужно.

Вот

package main
import (
	"fmt"
	"unsafe"
)

func main() {
	a1 := [...]int{1, 2, 3, 4, 5, 6, 7}
	fmt.Printf(" 1. %T %[2]p %[1]v\n", a1, &a1)
	a2 := [...]int{11, 12, 13, 14, 15, 16, 17}
	fmt.Printf(" 2. %T %[2]p %[1]v\n", a2, &a2)
	a2 = a1
	a2[3] = 100
	fmt.Printf(" 3. %T %[2]p %[1]v\n", a1, &a1)
	fmt.Printf(" 4. %T %[2]p %[1]v\n", a2, &a2)
	useArray(a1)
	fmt.Printf(" 5. %T %[2]p %[1]v\n", a1, &a1)
	useArrayP(&a1)
	fmt.Printf(" 6. %T %[2]p %[1]v\n", a1, &a1)

	s1 := []int{11, 12, 13, 14, 15}
	fmt.Printf(" 7. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s1, len(s1), cap(s1), &s1, &s1[0])
	s1 = append(s1, 55)
	fmt.Printf(" 8. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s1, len(s1), cap(s1), &s1, &s1[0])
	s1 = append(s1, 56, 57)
	fmt.Printf(" 9. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s1, len(s1), cap(s1), &s1, &s1[0])
	s2 := s1[2:5]
	fmt.Printf("10. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s2, len(s2), cap(s2), &s2, &s2[0])
	s2 = append(s2, 31, 32,33)
	fmt.Printf("11. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s2, len(s2), cap(s2), &s2, &s2[0])
	fmt.Printf("12. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s1, len(s1), cap(s1), &s1, &s1[0])
	useSlice(s2)
	fmt.Printf("13. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s2, len(s2), cap(s2), &s2, &s2[0])
	fmt.Printf("14. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s1, len(s1), cap(s1), &s1, &s1[0])
	s2 = s2[:5]
	fmt.Printf("15. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s2, len(s2), cap(s2), &s2, &s2[0])
	useSliceP(&s2, 40)
	fmt.Printf("16. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s2, len(s2), cap(s2), &s2, &s2[0])
	fmt.Printf("17. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s1, len(s1), cap(s1), &s1, &s1[0])
	useSliceP(&s2, 41)
	fmt.Printf("18. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s2, len(s2), cap(s2), &s2, &s2[0])
	fmt.Printf("19. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		s1, len(s1), cap(s1), &s1, &s1[0])
}

func useArray(a [7]int) {
	a[2] = 101
	fmt.Printf("a1. %T %[2]p %[1]v\n", a, &a)
}

func useArrayP(a *[7]int) {
	a[4] = 102
	fmt.Printf("b1. %T %[2]p %[1]v %[1]p\n", a, &a)
	p := (*int)(unsafe.Pointer(a))
	*p = 201
}

func useSlice(a []int) {
	fmt.Printf("c1. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		a, len(a), cap(a), &a, &a[0])
	a[4] = 80	
	a = append(a, 81, 82)
	fmt.Printf("c2. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		a, len(a), cap(a), &a, &a[0])
}

func useSliceP(a *[]int, w int) {
	fmt.Printf("d1. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		a, len(*a), cap(*a), &a, &((*a)[0]))
	(*a)[3] = w	
	*a = append(*a, 91, 92)
	fmt.Printf("d2. %T %[4]p %[5]p %[2]d %[3]d %[1]v\n", 
		a, len(*a), cap(*a), &a, &((*a)[0]))
}

Основной посыл статьи во первых самому убедиться в своих знаниях, а во вторых дать возможность порешать задачки на понимание темы.

Убеждаться в своих знаниях лучше пет проектом, не пытаясь проделать это за счёт окружающих, а вот "порешать задачки" меня встревожило. Это не задачки, это вопросики. Задачей может быть разработка алгоритма. Может быть задача по физике - физика есть некоторая теория над Природой. А язык Go и сам природой не является и никакой теории над ним нет - это набор решений его авторов. Точно так же не может существовать задач по Звёздному Пути, например. Вопросы могут быть, задачи - нет.

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

Документация есть и официальная, согласен.

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

Массивы и слайсы в Golang

Уж было хотел назвать автора последними и предпоследними словами, а статье его и нейронке её писавшей объявить "изыди" и, заодно, ткнуть мордой в документацию, но увы... В принципе, ткнуть можно, на go.dev/doc есть ссылка Go Slices: usage and internals, спрятана она в секции Language блока Codewalks и покрывает эту статью сто раз как бык овцу. Беда в том, что мне просто повезло. И беда в том, что это ссылка на блог. Вдумайтесь - документацией по Go является сборище блогов, то есть одна баба сказала. Это что такое вообще, если не выбор между саботажем и катастрофой?

На go.dev/doc есть ссылка на спецификацию языка, но она достаточно формальна чтобы быть неудобной для чтения и непригодной для обучения. Ау, люди - я один (смутно) помню, что описание языка совсем недавно было на сайте и были сэндвичи меню с общим и локальным содержаниями? Я помню, что познакомившись с Go отнёс его к хорошо документированным языкам, типа Rust или Dart, для чего абсолютно необходим связный текст, который можно было (рекомендовать) прочитать от начала и до конца и узнать о Go, как о языке, всё. Значит он там был? Not any more, или я чего-то не вижу в упор?

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

Исследование показало, что регулярное чтение книг добавляет...

Приятно слышать. Тогда и аниме должно продлевать жизнь. Если эпизод не заканчивается сразу как только начался, а 24 минуты делись незнамо куда - я просто не смотрю...

Capacitor: от веба к мобильным приложениям. Часть 0. Зачем нужен Capacitor

Когда Capacitor — плохая идея

• игры и тяжелая графика;

• сложные анимации;

Про Capacitor я толком знаю только то, что на нём писан мобильный Obsidian. И тут я не понял - почему не игры, графика и анимации, что по сути одно и то же, когда для этого есть как минимум Three.js с её Rogue Engine, Babylon.js и D3.js. Наоборот, хорошо должно быть, а у Flutter пока только 2D и Impeller новорожденный.

Архитектурно:

• приложение работает в WebView;

Приложение из WebView запросы как из браузера шлёт или более эффективные способы взаимодействия придуманы, как в Tauri? Две большие разницы, без прояснения архитектура не понятна.

Пишите любые интересующие вас вопросы в комментарии и в личку.

Сам напросился...

Представлен дистрибутив Omarchy с идеальным Linux-окружением

По мнению Ханссона, для высокой производительности труда важна мотивация, а частью такой мотивации является красивое и эстетичное окружение.

Это очень похоже на правду. Поэтому периодически приходит желание выделить выходные на неторопливую переустановку Arch, красота и эстетика со временем меняются. Пока желанию не поддавался, как на EndeavourOS (от Arch отличия минимальны) сел...

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

И Генри Форд считал так же, и Стив Джобс тоже. Ещё одним Капитаном Очевидность больше.

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

А вот это сомнительно. Компетентности может быть много, но она не обязательно будет в том, что нужно конкретному представителю "большинства пользователей". Ничего не менять и ничего не настраивать - тоже вариант требующий компетентности.

Наблюдаемый факт - "в начале своего пути" все проходят через distro hopping и я не вижу альтернативы - посмотреть варианты и пределы возможностей нужно обязательно. На этом этапе Omarchy кажется более чем уместным - Ruby on Rails выжала из Ruby всё что можно, наверно и Omarchy выжимает из Arch всю конфигурируемость без остатка.

По поводу собственно выборов сделанных Omarchy отмечу некоторую противоречивость - акцент на терминале обесценивает всю остальную кастомизацию, её просто не видно так же, как обычно, когда рабочее окружение не строится вокруг рабочего стола, не видно обоев этого стола.

Сколько нужно парадигм, чтобы вкрутить лампочку?

Давайте я сразу на личности перейду

Конечно переходите, если для Вас это важно.

Ох, ну и списочек.

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

Понимаете, эрудиция пока еще никому не вредила.

Наверно нет, хотя Холмс и поспорил бы. А при учёте того факта, что на её обретение уходят время и силы... Кстати, я не пишу что эрудиция вредна, я пишу что есть способ попроще для достижения того же эффекта.

А знать Dart… Невеликое достижение, прям скажем.

Я не требую чтобы Dart всем казался дико недооценённым, что есть, увы, физически невозможное состояние. Поэтому так, скажите, а какой тип имеет функция

f(v) {
     try {
             if (v < 0) return 11;
     } catch (_) {};
     try {
             if (v == "assa") return "sento";
     } catch (_) {};

  return 3.67;
}

Если (правильно) скажете - разве Dart не заслуживает изучения хотя бы из-за тшательности и продуманности, а то и мудрости, с которой он сделан? А если нет - тогда не такое и малое достижение...

Сколько нужно парадигм, чтобы вкрутить лампочку?

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

Ценность пишущего на "Java/.NET + Ruby/Python + JS/TS + Haskell/Idris + LISP" тем выше, чем больше накоплено дурно написанного разномастного кода. Но только при условии, что явно или неявно принято решение (пока) оставить всё как есть, ибо в ином случае стек унифицируют и от лишних языков избавляются. Стремиться в эту среду... добровольно...

В тех редких случаях, когда использование разных стеков и языков действительно необходимо или оправдано, нужно не уметь "написать внятный код", а быть на пяток ступеней выше. И крайне вероятно, что у подходящих людей ровно 1 (один) активный язык, в том числе потому, что это они решают чем будет заниматься менеджмент, а не наоборот.

Человек с одним активным языком может сделать практически всё. Объём этого "практически" тяготеет уменьшаться при росте требований к качеству, однако. По моему впечатлению, часть языков сразу отсеиваются при требовании относительно качественной разработки для браузера (когда код выполняет содержательную работу в браузере, это только часть "фронтенда") и 3D игр, после чего идёт долгое плато на котором все они равноценны.

Кроссплатформа и организация работы под полиглотов, наоборот, понижают требования к качеству и расширяют "практически всё" для людей с одним активным языком. Если угодно, эти три сущности образуют баланс по Переслегину.

И тут происходят события, представляющиеся мне знаковыми. Например, Dart, якобы специализированный язык для Flutter. И на него только что портировали с Go библиотеки Bubbletea (Charmbracelet) в виде пакета Artisanal... так что у (действительно) выучившего Dart на одну причину учить Go меньше.

Что значит «своему языку»?

Ну, типа совет выбрать язык который будете действительно знать. Если такой уже есть, то давать какие-то советы уже не нужно...

А если такого нет, то я неявно рекомендовал что-то типа Dart, Go, Python или Rust потому, что у них есть связная и полная официальная документация которую искать не нужно и можно просто последовательно прочитать. В отличии от С++ или JavaScript, где документация тоже есть, но...

Сколько нужно парадигм, чтобы вкрутить лампочку?

Если разработчик претендует на лычку мидл+, но не чувствует себя свободно хотя бы в основных пяти парадигмах, — это напыщенный дурак, гоните его в шею.

Есть ли ситуации, где этот совет полезен? Очевидно да, даже не вспоминая про сломанные часы. А вот на сколько это верно - совсем другой вопрос. Ну чувствует человек себя свободно в основных пяти парадигмах (кстати, спиок не приведён) - и что? А ведь ничего...

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

Претензия формулировалась так:

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

Тогда решение не в знании парадигм, а в умении не пользоваться неподходящей парадигмой. А тем, чего не знаешь, и не воспользуешься (just saying). В просторечии - и последние станут первыми, типа.

А как можно получить свободу в пяти парадигмах? Проще всего - заниматься разными задачами. Чтобы быстрее позаниматься разными задачами, удобно побыстрее потерпеть неудачу в каждой. По этой причине в своё время потерпела крах серебрянная пуля "бригада ведущего программиста", примерно современницв бума ООП, предъявлявшая к ведущему программисту требования идентичные знанию пяти парадигм.

Следующий тезис я пересказываю в собственном переводе по памяти о речениях наших западных партнёров.

Если есть три способа, значит ни одного хорошего нет.

Повеселившись, перейдём к инструментам. Автор сам пишет

Но попытка написать на Prolog веб-сервер будет выглядеть как попытка заколотить крота микроскопом.

но, к счастью,

На самом деле, в современном мире все взрослые языки давно стали мультипарадигменными.

Что приводит к мысли, что владние парадигмами эквивалентно полному владению языком программирования, ключевое слово - полному. В мире, где существуют курсы по основам, антониму полноты, Python - пропаганда и того и другого бессмысленна.

Если кто вместо броска к парадигмам потратит часть остатка праздников на то, чтобы просто перечитать доки по своему языку программирования от начала и до конца сосредоточившись на "почему" и "зачем", комментировать стоило. Если язык программирования Go, Dart или Rust - и перечитать проще не бывает, и вообще, Вы уже на правильном пути.

Вышел Linux-дистрибутив Nitrux 5.1.0

Действительно, почему?

Why some Linux users do not like systemd?

Спросил у Гугла и ИИ его сказал

Key reasons for the opposition include:

• Violation of the UNIX Philosophy: The traditional UNIX approach favors small, simple tools that "do one thing and do it well" and can be easily chained together. Critics argue that systemd is a large, monolithic, and complex suite of around 70 interconnected binaries that takes on too many responsibilities, from network management (networkd) to logging (journald) and login management (logind), which previously were handled by separate, replaceable utilities.

• Complexity and Learning Curve: The shift to systemd requires system administrators and power users to learn a completely new set of tools, commands (like journalctl and systemctl), and configuration files (declarative units). This deprecates decades of accumulated knowledge and scripts based on older systems like SysVinit or Upstart.

• Binary Logging Format: systemd uses a binary format for its logs (the journal) instead of plain text files. This is a major point of contention because traditional text-processing tools like grep, awk, and sed cannot be used directly. Users must rely on the specialized journalctl utility to read logs, which some view as a move away from the transparent, file-based nature of UNIX systems.

• Invasive and All-or-Nothing Approach: Due to its deep integration into the system and its dependencies, replacing individual systemd components with alternative software is difficult, and many desktop environments and projects have come to depend on it. This reduces user choice and flexibility, creating an "all-in-one bundle" that is hard to customize.

• Compatibility and Standardization Concerns: systemd is Linux-specific, rather than POSIX compliant, which makes it harder to port software between Linux and other Unix-like systems (like BSDs).

• Developer Dislike and Community Dynamics: A significant, though less technical, aspect of the controversy includes personal dislike for the key developers of systemd, with some critics citing a lack of openness to community feedback and an "inflexible by design" attitude. 

И это дивно совпало с моими личными ощущениями - systemd работает хорошо и удобно, но является злом которое вредит мне так тонко и замаскировано, что я этого не замечаю. В точности то же самое относится и к wayland. Со злом я, впрочем, не борюсь если можно примкнуть к нему, в данном случае - EndeavourOS называется.

Настройка Tor + Privoxy: HTTP и SOCKS5 proxy для домашней сети через Tor

Автор, 🧍‍♀️🐩, убери статью и про приватность пиши только одно - ой, мама, совсем нету, ничего не работает. На крайняк - как с этим обстоит дело в скрепной ОС Роса.

Python: Почему [] в аргументах функции — это ловушка?

Есть гипотеза почему - Пайтон делался давно, следовательно, для программистов совсем другого уровня. Видно же - он катастрофически медленный не случайно, скоростью пожертвовали ради чего-то ещё. Чего именно - не скажу, но вижу - что бы оно ни было, сейчас уже не упёрлось - до аннотаций типа дожили. На варворов найденное в Риме не по назначению пользующих похоже, потому и открытия. Одно успокаивает - такое непотребство продолжалось только пока вода по акведукам текла...

Иногда возникает вопрос - как долго данные могут...

Do sd cards refresh data when connected to power?

Спросил я у Гугла и АИ его сказал - чаще нет чем да, зависит от того, куда карта вставлена, и от профессиональности карты, но полное чтение есть один из способов обновления заряда в ячейках. Вроде сиё объясняет почему на дешёвой карте исчез провал скорости и кому под хвост пошёл эксперимент.

Go после Rust: краб и суслик

Увы, я не профессор и таланта к обучению не имею.

Go после Rust: краб и суслик

Первый недостаток Go -- это отсутствие перечислений (enum).

Поэтому объявляют специализированный тип и набор констант через iota и не парятся. Или используют кодогенератор и не парятся. Или используют пакет enum и его дженерики и снова не парятся.

Важная особенность состоит в том, что компилятор принуждает программиста либо обработать все возможные варианты, либо создать ветку, которая будет обрабатывать все варианты, не подпавшие под какой-либо шаблон:

А если ни то ни другое не нужно? Это, кстати, философски значимо - компилятор для программиста или программист для компилятора? Или даже так - что первично, процесс работы или её результат? Можно сказать, что Go помогает программисту автоматически создавая ветку по умолчанию которая не делает ничего.

А ситуацию когда есть набор вариантов из которых нужно выбрать ровно один на Go можно оформить массой способов - в Go функции are first class citizens.

Почему эта задача плохо решается с помощью Go. В Go для этой задачи придётся использовать обычный int

Не "придётся использовать", а "я не могу придумать ничего кроме".

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

Согласен, то, что об этом можно не думать - большое достижение авторов языка.

Можно было бы сказать, что это просто особенность Go -- что там более высокоуровневая модель памяти. Но так как он позиционируется как язык, на котором можно писать высоконагруженные системы, то это я считаю минусом

Некоторе системы требуют писать без выделения и освобождения памяти, но это к слову. Сама же идея интересная - кем позиционируется? Где? Когда? Зачем? Я вижу что про языки программирования несут чушь на уровне торгашей базарных и пропагандистов продажных, но не понимаю кто заказывает эту музыку.

Писать высоконагруженные (то есть с фиксированным временем реакции, что-ли?) системы на Go точно можно, но что для Go, что для Rust точно найдутся такие, что их проще писать на другом языке. Elixir не даст соврать... И чё?

Много неудобств доставляет ограничение, запрещающее генерики в методах структур.

Это долгая история. Просто выясните когда в Go появились дженерики и почему не появлялись раньше. И осторожнее - Rust вообще весь состоит из неудобств, и ничего.

Таким образом, Go подталкивает нас к использованию интерфейсов

Ну вот... понимают если захотят.

Из-за того, что кортежи -- это не настоящий тип, мы не можем их использовать в генериках:

Не "не можем", а "не должны". Извращаться можно где угодно, но зачем? Кортеж - собранные вместе несколько значений. Ничего не напоминает? А их возвращение из функции - синтаксический сахар, полезность которого доказана обработкой ошибок. Как и := оператора...

Сделаю небольшую ремарку про злоупотребление интерфейсом any -- плохая практика, которая встречается не так уж редко.

Да, у Go есть история.

Это полный трэш и по сути игнорирование строгой типизации языка.

Философия языка для программиста или наоборот? Это хорошо понимали профессионалы которые делали Go, и весьма недооценённый Dart из той же конюшни, кстати. Поэтому any никогда не была трешем... разве что ловушкой для любителей.

В подходе, который в Go выбран для обработки ошибок, мне нравятся две вещи: передача ошибок через возвращаемое значение функций (по сравнению с исключениями в C++, Java) и возврат ошибки как отдельного значения (по сравнению с использованием "особых значений" как в C).

Ну не надо такое писать, дурно пахнет. Да, все так пишут, запах только усиливается. В Go перехватывается panic...

Первая проблема с таким подходом в том, что по сигнатуре функции нельзя понять, какие ошибки внутри неё могут возникнуть.

Это уже зашкаливает. Используйте другой тип и всё. Если Rust создаёт выученную беспомощность заставляющую использовать только то, что есть в стандартной библиотеке, без изменения, пусть и не всех (на меня вот не подействовало), то это проблема Rust.

И это приводит к проблемам -- так как ошибки в Go обычно имеют тип error, то каждая новая ошибка будет присваивать значение всё в ту же переменную:

То же самое опять. "Обычно" не значит "всегда".

И у вас появляется переменная, существующая на протяжении всей функции, которую можно случайно использовать.

Давно решено. См. := оператор.

Сложно не упомянуть о синтаксическом сахаре в виде ?.

Спасибо что упомянули. Это как раз то, что было сознательно отвергеуто в Go. Упрощает и без того тривиальное ценой усложнения и так нетривиального.

Вариант, возможно, и более явный, но, мне кажется, возможность ошибки хуже неявности.

Отличное наблюдение. Действительно, в Go возможность ошибки - последний приоритет. Пытаюсь догадаться почему так - потому, что у каждой ошибки есть причина, и проще и лучше устранять причины, чем бороться со следствиями, особенно бороться запретами (вне программирования эту мысль прошу не думать). Но что думали авторы Go - не знаю.

Непонятно, что мешало за столько лет существования языка добавить банальное:

Да, в Go есть история и изначально в конструкциях языка была некоторая магия. Что лучше, append или .Push - не очевидно, это разные вещи потому, что append добавляет элемент не в массив, а в slice.

Видите баг? Мы создали массив, в котором уже есть 10 элементов.

Не вижу. Создали массив из 10 элементов. Молодцы. Не хватает фантазии сообразить когда это нужно?

Непонятно, что мешало сделать для массива пустого и массива заполненного два отдельных конструктора.

Я бы первым делом заподозрил array literal.

Начнём с того, что посылающая и принимающая сторона выражена одним и тем же типом:

Не понимаю. У канала нет принимающей и посылающей стороны, есть чтение из канала и запись в канал. И, как мне кажется и, конечно, не более того, именно каналы сделали все навороты Rust о которых любят петь как о fearless concurrency просто ненужными.

В Go присутствует такая эзотерическая конструкция, как теги на полях структур.

Да, и судя по предложениям по поводу в статье по соседству, её авторы переоценили уровень своих пользователей. Это весьма печально, особенно если задуматься о том, что рост популярности автоматом снижает тот самый уровень.

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

Нет, не хрупкий. Эта команда применяется для запуска генератора и больше ни для чего. Результат работы генератора проверяется наравне с остальным кодом. На макросы в Rust даже не похоже.

А мы не можем, потому что родительский модуль использует дочерний, поэтому дочерний модуль не может импортировать namespace ошибок из родительского.

И не должны мочь. По определению родительский модуль использует дочерний.

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

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

Существуют //go:build тэги, возможность явно перечислить файлы в коммандах run и build, ссылки в файловой системе, файл go.work. Вместе вот это всё позволяет раскладывать файлы по папкам крайне кучерявым образом, но я не могу придумать когда такое действительно нужно. Может быть для генераторов кода? Может быть тогда эта избыточность понадобится. А может просто избыточность введена для того, чтобы было проще обмениваться файлами по почте? Не знаю...

Про Go любят говорить, что его философия -- это простота (а также любят говорить, что каждая новая концепция, добавляемая в язык, лишает его простоты). Но в чём смысл этой простоты, если она делает инструмент негибким, неудобным для применения?

Ещё раз, мало ли что и из каких соображений врут говорят. Возьмём два slice (среза?) от одного массива и начнём их изменять - ничего от простоты Go не останется. Напишем горутины и сравним работу кода на десктопе и в Web Assembly - результат тот же. И далее везде.

Я бы мог согласиться с тем, что Go прост, если бы из контекста следовало, что он идеологически прост. Это не означает ни низкого порога входа, ни удобства для не понимающих сути языка, что Вы и описали. Как пример - Scheme и того идеологически проще... И ещё более охотно я бы согласился с тем, что Go идеологически прост и практичен.

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

Негибкости и неудобства я пока в Go не почуствовал. Наоборот, с Go приятней работать чем с чем-либо ещё. Следующий за Go вариант - сладкая парочка JavaScript + Dart. Rust мне тоже нравится, наличие архитектурных ошибок странностей не особо мешает, но пользовать его можно только если время ожидания окончания компиляции хорошо оплачивается.

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

Теги структур — худшее что есть в go

Чем мне нравится Go, так это взрослым подходом свойственным профессионалам. Это не Rust какой-нибудь, где авторы выглядят как способные, может быть даже талантливые, дети. Как пример - дженерики. 12 лет их не было потому, что было не понятно как их сделать нормально. Такой же подход был, отчасти и есть, у Эппл. Например, если нет достойного iOS калькулятора - значит в iOS калькулятора не будет.

О тегах начну с предполагаемых причин. Кому-то было неудобно парсить JSON и он придумал теги - из шкурных интересов решил нагадить всем. Как называется такая личность? Правильно, сволочь она называется.

Почему нагадить? Потому, что это значит городить второй язык поверх Go. Вот с этим делом и проблемы, дотпространств имён докатились. Это безумие, как бы кому ни казалось что лично ему профит выйдет.

Почему сейчас не ужас? А упомянутый выше профессионализм (пока) спас, думается мне. Тэги как они есть - не мешают никому, ну есть и есть. Более того, чтобы узнать, есть ли от них польза, другого способа чем попробывать - нету. Попробывали, есть польза, вот JSON парсить приспособили - теперь лучше понимаем как его парсить, положительный результат достигнут.

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

И ещё раз, для верности. Стандартизация и прочая дурь вокруг тегов а) смешивает концепты и б) мешает другим способом использовать тэги чтобы разобраться ещё с чем нибудь ограничивая свободу их использования.

Пример аналогичного этим предложениям, как по мне весьма, безумия из Rust - времена жизни в определении процедуры. Процедура не может интересоваться временами жизни что параметров, что возвращаемого значения - это автономная сущность. Если нужно обязательно делать ещё одну проверку не дождавшись пока компилятор поумнеет достаточно для того, чтобы её можно было реализовать нормально - пишите свои времена жизни там, где они не выглядят творением школьного кружка, при вызове функции, например. Или при объявлении переменной...

Премного я опечалился сию статью прочитав. Линуса на вас нет...

Законы о маркировке звонков: угроза для IT-отрасли в России

Мне как-то кажется, что случай не новый. Ибо вроде как общеизвестно, что

Осёл, поработавший в тени, больше никогда не будет работать на солнце.

Здесь, возможно, то же самое. Поняв, что бизнес идея тупо звонить кому ни попадя - не рабочая, нужно стенать, стонать и жаловаться, но не придумывать рабочую идею. Есть гипотеза почему так, вариант предыдущей:

Ослы, вкусившие административного ресурса, ...

Книга «Основы Dart: Community edition» 2-е издание

Я (чуть) заглянул в Вашу книгу. В надежде что если я таки это прочту, то неконец то буду понимать что как бывать по русски, а то все источники почему-то англоязычные попадаются.

Регулярно актуализировать - это подвиг, не отнимешь.

Лицензия не только читаема, что уже поразительно, но и приемлема. Есть мелкие, однако, вопросики. Вот "любому использованию" уделена масса внимания, а "любое не использование" почему-то обойдено стороной.

воспроизведение Произведения (полностью или частично) на бумаге путем распечатки с помощью принтера в одном экземпляре

А не на бумаге? А без принтера? А разве два экземпляра частичного воспроизведения не могут оказаться тождественны одному экземпляру? История с Хираньякашипу подталкивает к более общему стилю написания лицензий...

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

Это невыполнимое условие ибо запрещает, в частности, писать

void main() {

Формат epub выглядит серой нечитаемой простынью по сравнениию с pdf, который тоже не блещет изысками форматирования. Надо бы по тексту предупредить - epub, по возможности, не качайте.

Сразу, после заглядывания в случайное место, в глаза бросилось

// base_url/part_2/2.2/ex_1.dart
void main() {
// Dart 2
final myList = [1, 2];
var a = myList[0];
var b = myList[1];
print('a: $a, b: $b'); // a: 1, b: 2

// Dart 3
var [a1, b1] = myList; // или final [a1, b1] = myList;
print('a1: $a1, b1: $b1'); // a1: 1, b2: 2
}

разве немного иначе не было бы понятнее:

// base_url/part_2/2.2/ex_1.dart
void main() {
final myList = [1, 2];

// Dart 2
var a = myList[0];
var b = myList[1];

// Dart 3
var [a1, b1] = myList; // или final [a1, b1] = myList;

// with the same result
print('a1: $a1, b1: $b1'); // a1: 1, b2: 2
}

Сама идея бесплатной книги по Dart кажется мне великолепной, особенно когда основная цель - продвижение Flutter, что самого по себе, что курсов или ещё чего по нему. Стандартный подход - вот великий Flutter но и про неизбывный Dart тоже поговорим, - не работает потому, что как раз Dart и есть главное психологическое препятствие на пути к Flutter.

Моя предварительная оценка - 129 из 137.

В ядре Linux обнаружена первая уязвимость, связанная с кодом Rust

Нету в Rust никакой безопасности, а раз так, нету и никакого её обмена на эффективность - Rust быстр на уровне С. Есть, как и везде, ложь, полуправда, политика и шкурные интересы.

В Rust реализованы, если угодно - доведены до абсурда, некие интересные сами по себе идеи, для удобства назовём их парадигмой, заставившие меня понять - парадигмы могут быть разные (Scheme пытался но не смог) и чем очевиднее, что где-то никакой парадигмы то и нету, тем разрушительнее её неизбежное наличие. Как пример - borrow checker продают как безопасность, которая, в зависимости от точки зрения, либо отсутствует либо преждевременна и, следовательно, не нужна в лучшем случае, но не продают как способ облегчить чтение и понимание программы, хотя про отсутствие второй модифицирующей ссылки можно повторить всё когда-то сказанное про отсутствие go to.

У Rust хороший тулинг, я бы сказал - отличный кабы у Go тулинг не был бы на том же уровне, хорошая интеграция с С, разве что у Zig и того лучше, и отличная, в смысле непревзойдённая, документация на сайте. Я не знаю, достаточно ли этого чтобы объяснить движуху вокруг Rust, но поветрие "перепишем на Rust" породило много интересного, а набор крейтов Rust, уступая числом но, вроде как, возрастая быстрее, превосходит набор пакетов Go разнообразием, то есть Rust выглядит поуниверсальнее.

Как Rust ложится на (безумную) схему "джун - сеньор - тестер" я не знаю, но знаю - это важно. Но и без этого движ вокруг Раста не удивителен, а в истории смысл точно есть.

Забыл, придётся отредактировать пост. У Rust отвратительно медленный компилятор, но его как раз сейчас переделывают.