Developer

Есть термины функция, процедура, метод в рамках парадигм программирования, но терминология в C# иная.

В C# нет функций и процедур, есть только методы и делегаты.
Лямбда-выражения, в зависимости от контекста, "под капотом" приводятся к анонимным делегатам с телом или к Func, Predicate, Action.
Все утыкается в объектную модель, которую поддерживает абстрактная машина языка C#.
Единицей трансляции является класс, и свободных функций в namespace быть не может, так же как и указателей на функцию в принципе - вместо указателей на функцию в C# используются делегаты. Делегат реализован как абстрактный класс, это позволило реализовать типобезопасные ссылки на методы, которые можно складывать и вычитать, позволило удобно реализовать асинхронность.

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

В C# нет понятия функции как объекта, функцию нельзя просто так создать. Вообще можно, но прежде чем её использовать, её нужно будет скомпилировать, но она будет в любом случае в каком-то классе, и она будет методом этого класса; и чтобы методы вызвать, сначала надо получить ссылку на экземпляр класса.

Multiprocessing и multithreading относятся к стратегии управления разделяемыми ресурсами и оптимизации простоев между задачами, а Asynchronous invocation к паттернам проектирования.

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

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

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

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

/// <summary>Служит хэш-функцией по умолчанию.</summary>
    /// <returns>Хэш-код для текущего объекта.</returns>
    [__DynamicallyInvokable]
    public virtual int GetHashCode()
    {
      return RuntimeHelpers.GetHashCode(this);
    }

https://stackoverflow.com/questions/720177/default...

Она же вызывает вот этот нативный код.

FCIMPL1(INT32, ObjectNative::GetHashCode, Object* obj) {  
    CONTRACTL  
    {  
        THROWS;  
        DISABLED(GC_NOTRIGGER);  
        INJECT_FAULT(FCThrow(kOutOfMemoryException););  
        MODE_COOPERATIVE;  
        SO_TOLERANT;  
    }  
    CONTRACTL_END;  

    VALIDATEOBJECTREF(obj);  

    DWORD idx = 0;  

    if (obj == 0)  
        return 0;  

    OBJECTREF objRef(obj);  

    HELPER_METHOD_FRAME_BEGIN_RET_1(objRef);        // Set up a frame  

    idx = GetHashCodeEx(OBJECTREFToObject(objRef));  

    HELPER_METHOD_FRAME_END();  

    return idx;  
}  
FCIMPLEND

Еще посмотрите эту статью.

see Knuth Vol 2 p16 (3.2.1.2 Theorem A)

https://habr.com/ru/post/188038/

https://codingsight.com/the-origin-of-gethashcode-...

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

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

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 млн раз и посмотрим распределение

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