Aký programovancí jazyk? pre 2023

2.8.2023 22:19 | Přečteno: 1580× | Hardware | poslední úprava: 2.8.2023 22:19

Každých pár rokov si kladiem túto otázku a zčasu na čas sa skutočne nejaký nový jazyk naučím.

Snažím sa učiť jazyky, tak aby som si čo najviac rozšíril obzory. Keďže v práci ako frontendista používam najme JavaScipt (>ES6) / TypeScript (v minulosti aj C# a PHP) tak beriem jazyky z úplne iného súdka.

Posledné jazyky čo mi niečo dali boli F#, Elm, C++ a Erlang.

O výbere jazyka bude aj anketová otázka. Do ankety sa bohužiaľ zmestilo len pár jazykov, samozrejme podľa môjho výberu, snažil som sa vyberať navzájom, čo najviac odlišné jazyky, ak máte návrhy na nejaké iné - napíšte ich prosím do komentárov. Do ankety by sa určite hodil aj Kotlin, Scala, Zig, F#, OCAML, SML, Elm, Go, Erlang, Python, Smalltalk, ale niektoré z nich už ovládam a navyše snažil som sa zamerať na trendy obdobia 2018 - 2023.

1. Rust - multiparadigmatický nízkoúrovňový jazyk od Mozilly, doteraz asi najzaujímavejší počin v tejto oblasti (od vzniku C++)
2. Swift - multiparadigmatický protocol oriented jazyk od Apple, ktorý má za cieľ poučiť sa z chýb Objective C a stať sa mainstreamom na Apple platforme.
3. Nim - nízkoúrovňový jazyk s Python like syntaxou. OOP má podobné ako Go a navyše podporuje metaprogramovanie (napr. má makrá)
4. PureScript - strong typed - pure funkcionálny jazyk ktorý sa transpiluje do JS podobne ako Elm.
5. Lua - dynamický weak typed - skriptovací jazyk s prototypovým OOP s veľmi maličkým interpreterom. Používa sa najme vo svete vývoja hier a ako doplnkový jazyk k C++. Sémantikou pripomína JS, ale je ešte jednoduchší (a v tom spočíva aj jeho krása). Syntaxou sa trošku podobá na Pascal. Existujú rôzne varianty tohoto jazyka napr MetaLua.
6. Julia - rýchly dynamický jazyk určený na vedecké výpočty pre LLVM
7. Elixir - dynamický jazyk pre erlangovskú BeamVM s Ruby like syntaxou
8. IO - dynamický objektový jazyk s prototypovým OOP a message passingom.
9. Reason - jazyk od facebooku so sémantikou inšpirovanou OCAML, pričom syntax je upravená pre React framework (kôli kopmpatibilite s JSX)
10. Pony - Strong typed, objektovo orientovaný, actor model based jazyk.

       

Anketa

Komentáře

[KAPAVKA]

KDE JE JAI

[gsnak]

Vanilla JavaScript. Tam kde neni dať libv8 a pridať podporu js.

[plostenka]

Jednoznacne LISP.

[hdbxbxbxb]

presne. nechapu ze nekoho furt bavi vymyslet podmnoziny moznosti lispu. asi aby to bylo cool nebo co.

[Max]

Dřív se lidi webařům smáli, a následně se dostal javascript i na backend a všechny úsměv přešel.
Připadá mi, že je v dnešní době spousta věcí o javascriptu (frontend, backend, nodejs, angular, react, typescript, electron, typeorm, graphql...) a rustu.
Zdar Max

[.]

V JS dnes uz primo kodi malo lidi, stal se takovym assemblerem Vetsina transpiluje z TS nebo jinych.

[plostenka]

javascript i na backend a všechny úsměv přešel.

Protoze ani nejsilnejsi antidepresiva proti JS nepomahaji.

Připadá mi, že je v dnešní době spousta věcí o javascriptu

No a podle toho to taky vypada. Kazda jednotliva Electron app sezere o rad(!) vic RAM nez cely OS, zpetna kompatibilita je u JS matlalu sproste slovo, nevis dne ani hodiny kdy s minor verzi random knihovny se zmeni API takze armada indu neustale neco prepisuje (a nevyhnutelne u toho neco rozbiji)...

a rustu

Rust mel sanci (konecne) nahradit plain C. Jenze to by musel byt kompatibilni aspon sam se sebou, aby se daly rozumne delat sdilene knihovny. Jenze to ne, je nova doba, vsechno budes dokolecka rekompilovat a jednu knihovnu mit v pameti 100x. Such improvement, many buzzwords.

[Max]

Však já to s tím javascriptem napsal dvojsmyslně schválně :D
Stále někde slyším o tom, že jsou i lidi, co kódí v js čistě, ale ještě jsem žádného nepotkal :).
Zdar Max

