LINUX.ORG.RU

История изменений

Исправление kaldeon, (текущая версия) :

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

Дерево содержит сотни миллионов узлов? В таком случае, уступаю утверждение «машина не устанет».

Однако, это домен высоких нагрузок, поэтому:

. Go не претендовал быть неоспоримым лидером в этой области.

. Дженерики — не единственное обоснованное решение. Ещё есть кодогенерация.

Компактнее и надежнее. . . . ткну в примитивнейший пример

Цитирую пример:

i, err := strconv.Atoi("bla-bla-bla")
fmt.Printf("unchecked i=%d\n", i)
if err != nil {
	fmt.Printf("still access i=%d\n", i)
}

Я за всю практику ни разу не допустил данной ошибки и ни разу не увидел её в чужом коде.

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

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

Иногда, однако, данный код и не должен являться ошибкой. Read может вернуть неполные данные вместе с ошибкой.

Компактнее — да, я не оспариваю эту пользу. Однако, в вашем же примере используется unwrap. Приведу аналогию: тот факт, что у нас есть достоверная карта казино по всему городу, не сокращает их количество. В действительности, Rust-разработчики намного чаще используют unwrap, чем Go-разработчики игнорируют error.

рассуждения Go-шников о «красоте» должны отправляться [в /dev/null] просто по факту того, что в XXI веке они добровольно и с удовольствием использовали . . . SearchInts . . . в то время, когда у всех вокруг уже были шаблоны/дженерики.

Я ума не приложу, в соответствии с какими эстетическими стандартами можно найти существенную разницу между sort.SearchInts() и sort.Search[int](). Разница настолько маргинальна, что сама попытка раздуть её вызывает подозрения.

> А кто-нибудь кроме Go смог должным образом усвоить уроки Alef и Limbo?

Какой-то странный, мягко говоря, вопрос.

Суть вопроса изложена в следующем абзаце: «Пока опыт из прошлого не был осмыслен, он остаётся релевантным в каждом новом поколении.»

То есть исследования измеряются не в годах, а во влиянии на индустрию.

Небольшой пример. Сегодня идеологические критики GC в Go, в основном, указывают на желание ручного управления, на непредсказуемые латенси и паузы, оверхед CPU, зависимость в рантайме. Всё это правда, только никто не учитывает, что CSP без GC уже был испробован в Alef и именно это было его главной проблемой. В этом отношении индустрия (за пределами Go) не то чтобы переросла Limbo, а не доросла до Alef.

Исправление kaldeon, :

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

Дерево содержит сотни миллионов узлов? В таком случае, уступаю утверждение «машина не устанет».

Однако, это домен высоких нагрузок, поэтому:

. Go не претендовал быть неоспоримым лидером в этой области.

. Дженерики — не единственное обоснованное решение. Ещё есть кодогенерация.

Компактнее и надежнее. . . . ткну в примитивнейший пример

Цитирую пример:

i, err := strconv.Atoi("bla-bla-bla")
fmt.Printf("unchecked i=%d\n", i)
if err != nil {
	fmt.Printf("still access i=%d\n", i)
}

Я за всю практику ни разу не допустил данной ошибки и ни разу не увидел её в чужом коде.

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

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

Иногда, однако, данный код и не должен являться ошибкой. Read может вернуть неполные данные вместе с ошибкой.

Компактнее — да, я не оспариваю эту пользу. Однако, в вашем же примере используется unwrap. Приведу аналогию: тот факт, что у нас есть достоверная карта казино по всему городу, не сокращает их количество. В действительности, Rust-разработчики намного чаще используют unwrap, чем Go-разработчики игнорируют error.

рассуждения Go-шников о «красоте» должны отправляться [в /dev/null] просто по факту того, что в XXI веке они добровольно и с удовольствием использовали . . . SearchInts . . . в то время, когда у всех вокруг уже были шаблоны/дженерики.

Я ума не приложу, в соответствии с какими эстетическими стандартами можно найти существенную разницу между sort.SearchInts() и sort.Search[int](). Разница настолько маргинальна, что сама попытка раздуть её вызывает подозрения.

> А кто-нибудь кроме Go смог должным образом усвоить уроки Alef и Limbo?

Какой-то странный, мягко говоря, вопрос.

Суть вопроса изложена в следующем абзаце: «Пока опыт из прошлого не был осмыслен, он остаётся релевантным в каждом новом поколении.»

То есть исследования измеряются не в годах, а во влиянии на индустрию.

Небольшой пример. Сегодня идеологические критики GC в Go, в основном, указывают на желание ручного управления, на непредсказуемые латенси и паузы, оверхед CPU, зависимость в рантайме. Всё это правда, только никто не учитывает, что CSP без GC уже был испробован в Alef и именно это было его главной проблемой. В этом отношении индустрия (за пределами Go) не то чтобы переросла Limbo, а не доросла до Alef.

