Ещё один миф из JavaScript: нестрогое равенство

13 ч. назад

Очередной миф на сайте "Современный учебник JavaScript":
https://learn.javascript.ru/comparison

Цитата:

При сравнении значений разных типов JavaScript приводит каждое из них к числу.

Откуда дровишки? Правда о JavaScript написана только в одном месте - в документации языка. Поэтому смотрим доку:
https://262.ecma-international.org/16.0/index.html

EqualityExpression : EqualityExpression == RelationalExpression
 1. Let lRef be ? Evaluation of EqualityExpression.
 2. Let lVal be ? GetValue(lRef).
 3. Let rRef be ? Evaluation of RelationalExpression.
 4. Let rVal be ? GetValue(rRef).
 5. Return ? IsLooselyEqual(rVal, lVal).

Ага, значит, ищем IsLooselyEqual:

The abstract operation IsLooselyEqual takes arguments x (an ECMAScript language value) and y (an ECMAScript language value) and returns either a normal completion containing a Boolean or a throw completion. It provides the semantics for the == operator. It performs the following steps when called:

1. If SameType(x, y) is true, then
   a. Return IsStrictlyEqual(x, y).
2. If x is null and y is undefined, return true.
3. If x is undefined and y is null, return true.
4. NOTE: This step is replaced in section B.3.6.2.
5. If x is a Number and y is a String, return ! IsLooselyEqual(x, ! ToNumber(y)).
6. If x is a String and y is a Number, return ! IsLooselyEqual(! ToNumber(x), y).
7. If x is a BigInt and y is a String, then
   a. Let n be StringToBigInt(y).
   b. If n is undefined, return false.
   c. Return ! IsLooselyEqual(x, n).
8. If x is a String and y is a BigInt, return ! IsLooselyEqual(y, x).
9. If x is a Boolean, return ! IsLooselyEqual(! ToNumber(x), y).
10. If y is a Boolean, return ! IsLooselyEqual(x, ! ToNumber(y)).
11. If x is either a String, a Number, a BigInt, or a Symbol and y is an Object, return ! IsLooselyEqual(x, ? ToPrimitive(y)).
12. If x is an Object and y is either a String, a Number, a BigInt, or a Symbol, return ! IsLooselyEqual(? ToPrimitive(x), y).
13. If x is a BigInt and y is a Number, or if x is a Number and y is a BigInt, then
   a. If x is not finite or y is not finite, return false.
   b. If ℝ(x) = ℝ(y), return true; otherwise return false.
14. Return false.

Вот и весь ответ. В JS есть чёткий алгоритм нестрогого сравнения, который назван IsLooselyEqual, а всё остальное - отсебятина.

null == undefined; // вернёт true

В Javascript при нестрогом сравнении null равен undefined не потому, что они оба привелись к 0, а потому что в пункте 2 чётко сказано, если первый оператор null и второй оператор undefined, то нужно вернуть true.

JavaScript

программирование

Комментариев пока нет

Хитрость spread-синтаксиса в JS

dima

недавно

А вы знали, что теоретически spread-синтаксис в JS можно применять почти к любому типу.
Вот пример "обычного" использования:

// Массив спредится
console.log([...[1, 2, 3]]); // [1, 2, 3]
// Строка спредится
console.log([...'Famabara']); // ['F', 'a', 'm', 'a', 'b', 'a', 'r', 'a']

Но если попытаться заспредить number, то будет ошибка:

console.log([...555]); // Uncaught TypeError: 555 is not iterable

Не является iterable.
Так давайте сделаем iterable!

Number.prototype[Symbol.iterator] = function * () {
  yield 'Фамабара';
  yield 'лучше';
  yield 'всех';
}

console.log([...555]); // ['Фамабара', 'лучше', 'всех']

Мы успешно заспредили number! Толку от этого никакого, на сам факт забавен.
Можно джунов за собесах мучить :)

JavaScript

программирование

языки программирования

147

TypeScript скоро станет в 10 раз быстрее

volchara

недавно