[kralyk z abclinuxu]

Rust mel sanci (konecne) nahradit plain C.

Ne, Rust nikdy nebyl myšlen jako náhražka C. Spíš C++.

Jako náhrada C jsou myšleny spíš jazyky Go, Zig nebo Hare...

Jenze to by musel byt kompatibilni aspon sam se sebou, aby se daly rozumne delat sdilene knihovny. Jenze to ne, je nova doba, vsechno budes dokolecka rekompilovat a jednu knihovnu mit v pameti 100x.

Tuhle diskusi už jsme vedli. Rust se technicky v tomho ohledu ničím neliší od C++. C++ také negarantuje kompatibilitu "sám se sebou", ani standardní knihovna není binárně kompatibilní napříč linuxovými distry. Což není ani Céčková stdlib. Proč si tady nestěžuješ, že 3/4 boostu jsou header only a dokolečka se rekompilují? A ten zbytek ani nedodržuje semver kompatibilitu - ale špatně je Rust?

Ten požadavek na sdílené knihovny (a jejich balíčkování) bych osobně začal nějak respektovat ve chvíli, kdyby se linuxová distra v tomhle ohledu dohodla na nějakém společném postupu a vzájemné kompatibilitě. Pak by to mělo smysl, ale do té doby je to vyhozená práce.

To, že se lidi obracejí k statickému linkování nebo různým AppImagím, Snapům atd. není nějaký zlý úmysl záškodnických hipsterů, ale reakce na to nesmyslné lpění na tom nekompatibilním chaosu. Dokud ten chaos bude trvat, lidi budou preferovat alternativy a nějakých pár kB nebo MB sdílené knihovny navíc fakt nikoho nezajímá.

[Kate]

Dynamické linkování je hezký sen, ale realita už teď vypadá krapet jinak, navíc samo o sobě přináší nemalý overhead.

[petr_p]

Teď? Ta statistika vůbec neporovnává teď a tehdy. Navíc to je klasický případ statistiky, kterou jsem si zfalšoval sám, aby mi poskytla výsledky, které potřebuji: Předvýběr typu „100 nejčastějších“ je zatížen předpoklady, které ovlivňují výsledky. Chybná metodika, kdy do vstupu beru všechny programy a na nich zkoumám kolik knihoven linkují bez ohledu na to, že to vůbec není dynamicky linkovaný ELF (například skript), je k pokukání. A tak by se dalo pokračovat. V podstatě jediný kvalitní výstup té statistky je, že na jeho systému ze 5688 programů je 4483 dynamicky linkovaných. Takový výstup ovšem stěží může podpořit tezi, že statické linkování válcuje dynamické na všech frontách.

[kralyk z abclinuxu]

Huh? Jaký předvýběr? Skripty odpadnou tím, že na nich ldd nevyprodukuje výstup. Mně to přijde v pořádku. Samozřejmě, je to výstup z jednoho systému. Ale i tak to je IMO zajímavé.

Jediný, co úplně neberu jako vypovídající, je ta část o velikosti binárek, IMO počet použitých symbolů to až tak neurčuje. Ty binárky větší budou. Ale ani tak nepovažuju velikost reálně za problém.

[petr_p]

Jaký předvýběr?

