Владислав

Эта элементарная задача называется "генерирование дискретных случайных величин с заданным законом распределения". Решается классическим образом.
Сначала разбиваем наш диапазон от 1 до 100 на следующие интервалы:
1-35,36-60,61-85,86-95,96-100.
Затем генерируем число, равномерно распределенное в диапазоне от 1 до 100. Номер интервала, в который это число попадает дает ваши генерируемые цифры - от 1 до 5, причем распределены они в точности по вашей таблице распределения.

dmshar все правильно вам написал, разбивайте число из диапазон 1..100 на интервалы

function foo() {
  let random = Math.floor(Math.random() * 100) + 1; // 1..100
  switch (true) {
    case random < 36: return 1 // 35%
    case random < 61: return 2 // 25%
    case random < 86: return 3 // 25%
    case random < 96: return 4 // 10%
    default: return 5
  }
}

Тест: запустим 10 млн раз и посмотрим распределение

Глобальные переменные в большинстве случаев нарушают инкапсуляцию. К ним открыт неконтролируемый доступ отовсюду.

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

Глобальные переменные в большинстве случаев нарушают принцип инверсии зависимостей (или делают возможным его нарушение).

Глобальные переменные ухудшают масштабируемость проекта.

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

Глобальные переменные приводят к трудноуловимым ошибкам. Примеры: нежелательное изменение её значения в другом месте/другим потоком, ошибочное использование глобальной переменной для промежуточных вычислений из-за совпадения имен, возвращение функцией неправильного значения при тех же параметрах (оказывается, она зависима от глобальной переменной, а ее кто-то поменял).

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

Тримы работают вполне нормально https://play.golang.org/p/31OXind1eyt

str := "UserName: Vasya Pupkin"
result := strings.TrimPrefix(str, "UserName: ")
fmt.Println(result)

for index, item := range cyber.Links {
	fmt.Printf("%s: %v\n", cyber.Titles[index], item)
}

Как бы это странно не звучало, но одно из главных преимуществ TypeScript - это ускорение разработки в несколько раз. Да, когда еще ничего нет - разработка незначительно замедлится, так как помимо логики нужно описать еще и типы. Но это только в начале. И это не только возможность писать большую часть кода с помощью автодополнения. Поддержка существующего кода занимает в десятки раз больше времени, чем его начальное написание. Стоит ли вложить несколько лишних часов на старте, чтоб сэкономить в последствии месяцы? Как по мне стоит.

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

Ну и отвчечу на некоторые Ваши сомнения:

TSLint в VSCode прям жутко тугой

TSLint официально deprecated, вместо него стоит использовать плагин к eslint, заодно можете мой конфиг попробовать.

Типы? Есть JSDOC

JSDoc в плане типов не умеет и 10% того, что умеет TypeScript. Кроме того, никто в здравом уме не пишет JSDoc на приватную логику, а значит проверки типов там не будет. JSDoc не гарантирует корректность рефакторинга, а вот благодаря TypeScript я, опять таки, точно не забуду обновить JSDoc.

многие библиотеки nodejs не имеют типов

может лет 5 назад так и было, но сейчас встретить библиотеку без типов - скорее исключение. Если библиотека популярная, но не предоставляет типов, скорее всего их уже написал кто-то другой, достаточно просто установить одноименный модуль из npm скоупа types и все будет работать само.

Поддержка браузерами скомпилированного кода? Да какбы почти весь JS имеет поддержку 95%+, тот же Babel уже забыл когда использовал.

Вообще это не основная задача компилятора TypeScript, а опциональная возможность. И babel + preset-env с ней справляются гораздо лучше. И никто не мешает использовать их вместе. А еще думаю вопрос времени, когда кто-то напишет оптимизатор кода использующий информацию о типах из TS.

Примерно в каждой второй есть инстансы, на которые смотришь - и чешешь репу - а как называется тип этой переменной в @types/?

import {someObject} from 'some-library';