Андерс Хейлсберг (автор Тайпскрипта) опубликовал пост в блоге:
https://devblogs.microsoft.com/typescript/typescript-native-port/

В общем, TypeScript скоро станет в 10 раз быстрее, вернее, он уже стал таким, просто пока эту версию не сделали общедоступной.

Вот такой прирост скорости компиляции крупных проектов теперь показывает tsc:

Как видно, прирост на порядок - т.е. примерно в 10 раз. Достигается это за счет использования Golang для работы tsc, а не JS. Сам по себе JS быстрый, но он упирается в один поток. А кто писал на Go, то знает, насколько легко там запустить горутину. Теперь tsc будет использовать несколько имеющих потоков, что и даст прирост скорости компиляции.

Обратите внимание, это полноценная работа tsc, а не как у esbuild, где только транспиляция без проверки типов.

На момент написания этого поста текущая версия TypeScript - 5.8.2. Следующая мажорная версия - 6-я - будет всё ещё на JS-е, а вот 7-я версия будет уже на "нативном" коде, т.е. компилироваться из Go. Автор их так и называет:

For the sake of clarity, we’ll refer to them simply as TypeScript 6 (JS) and TypeScript 7 (native)

В общем, новость хорошая. Быстрее будет не только компиляция в JS, то и VSCode будет работать быстрее, потому что там все подсказки в редакторе, даже если это JS-код, реализованы с помощью тайпскрипта.

Показать полностью...

138

Идёт разработка Vue Vapor

connected2u

1 г. назад

Между прочим в мире VueJS большая новость - активно разрабатывается Vue Vapor. По основной идее этого проекта во VueJS исчезнет виртуальный DOM, который являлся важной частью всего VueJS. Теперь работа будет вестись напрямую с DOM и меняться будут только нужные HTML элементы, если срабатывает реактивность.

А еще интересная деталь: пишут, что будет работать только с Composition API, а Options API уйдёт на свалку истории. А ведь говорили, что этого не будет и старый Options API будет поддерживаться до последнего. Плюс обязателен script setup.

Vue.js

программирование

JavaScript

176

Неочевидно опасное undefined behaviour в языке Си

volchara

недавно

Чтобы мозг не раскисал, учу Си. Язык простой и одновременно довольно сложный. А ещё в нём есть куча undefined behaviour - неопределённое поведение компилятора для пограничных случаев, которых на самом деле масса.

Вот пример простейшей функции:

int get_zero(void) {
  int num;
  return num & 0;
}

Переменная num не инициализирована, значит там могут сидеть любые "мусорные" биты.
& - это оператор побитового И, который сравнивает последовательно биты двух чисел и ставит в соответствующий бит возвращаемого числа 1, только если оба бита - это 1, иначе поставит туда 0.

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

123 // 00000000 00000000 00000000 01111011
0   // 00000000 00000000 00000000 00000000

Сравнение битов двух чисел выше всегда вернёт 0, т.к. второе число тоже 0. Неважно, какие там будут биты у первого числа, всегда в итоге 0.

Но проблема кода здесь связана со спецификацией Си. Код небезопасен, потому что теоретически компилятор может делать всё что угодно! Программа может "упасть", компилятор может удалить код и прочее. Компилятор имеет право делать что угодно в этом случае. Undefined behaviour - это поведение программы, для которого стандарт языка не накладывает никаких требований, стандарт не говорит, что должно или не должно произойти!

Т.е. писать код таким образом в Си - опасно. Даже переполнение обычного signed int (он же просто int) в Си - это уже undefined behaviour!

int x = 2147483647; // Максимальное значение
x = x + 1; // Опачки - undefined behaviour - рисково!

Вот такое приходится учить. А кто-то жалуется на сложности Golang.

программирование

C (язык программирования)

языки программирования

Как по-английски костыль в программировании

volchara

недавно

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

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

Так вот на английском языке есть аналогичное слово - kludge (кладж). Смело используйте его в своих слаках и гугл-митингах, когда общаетесь на английском. Никаких больше workaround, теперь только честный kludge!

