Переважно в комп'ютерних іграх, наскільки я розумію? Чи не тільки?

Абсолютно всi натiв-мови використовують для:

...

останнiм часом захоплює ринок Інтернет-речей (IoT).

Хаскель варто розглядати, коли ваша програма має прийняти щось на вхід, обробити його, і віддати результат обробки на вихід, при цьому без жорстких часових обмежень. Наприклад, компілятор. Або якась обробка зображень.

Java для розробки десктопних прог використовують дуже рідко. Принаймні у мене на домашньому компі таких немає жодної. На роботі одна була, але на неї без сліз неможливо було дивитися.
С# - десктопний софт для вінди, та майже увесь софт для віндофонів. Також популярний в ентерпрайзі.
Delphi - для тих хто не вважає себе програмістом, але пам'ятає паскаль з інституту, і час від часу має потребу швиденько щось збацати для власних потреб.
SQL та мови на його основі - робота з базами даних.
JS - фронтенди для вебу.
Rust, Go - спроба виправити помилки в генетичному коді C++.

можливо це буде отак виглядати,

але запитаю: assambler?

По-моєму, лише там, де потрібне щось низькорівневіше за Сі. Мода на прикладні програми з асемблерними вставками була в вісімдесяті, але нині, схоже, це вже неактуально.

Torbins, перечитав, з другої та навіть третьої спроби ближчими до реальності наведені в них твердження не стали. Я навів щонайменше декілька прикладів десктопного ПЗ на Java з мільйонами користувачів, на які, кхм, не лише можна, але й щодня дивляться без будь-яких сліз.

чого тільки для малини не використовують http://raxp2.blogspot.com/2012/05/raspb … -faq.html, а якщо встановлен Win IoT, то фантазія не обмежена.

з JAVA додатків у мене вдома Sweet Home 3D, та ще SDK, який ембаркадери підтягують )

ось так одним махом з плеча рубати ))) У мене промислові додатки на ньому і не на ньому, бібліотеки, і не для власних потреб.

не варто виділяти якийсь із натів окремо, ті ж драйвери в ОС і навіть під МК можна писати на Пуріке, прикладів безліч.

як би так й як би вже і нi. Сучасні компілятори оптимізують код, що на Сі, що на ASM майже однаково, а мороки з АСМом набагато більше в плані переносимості коду. ASM залiзякозалежен.

p.s.: до речi, якщо згадати історію самої Delphi, то взагалі замислювався для роботи з базами даних спочатку. Та й сам він лише відгалуження FP.

Я перечитую :-)
Об'єктивно не знаємо. Саме тому іноді варто перечитувати, щоб знати межі.

Пристойний сучасний компілятор має зрозуміти.

#include <stdint.h>

uint32_t foo1(uint32_t val, uint8_t n)
{
        return (val << n) | (val >> 32-n);
}

int a, b;

void moo(int c, int d)
{
        a = c / d;
        b = c % d;
}

foo1:
        movzbl  8(%esp), %ecx
        movl    4(%esp), %eax
        roll    %cl, %eax
        ret

moo:
        movl    %edi, %eax
        cltd
        idivl   %esi
        movl    %eax, a(%rip)
        movl    %edx, b(%rip)
        ret

foo1:
        rsb     r1, r1, #32
        rors    r0, r0, r1
        bx      lr

moo:
        sdiv    r3, r0, r1
        mls     r1, r1, r3, r0
        ldr     r2, .L2
        ldr     r0, .L2+4
        str     r3, [r2]
        str     r1, [r0]
        bx      lr

Навіть складніші речі компілятор виловлює. От дещо обчислюється у знаковому 32-бітному акумуляторі з фіксованою крапкою і запасом по розрядності в старші біти. Результат на ЦАП треба видати 12-бітний беззнаковий з насиченням з цілої частини акумулятора (тобто акумулятор може залетіти в мінус або більше 4095, це треба зсунути вправо і потім обмежити).
gcc ставить одну команду CM3 на всі ці дії. Спеціально дивився, бо там по часу тісно, то чи треба буде асм-вставки робити, чи ні.

#include <stdint.h>

int32_t acc;
// Тут для демонстрації виділено в окрему функцію
// Реально це частина більшого коду і там взагалі одна команда,
// бо не треба виймати з пам'яті
uint16_t get_value()
{
        int32_t val = acc >> 18;
        if (val > 4095)
                val = 4095;
        else if (val < 0)
                val = 0;
        return val;
}

get_value:
        ldr     r3, .L2               ; Завантажили адресу акумулятора
        ldr     r0, [r3]              ; Завантажили значення акумулятора
        usat    r0, #12, r0, asr #18  ; Все тіло функції
        uxth    r0, r0                ; приведення int32 до uint16
        bx      lr

.L2:
        .word   acc

І от саме тому, що я вичитую, іноді я таки пишу на асемблері.
Хоча загалом ще з фідошних ех в усіх суперечках asm vs C стояв на тому, що треба писати на С — за виключенням тих випадків, коли ти точно знаєш, чому саме ти пишеш на асмі (за результатами прогонів та вивчення згенерованого коду).