type TypeFromValue = typeof someObject;
const valueCopy: TypeFromValue = {
    ...someObject,
    type: 'overrides',
    with: 'type check',
};

и кстати, вот пример того что JSDoc типы не умеют.

//@ts-check

и почти везде останется бесполезный any.

P.S. удачи такие типы на JSDoc описывать
P.P.S. Еще прелести современного TypeScript невозможные у...

Бенчмарки - это хорошо, но очень важно понимать что именно там меряли и почему результаты именно такие.

Несколько лет назад я тоже делал бенчмарки Python, PHP, Node, Go.
Для меня были важны две вещи:
1 - скорость ответа сервера/кол-во запросов в секунду
2 - объём сервиса в памяти, т.к. от этого зависит стоимость ресурсов

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

Но вся эта разница сошла на нет, как только добавился всего один простой SQL запрос в базу, в таблицу с 10 строками. И на этом фоне разница по скорости ответа была меньше 10%.

Иными словами если ваш сервис работает с базой - критической разницы по скорости работы между Go/Rust/PHP/Node/Java, особо не будет.

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

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

Один экземпляр Go занимал в памяти порядка 6мб RAM, при том, что Pytho+Django порядка 60мб.
Node уже не помню сколько, но что-то близкое к Python'у.

Вот тут уже, когда серверов у вас будет много - количество серверов с Go у вас будет в 10 раз меньше, соответственно расходы за эти сервера у вас будут в 10 раз меньше :)

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

Где-то читал статью, что у людей было API на порядка 40 серверов на Node, после переписывания на Go - серверов осталось два, из которых второй запасной :)

1. Для упрощения кода. Скажем, чтобы не писать каждый раз всю конструкцию аля

   axios.get(ENDPOINT + '/api/' + API_METHOD, {
     params: {
       id
     }
   })
   .catch
   ...

   
   Делается обёртка, условная функция getUser(id). В неё выносится вся логика по работе с запросом, определение маршрутов АПИ, обработка ошибки и так далее. Наружу торчит только одна функция и параметр.
   
2. При работе с TS это проще типизировать. Намного легче описать типы принимаемых параметров и возвращаемый тип для нескольких функций, чем описывать универсальную конструкцию для доступа к любым методам апи.
   
3. Ну и наконец: сервис можно вызывать прямо в компонентах. Вызывать методы АПи не обязательно внутри Vuex. Доже чаще это должно выполняться внутри отдельных компонентов, каждый из которых работает с одним-двумя апи, а не со всем набором.
   

Gopher (гофер).

Потому что некоторые задачи имеют дело с повторениями.

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

Однако что если вам нужно найти все цифры между двумя E?
Вот такие:
E123ExxxE456E789E

По вашей логике нужно выражение: /E(\d+)E/
И да, оно действительно найдёт 123 и 456 (см. ссылку), но на 789 оно сломается, потому что там E входит как бы сразу в две подстроки. В этом случае и нужен позитивный просмотр вперёд. Мы как бы подсматриваем, что там впереди, но не захватываем, поэтому поиск следующей подстроки начинается раньше.
Для такой задачи решением будет: /E(\d+)(?=E)/

Redis как кэш актуален для "одноядерных" языков вроде node/python/php. Там большие проблемы с многопоточным доступом к памяти, поэтому вместо памяти используют key-value (memcached еще вспомнить можно). А если у вас голанг - так зачем редис? Воспользуйтесь кэшом в памяти, всё еще на порядок быстрее работать станет за счет отсутствия сетевых взаимодействий на кэш-хитах.

Ну если по фактам раскидать дальше только хуже. Так что или сдался или поборол себя и пошел дальше. Это еще верхушки. А дальше нужно придерживаться DRY, KISS, SOLID, YAGNI. Учить и применять паттерны. Одумайся пока не поздно...

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

Потому, что ваше приложение падает при запуске. И даже ошибку выводит о том, что порт 8080 занят.