Kapitola „Will security vulnerabilities…“. Nejprve si zvolí hranici 100 programů, které používají stejnou knihovnu, a na konci má egrep opět na nějakou jinou množinu knihoven vycucanou z prstu.

Skripty odpadnou tím, že na nich ldd nevyprodukuje výstup

Skripty by neměl počítat ani jako statické, ani jako dynamické. Nebo když už, tak jako dynamické, protože jejich interpreter bude zcela určitě dynamicky linkován. Místo toho je hned v první kapitole započítá jako statické.

Jeho výsledky zajímavé jsou. Ale jen jako orientační, nebo trendové. Rozhodně ne ale seriózní.

[kralyk z abclinuxu]

Ok. No, ono by se to hlavně muselo uělat na mnoha systémech, nejlépe více různých druhů...

[_.,]

Udrzovals nekdy nejaky node backend? Problem je v tom, ze to typicky pisou frontendisti nebo "fullstack" frontendisti a podle toho to potom vypada. My vsechno z tohodle duvodu prepisujem do pythonu nebo C++ nebo kombinace tech 2 jazyku. Najit schopnyho backendaka co dela v node je strasne tezky.

[Člověk z Horní Dolní]

Najit schopnyho backendaka co dela v node je strasne tezky.

A kolik bys mu dal za mesic?

[_.,]

To je přesně ono, řeknu o pět tisíc víc než máš a za max. rok tě někdo přeplatí. Tohle nechám nadnárodnim korporátum.

[RealJ]

Takovy fakeJ tady dela FE/BE reseni i pro webovou prezentaci o 5ti strankach. Pokud najdes takoveho srdcare tak ti to bude psat za misku orisku a sklenici vody. A pokud to nazves open source tak ti to lidi budou psat uplne zdarma. Platit nekoho neni moderni.

[Max]

Řekl bych, že cena nebývá ten hlavní problém. Když někdo řekne, že nemůže nikoho sehnat, tak to je pro mnohé znak toho, že neumí zaplatit. Má zkušenost je jiná. Nabídneš za konkrétní post královské prachy a stejně seženeš max někoho, kdo se chlubí, ale umí kulový. A nejhorší jsou ty posty, co jdou špatně kontrolovat (např. chybí znalosti problematiky, takže nelze odhadnout časová náročnost atd.).
V našem případě jsme se několikrát spálili u DevOps, nedostatek lidí, chyběl člověk na novou pozici, který by pomohl rozjet projekt. Nejdříve jsme našli někoho standardní cestou, když to nešlo, tak šel od válu. Nakonec nám byl dodán člověk firmou, co se zabývala analýzou a vývojem. Za dva roky vytvořil něco, co bychom dnes s dnešními znalostmi považovali za práci na 3 měsíce. Na DevOps se tedy částečně transformoval jeden devík, jeden admin a já, ač se bráním (no time), tak něco také musím řešit.
Zdar Max

[podlesh]

No to máte z toho, že si vyrobíte pozici zvanou "DevOps" - tedy termínem který původně znamenal, že si dohromady sednou:

jeden devík, jeden admin a já, ač se bráním (no time), tak něco také musím řešit

No ale alespoň jste se nakonec dostali na ten správný začátek

[Max]

Já dev nechci řešit, stačí mi ten team, co vedu. Bohužel i tak musím přičichávat k DevOps a znát styl vývoje, údržby, věci, co jedou aktuálním stylem (CI/CD, devíci napříč kontinentem, microservices atd. atd. atd.) a vím, že to je asi budoucnost a ten brutální overhead se asi jednou vyplatí. A také samozřejmě vím, jaký je problém s vývojáři a jejich vedením. Každopádně backend jedeme v net core a není problém. Problém je u toho frontendu, tedy js se všemi frameworky apod.
Pamatuji si, jak kdysi jeden bývalý kolega, programátor, protlačil do nového projektu Nodejs. Za celou dobu vývoje se nebyl schopen ani pořádně připojit do db (pořád se mu plnil pool, generoval šíleně spojení atd.), na tom projektu se vystřídalo několik vývojářů a všichni shořeli. Nakonec se toho ujal další, který s nodejs neměl zkušenosti, nastudoval a uvedl to o provozuschopného stavu.
Jo, všechno je jen o lidech a asi nemá cenu hledat konkrétní skill, ale zkušeného týpka, který se nebrání změně.
Zdar Max