жаргон

программирование

английский язык

167

Как в Git безопасно поправить коммит в удалённой (remote) ветке

connected2u

недавно

Представим вы несколько дней работали, писали код и наконец-то сделали коммит:

git commit -m "#715 changed color of button from red to green"
git push

И тут вы понимаете, что забыли убрать какой-нибудь console.log() или fmt.Println().
Можно добавить ещё один коммит поверх, что-то вроде:

git commit -m "#715 clean unnecessary code"

Но в некоторых командах это могут посчитать мусорным коммитом. Что делать?

Вместо второго коммита "правим" первый коммит, дописывая amend:

git commit --amend -m "#715 changed color of button from red to green"

И теперь можно пушить снова. Но сервер не даст запушить, ведь у нас локально и на ремоуте уже разные истории одной ветки. Можно запушфорсить:

git push force

Но это может быть очень плохо, если над веткой работает несколько человек. Кто-то мог уже поверх нашего коммита свои коммиты накатать. Но есть хороший параметр force-with-lease, который перезапишет ветку только тогда, когда никто поверх не дописал свои коммиты:

git push --force-with-lease

В этом случае никто не пострадает.

Git

программирование

Эффективность использования всех ядер процессора в NodeJS с помощью cluster

dima

1 г. назад

Для повышения производительности приложений на NodeJS во всех материалах рекомендуется использовать нодовский встроенный модуль cluster. Все статьи повторяют одно и то же, что и так написано в документации.
Вот официальный пример из доки:

import cluster from 'node:cluster';
import http from 'node:http';
import { availableParallelism } from 'node:os';
import process from 'node:process';

const numCPUs = availableParallelism();

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

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

Во-первых, некорректен нейминг переменной numCPUs. На моём компьютере, на котором тестировал производительность, стоит процессор Intel i7-13700, в нём всего 16 ядер. Сайт Intel так и пишет:

Обратите внимание: 16 ядер и 24 треда. И нода после вызова availableParallelism() возвращает число 24, а не 16. Так что это не ядра, а треды.

Во-вторых, большинство нодовских приложений - это обычные API. Какой-нибудь REST API, гоняющий туда-сюда JSON. А берётся этот JSON в большинстве случаев из базы данных вроде PostgreSQL. Многие сайты, описывающие работу с модулем cluster в качестве примера, почему-то возвращают моковые данные, захардкоженные прямо в коде, а в реальную базу данных не лезут. И потом делают нагрузочное тестирование по этим данным. Т.е. при таком подходе на каждом ядре сидит по процессу NodeJS и другие процессы не мешают их работе, не заставляют переключать на себя внимание ядра.

А теперь давайте проведём тест на реальной работе REST API. Это будет GET-запрос за сущностью по её id. Чтобы сформировать JSON этой сущности, нода совершает не один, а несколько сложных запросов в базу данных. Кэширование в глобальных переменных или в Redis не используется.

Для тестирования я использовал пакет bombardier, написанный на Golang.

go install github.com/codesenberg/bombardier@latest

Сначала провёл тест на Windows 10.
Запускаю:

bombardier http://127.0.0.1:7100/api/some/1101

Результат без cluster:

Bombarding http://127.0.0.1:7100/api/some/1101 for 10s using 125 connection(s)
[=================================================================================================================] 10s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      2754.89    1413.90    5813.88
  Latency       45.31ms     1.95ms    72.43ms
  HTTP codes:
    1xx - 0, 2xx - 27625, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     9.99MB/s

Результат с cluster (все 24 потока):

Bombarding http://127.0.0.1:7100/api/some/1101 for 10s using 125 connection(s)
[=================================================================================================================] 10s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      8424.89     801.49   15177.67
  Latency       14.84ms     1.69ms    72.64ms
  HTTP codes:
    1xx - 0, 2xx - 84224, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:    30.54MB/s

Разница по производительности почти в 3 раза.

Показать полностью...

Node.js

JavaScript

производительность