Исправление kaldeon, :

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

Дерево содержит сотни миллионов узлов? В таком случае, уступаю утверждение «машина не устанет».

Однако, это домен высоких нагрузок, поэтому:

. Go не претендовал быть неоспоримым лидером в этой области.

. Дженерики — не единственное обоснованное решение. Ещё есть кодогенерация.

Компактнее и надежнее. . . . ткну в примитивнейший пример

Цитирую пример:

i, err := strconv.Atoi("bla-bla-bla")
fmt.Printf("unchecked i=%d\n", i)
if err != nil {
	fmt.Printf("still access i=%d\n", i)
}

Я за всю практику ни разу не допустил данной ошибки и ни разу не увидел её в чужом коде.

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

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

Иногда, однако, данный код и не должен являться ошибкой. Read может вернуть неполные данные вместе с ошибкой.

Компактнее — да, я не оспариваю эту пользу. Однако, в вашем же примере используется unwrap. Приведу аналогию: тот факт, что у нас есть достоверная карта казино по всему городу, не сокращает их количество. В действительности, Rust-разработчики намного чаще используют unwrap, чем Go-разработчики игнорируют error.

рассуждения Go-шников о «красоте» должны отправляться [в /dev/null] просто по факту того, что в XXI веке они добровольно и с удовольствием использовали . . . SearchInts . . . в то время, когда у всех вокруг уже были шаблоны/дженерики.

Я ума не приложу, в соответствии с какими эстетическими стандартами можно найти существенную разницу между sort.SearchInts() и sort.Search[int](). Разница настолько маргинальна, что сама попытка раздуть её вызывает подозрения.

> А кто-нибудь кроме Go смог должным образом усвоить уроки Alef и Limbo?

Какой-то странный, мягко говоря, вопрос.

Суть вопроса изложена в следующем абзаце: «Пока опыт из прошлого не был осмыслен, он остаётся релевантным в каждом новом поколении.»

То есть исследования измеряются не в годах, а во влиянии на индустрию.

Небольшой пример. Сегодня идеологические критики GC в Go, в основном, указывают на желание ручного управления, на непредсказуемые латенси и паузы, оверхед CPU, зависимость в рантайме. Всё это правда, только никто не учитывает, что CSP без GC уже был испробован в Alef и именно это было его главной проблемой. В этом отношении индустрия не то чтобы переросла Limbo, а не доросла до Alef.

Исходная версия kaldeon, :

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

Дерево содержит сотни миллионов узлов? В таком случае, уступаю утверждение «машина не устанет».

Однако, это домен высоких нагрузок, поэтому:

. Go не претендовал быть неоспоримым лидером в этой области.

. Дженерики — не единственное обоснованное решение. Ещё есть кодогенерация.

Компактнее и надежнее. . . . ткну в примитивнейший пример

Цитирую пример:

i, err := strconv.Atoi("bla-bla-bla")
fmt.Printf("unchecked i=%d\n", i)
if err != nil {
	fmt.Printf("still access i=%d\n", i)
}

Я за всю практику ни разу не допустил данной ошибки и ни разу не увидел её в чужом коде.

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

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

Иногда, однако, данный код и не должен являться ошибкой. Read может вернуть неполные данные вместе с ошибкой.

Компактнее — да, я не оспариваю эту пользу. Однако, в вашем же примере используется unwrap. Приведу аналогию: тот факт, что у нас есть достоверная карта казино по всему городу, не сокращает их количество. В действительности, Rust-разработчики намного чаще используют unwrap, чем Go-разработчики игнорируют error.

рассуждения Go-шников о «красоте» должны отправляться [в /dev/null] просто по факту того, что в XXI веке они добровольно и с удовольствием использовали . . . SearchInts . . . в то время, когда у всех вокруг уже были шаблоны/дженерики.

Я ума не приложу, в соответствии с какими эстетическими стандартами можно найти существенную разницу между sort.SearchInts() и sort.Search[int](). Разница настолько маргинальна, что сама попытка раздуть её вызывает подозрения.

> А кто-нибудь кроме Go смог должным образом усвоить уроки Alef и Limbo?

Какой-то странный, мягко говоря, вопрос.

Суть вопроса изложена в следующем абзаце: «Пока опыт из прошлого не был осмыслен, он остаётся релевантным в каждом новом поколении.»

То есть исследования измеряются не в годах, а во влиянии на индустрию.

Небольшой пример. Сегодня критики GC в Go, в основном, указывают на желание ручного управления, на непредсказуемые латенси и паузы, оверхед CPU, зависимость в рантайме. Всё это правда, только никто не учитывает, что CSP без GC уже был испробован в Alef и именно это было его главной проблемой. В этом отношении индустрия не то чтобы переросла Limbo, а не доросла до Alef.