[M.]

To jo, když webare pustili k backendu, tak šly vsechny žerty stranou.

[Idris]

Idris

[z_sk]

Rebríček programovacích a iných jazykov použitých v 4000 najčastejšie inštalovaných softvérových balíčkov v operačnom systéme Debian.

[_]

Tak ja bych se dal na ten "PO File" jazyk, je treti nejpouzivanejsi v debianu!

[Erlang Senior Programmer]

Pises ze chces trendovy jazyk z rokov 2018 - 2023 a do vyberu zaradis 30 rokov staru Lua? Vela borcov preslo z Lua na Janet.

[RealJ]

Ja bych se chtel naucit brainfuck ale vzdy kdyz ho vidim tak si rikam ze na to proste mentalne nemam.

[Gilhad]

Já se teď chystám naučil 6809 assembler.

Počítač už mám (OMEN Kilo), navrhnul jsem si rozšiřující desku Expanduino, takže bude i práce s SD kartou a RTC (až ji osadím a oživím a naprogramuju to Arduino na ní) a spousta nápadů, co by to mohlo dělat tu je taky, takže jen zbývá se naučit ten assembler ...

[dd]

Assembler si dokážu představit, ale zajímají mě ty tvoje nápady. Díkec

[Gilhad]

Z éry 8biťáků mám pořád ještě nedokončených (spíše polozačatých) textových her, které bych někdy rád dodělal (a teď už by to zase šlo, zvlášť když bych mohl vyvíjet na velkém ppočítač s gitem, rychlou odezvou a spolehlivým ukládáním/načítáním).

Pro tu desku samotnou chci upravit původní Monitor, aby v prvním kroku uměl komunikovat jak s vestavěnou MC6850 ACIA, tak s Expanduinem a pokud bude zapojené, tak mu na začátku vyslat nějaký prompt. Expanduino ho rozezná a nabuší tam (jakoby ručně) přez Monitor vlastní kód pro komunikaci se sebou a pak tam přez něj přepošle poslední verzi "firmwaru" abych nemusel furt přepalovat (EEP)ROMku. Čili takový "bootsektor".

A pak už to půjde rozbalit - komunikace v barevném ANSI textu, systémové rutiny pro menu, práci se soubory, reálným časem, vším možným a nemožným a do toho už půjde začít s těma hrama, které budou používat "BIOS" pro řadu společných věcí (a asi přez nějakou úvodní tabulku, která půjde snadno přepsat, pokud se BIOS přemístí a změní, takže by pak šly rozjet i na jiném HW, který by jen emuloval služby Expanduina)

Navíc, protože je tam to Arduino a má ještě asi 6 pinů volných (+I2C, +2 SPI zařízení, +USB komunikaci s PC, +SD karty), tak by tam mělo jít časem přidat děsná spousta dalších zařízení jako PS/2 klávesnice, nějaké LCD, možná i připojit modul/desku s grafickou kartou (například Rapsberry Pi přez I2C a posílat mu grafická primitiva jako zprávy a ať to rozkreslí samo - takže klidně i sprity a vyšší abstrakce) a vůbec, pro Arduino je teď všude modulů ...

Takže když vhodně rozdělím problém, tak ho šikovný BIOS bude schopný zobrazovat mnoha kreativními způsoby.

Ale s nepatrnými náklady spousta zábavy na mnoho dalších let :)

[Radovan]

https://commodore.bombjack.org/generic/reference-cards/6809-6809E_Reference_Card.pdf

Má tam toho víc

[Gilhad]

Díky tuhle kartu už má, stejně jako některé další materiály, ale má tam k 6809 i věci, které ještě nemám ...

[Luky]

akurat mam Nintendo 2DS XL, ktore len sem tam zapnem a Nintendo Swith Lite toto je daily zapnute koli diablo 3, pametam si na casy minule ked som mal atari800xe a cchem povedat len tolko ze najvecsie caro tzchto veci su CATRIDZE, mala vecicka ktora obsahuje eepromku aspon v pripade tohto atari ale nintendo sa toho drzi stale, ja nechapem preco toto nepouzivaju aj iny, cena eeprom pripadn nejakej read only emmc nie je velka a je to super vec zasunies, zapnes system a mas instantne disk s hrou, pripadne sysstemom

[RealJ]

Protoze kdyz tech her mas 5000 tak musis mit dalsi mistnost v baraku… proto se od toho upustilo.

[Luky]

Ok, nintendoswitch ma uz o dost mensie cartridge, horko tazko je tam ten emmc chip natlaceny, ale v dnesnej dobe potesi aj hardverove medium kedze vsetko je uz online k stiahnutiu pre danu platformu

[RealJ]

Ja souhlasim s tebou ze nejaky online provozovatel je pruser. Me prijde nejlepsi moznost si hru stahnout (treba gog) a skladovani nechat na uzivateli.

[prt]

Super blog, dík za anketu

[Luky]

FreeBASIC + asm

[AAAA]

Mam zkusenost s: Java, Julia, Kotlin, C++, JavaScript, TypeScript, Python, Objective-C (fuj), Dart, Clojure. A u par dalsich vctene Rustu jsem precetl tutorial a pripadne napsal neco na par radku.

Hodne jsem si oblibil TypeScript+Deno, je to fakt prijemny na pouziti a zaroven rychly. Je to prekvapivy, ale s TypeScript+Deno se pracuje znatelne lip nez s TypeScript+Node. To Deno je v podstate takovy ekosystem okolo TypeScriptu.

Pak je dobry Swift, oproti TypeScript+Deno ma ruzne vyhody a nevyhody. Kdyz vezmu ciste ten jazyk a ne ekosystem okolo, tak Swift je lepsi.

Pokud je potreba performance, tak C++ nebo Rust.

Driv jsem pouzival Julii, ve spouste ohledech mi to prislo super, ale postupne mne tam zacalo spousta veci vadit a kdyz jsem prepsal jeden projekt do TypeScript+Deno, najednou mi to prislo takovy osvobozujici.

[perlista]

A kde je Perl?

[neexistuje lol]

neexistuje lol

[(k)(o)(u)(z)(l)(o)]

Tohle byl dost spatny vtip. Nechte uz ten Perl odpocivat v pokoji. Bylo to monstrum s pritroublou syntaxi a jediny na co se to hodilo je parsovani stringu. Ale Svedci Laryovy to vid jinak a porad se z hovna snazi uplest bic, tentokrat pod navem Raku... velky spatny

[RealJ]

Perl bud unis nebo ho nemas rad. Je videt ze ho neumis.

[Ariczek]

Podle 5 Programming Languages to Learn in 2024 jsou to: Java, Python, JavaScript, SWIFT a C++. Takže žádné překvapení... za sebe bych k té Javě přidal ještě Kotlin, minimálně pro Android svět.

[🇹🇬]

zig :D ;D

[antifasista]

Nehajluj Greto :D

[karkar]

Ti probrali blogýsek, ne? nebo se mi to zdá, že tam kdysi bylo víc článků?

[RealJ]

To vis, ted musi psat zelene clanky a hrichy linuxoveho mladi se “ztratili”

[karkar]

A kde je slovensky narodni programovaci jazyk Cobol?

[RealJ]

Horná Očová. Uchlastal se ke smrti.

[RealJ]

Jozef.

[Timotej Kuchár]

D

[Heretik 《小魔神》]

Javascript??

Dokonce i abclinuxu hází neustále dokola chyby jako

JavaScript error: https://www.abclinuxu.cz/blog/ASDFGH/2023/8/aky-programovanci-jazyk-pre-2023, line 3246: ReferenceError: bmone2n is not defined

Blázni všude kam Oko dohlédne.

[tester4]

https://vlang.io/