Názory k článku Nechte Go plavat, teď sviští Java

Nechápu, proč si nepřipustí, že svět ovládne Haskell.

podivej se co bylo do javy za poslednich 10 let pridano a odkud to prislo ... a pak neco rikej

Treba lambdy, streamy, reactive streams, type interference, spoustu novych API?:-)
To ti prijde malo ?:)

To, ze nejsi schopen pochopit vyhody funkcionalniho programovani je tvuj, nikoliv muj problem.

Mám na trolling stejný právo jako ty nebo autor článku.

Ajéje, to zas bude v alejích ráno nablito.

Wtf to je clanek. Dnes v dobe .NET core nema smysl vubec premyslet nad Javou, protoze C# jasne vede. Mozna JVM trochu spasi Kotlin.

To je zajímavé, tolik mínusů a žádný argument. Osobně s .NET Core experimentuju, tak by mě i ty argumenty zajímaly.

To asi pre to. ze .Net Core je na tomto fore sproste slovo, lebo nieco pod BSD licenciou je menej open sourse ako nieco ine pod BSD licenciou vsak.

Ja si hraji jak s Javou tak .Net core a pro me proste skoro vse, co se tyka developmentu, od MS je par let pozadu. Od IDE pocinaje, tak po podporu CICD procesu. Tak treba prace s dependency managementem v mavenu je super, nugety, mno co rict a neurazit, proste vymysleji kolo, co na tom, ze je hranate ... Schvalne si zkuset udelat dva projekty na sobe zavisle v jave (pres pom) a pres nugety a developte v obou projektech a debugujte. V MS jednoduse nemozne.

Sory, ale ked s tym nevies robit ani si precitat tutorial, no za to Microsoft nemoze.
Ale na tomto fore su argumenty nanic, lebo viera je silenjsia.

Celkem souhlas. .NET Core je prijemna technologie, pouzivam to u nekolika projektu, ktere se migrovali z stareho ASP.NET a nikdo je nechtel cele prepisovat.
Proti puvodnimu .NET velke zlepseni, ale samozrejme to trpi syndromem nove technologie, jeste se to vychytava a ladi. Java si touhle fazi uz prosla, takze Gradle / Maven je opravdu nekde jinde.

O vyvojovych prostredich ani nemluve.

Studentíci za to nemohou. Na jejich bazarových noteboocích s předinstalovaným Ubuntu ani jiné tlačítko nefunguje...

Já dal mínus přesně za to, co sám píšete: že tam žádný argument není. Jen manipulativní "nema smysl vubec premyslet". Asi jsem ze staré školy, protože nás učili, že má smysl přemýšlet. Občas to trochu bolí a člověk tím zabije moře času, ale vyplatí se to. Vadí mi, když někdo tvrdí opak.

.NET core? Obcas taky placnu nejakou pitchovinu cestou z hospody...

problem .net je to, ze ho skoro nikdo krome MS nepouziva

https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

pokud chces delat predrazeny zakazky pro statni spravu, tak .Net je dobra volba, ikdyz i tam se asi vic pouziva Java. Nicmene pokud checes delat na nejakem zajimavem projektu (pr: nejaka cloud sluzba), tak se jazyky nad JVM nebo GO pouzivaji mnohem casteji. Minimum startupu pouziva .Net ve srovnani s jazyky nad JVM nebo GO.

C# je asi lepsi jazky nez Java, ale to neni vsechno. Navic pokud ti vadi Java, muzes pouzit Kotlin nebo Scalu, pak uz nemas jediny duvod, proc bys chtel pouzit .Net

Bohužel ta statistika nezahrnuje různé vnitrokorporátní systémy.

Článek ve kterém se dají najít odkazy na několik různých žebříčků oblíbenosti programovacích jazyků:
https://medium.freecodecamp.org/best-programming-languages-to-learn-in-2018-ultimate-guide-bfc93e615b35 .
Osobně považuji za seriozní např. TIOBE žebříček (přímý okda: https://www.tiobe.com/tiobe-index/ ). Každopádně i ve všech ostatníchžebříčcích C# dlouhodobě pouze padá a i když ho mám docela rád, rozhodně nevypadá do budoucna jako nejlěpší volba (určitě ne jako jediný případně primární jazyk).

Tak C i C++ zrovna v TIOBE (kupodivu) drzi poslednich 20 let stabilni pozici (1. nebo 2., max. treti misto) - mozno zkontrolovat zde: https://www.youtube.com/watch?v=ZkP4sv3H6g8 . Nakonec C# taky, jenom postupne pomalu klesa z 3. mista v roce 2012 na soucasne 6. misto 2018. Neprikladam tomu zvlastni vahu, ale trendy to podle me zachycuje dobre, vcetne ruznych modnich vln.

To už musí být Oracle hodně zoufalý...

Odkedy orakul "prebral" Javu od SUN-u, prestal som jej vyvoj sledovat, ale pisat, ze je zufaly, ked vlastne z nej nic nema a su tu openJava alternativy je trochu prehnane. Z clanku mi vyplyva, ze sa za tie roky, co Javu aktivne nesledujem moc nezmenilo. Akurat ten nativny kod pribudol. Ale aj to bolo planovane este SUN-om ak si dobre pamatam.

Když s tím neděláš, změn si nepovšimneš... ale kdo dělá s tím každý den by ti to rád vysvětlil, ale ovšem k čemu, když to pak tu informaci dáš do koše.

Kludne mozete k teme napisat blogovy prispevok tu na roote, ja si ho zase velmi rad precitam. Javu som kedysi protezoval, odkedy sa odstala k orakulu, skor ju zaznavam. Ale mozno mi zmenite nazor.
V sucasnosti mam nutenu volbu .NET/C# alebo Javu tak neviem ktore zlo je to mensie.

WTF, WTF, WTF a ještě jednou WTF. Může se to zdát jako jedno zmatení, ale považoval jsem to za tak důležité, že jsem to uvedl 4x.

Java je jazyk, který měl významnou roli, kde jsme teď, ale pořád je to překombinovaný jazyk pro psaní jednoduchých úloh. Ve složitých i jednoduchých úlohách již dnes selhává. Tedy je zbytečně nebo nedostatečně složitý. (tento text používám pro ilustraci)

Příští díl se bude jmenovat "Pusťte Javu k vodě, přecházíme na FORTRAN 77".

Napiste clanok o reaktivnom haskell-skripte :) Ak to bude mat hlavu a patu, root to opublikuje :)

S novým fortranem jsem se potkal a byl jsem fakt příjemně překvapený. Ten jazyk je daleko lepší, než co se o něm povídá.

Právě proto jsem schválně zmínil zrovna F77 a ne pouze "Fortran" bez bližšího upřesnění. Sám jsem v dobách svých studií napsal poměrně dost kódu ve F90 a dělalo se v něm příjemně. Na výpočty rozhodně nesrovnatelně příjemněji než v C++ nebo nedej bože v C.

>>Go je jazyk navržený od začátku tak, aby řešil problémy při psaní nízkoúrovňových programů spjatých s operačním systémem. Go to zvládá velmi dobře. Na druhou stranu Go zvolilo přístup, který v sobě má jistá omezení.

Takhle je napsaný každý jazyk, nežijeme v ideálním světě.
Go je evolucí C/C++ podobně jako je Kotlin evolucí Javy, podobně jako je Ruby evolucí Pythonu, stejně jako je BASH evolucí Bourne shelu, který je evolucí Thompson Shellu…

>>Go překladač je od základu napsán Go týmem. Nevyužívá žádné z obecně rozšířených systémů jako je GCC či LLVM. Vše je od začátku do konce napsáno Googlem. To se samozřejmě negativně odráží na šíři podporovaných fíčurek, ale i na rychlosti. Go tým prostě není nafukovací a nemůže všechny požadavky řešit tak rychle, jak by si uživatelé přáli.

Autor téhle hate-speech nejenom že předkládá ničím nepodložená fakta, ale zjevně přehlédl projekt gollvm.
Mimochodem MS Visual Studio take nestaví na GCC nebo LLVM, je psán jenom týmem Microsoftu –> taky o něm budete tvrdit že je kvůli tomu omezené a „nemůže všechny požadavky řešit tak rychle, jak by si uživatelé přáli“???

Re. "zjevně přehlédl projekt gollvm" - Nepřehlédl. Naopak beru jej jako podporu svého tvrzení. Zdá se, že i Go komunita si uvědomuje, že napsat překladač odshora dolů vlastními silami má své nevýhody. Takže ano, pokusy to napravit existují (jak do LLVM tak i do GCC), ale povšimněte si prosím poznámek typu "Gollvm is currently in development -- releases are not yet available for download" či "It compiles and passes most of the standard library test suite and a substantial portion of the gc test suite, but there are some corner cases that are known not to be handled correctly yet"

Ruby není evolucí pythonu.

Ruby je poměrně dost opajcovaná kopie jazyka Smalltalk s nějakými změnami jak se to autorovi líbilo. Pokud někdo napíše, že Ruby je evoluce Pythonu, tak jednoduše se neorientuje - a zbytek jeho příspěvku nemá nejmenší cenu číst.

Kotlin opravdu není evolucí Javy.

Go není evolucí C/C++. Typické požití Go je nahrazení velké Java aplikace spoustou malých Go microservices.

Urcite ))

Ty používáš nějaký program nebo řádkovou utilitu psanou v Go? Já jsem zatím na nic nenarazil. Zato všechny inzeráty na Go programátory jsou právě na psaní microservices.

Tak já nějaké používám, nejčastěji asi fzf ( https://github.com/junegunn/fzf ).

A také i další psané v rustu, C, pythonu, perlu, bash... ale snad žádnou malou utilitu psanou v javě.
Java je u mne spíše doménou velkých programů (např. Intellij Idea), u kterých člověk čeká velkou náročnost a nevadí pomalejší start.

docker a kubernet

Napr. hugo (generator statickych webov), syncthing (synchronizacia suborov medzi viacerymi zariadeniami), imposm (importer openstreetmap do postgresu).

Přiznám se bez obalu, že nesnáším tyto nadšenecké články. Ve slaboduchých vyvolávají mylné dojmy iluzích různých pozitivních změn(revolucí), tvz. jsou manipulativní a ti jsou pak zklamaní . Jako člověk co využívá Javu tak vyjádřím aktuální negativa u Javy :
- změna licenčních podmínek u Oracle Java
- rychlejší vydávání verzí JavySE
- pomalé vydávání oprav JavaEE např. GlassFishu ( samozřejmě vím že přešel nedávno pod Eclipse, ale když byl pod Oracle vyšli pro EE7 pouze 3x opravy - za cca 3 roky )
- katastrofální podpora multimedií v API
- nekvalitní dokumentace k API ( jako kdyby to psaly Indové, triviální věci jsou napsané pod psa ale skutečně obtížné věc jenž se často nepoužívají jsou napsané katastrofálně )

Autore odkud bereš informaci že se jedná o native-image ? Dle specifikací se jedná o JEP 220 (Modular Run-Time Images), takže se jedná o run-time image. Já osobně na to čekal od Java6 ale faktem je že to přišlo příliš pozdě, tato věc tu měla být tak na konci 90.let a nikoliv 2017. Java prakticky DESKTOP sektor prohrála a ani toto to nezmění.

https://www.graalvm.org/docs/reference-manual/aot-compilation/

I kdyby byl PÁN BŮH, specifikace je jednou standardizovaná a pojmenovaná a tím to hasne.
https://openjdk.java.net/jeps/220

Vlastní označení(pojem) může neznalé vést ke zmatenosti.

Evidentně patříš mezi hlupáčky, na které podpis pod jménem dělá DOJEM. Doporučuji nejdříve si to nastudovat, naučit, pochopit a používat vlastní mozek. Stejným způsobem tu po revoluci přišel Kožený, oháněl se titulem s Hardwardu a naivní hlupáci(jejíchž si zjevně potomek dle zákonu genetiky) z něj padaly na hubu. A pak až si uvědomily, že s nimi bylo vymrdáno bylo už pozdě.

Mě přijde že mateš ty, a to dost šíleně. native-image vytvoří z javovských zdrojáků přeloženou nativní binárku, která už nepotřebuje k běhu virtuální stroj. JEP 220 mluví o reorganizaci JRE a JDK a změně formátu JARek (které se pak asi budou jmenovat jinak). Reálná souvislost mezi native-image a JEP-220 (a tedy i článkem a tvým komentářem) je velmi nízká, snad až na to že JEP 220 počítá s tím, že by v "nových JARkách" mohlo být možné mít uložené předkompilované verze bytekódu.

Už se moc nedivím, že ti dokumentace Javy přijde špatná. Porozumění ti moc nejde.

native-image není (zatím) specifikována žádným JEPem, takže to určitě není to samé jako JEP 220. Navíc GraalVM 1.0.0 RC9 je rozšířením JDK8 - a ten JEP 220 je jen v JDK9 a více.

Tomuto ty říkáš odpověď?

Proč v tvém příspěvku NENÍ jako argument použit standard(speci­fikace JEP) která v Javě tvz. native-image definuje nebo aspoň používá ? Takto to tvou odpověď dělá pouze lichou a bezpředmětnou, kdy opakuješ fráze které ví snad každý.

Jak další argument bych akceptoval kdybys popsal tedy "správnou "definici" "run-time image". Jenže jsi tak zjevně hloupí, že ani to tě nenapadlo.

Souvislost mezi JEP220 je zásadní a to proto hned z několik důvodů :
1) že JEP220 a odkazuje se na další JEP které jsou pro to nutná (proto jsem tu dal link) - ty jsi se na žádný url odkaz ani nevzmohl
2) je součástí specifikací Modularity, stejně jako jlink a bez modularity dané řešení nefunguje. Staré projekty v jar bez module-info.java by se tedy neměli takto převést.(ovšem aktuálně to nemám otestované, neboť v betě Java9 před 2 lety kdy jsem to zkoušel to nefungovalo)

PS. a ano, skutečně jako menza jedinec mám dost často problém s porozuměním výplodů slabomyslných mozečků. Dost často totiž pletou páté přes deváté(z důvodu zmatenosti) a nic jim pořádně nefunguje, často při výzvách selhávají, mají problémy se pořádně vyjádřit( tzv. vymáčkout ), ty jsi toho přímí důkaz.
PSS. Když ti je vše jasné, a domníváš že tomu rozumíš, co ti brání nechovat je jako LÍNÝ CIGÁN a udělat na to český tutoriál. Snad jenom to, že se domníváš chybně, uvědomuješ si to a proto se bojíš to zveřejnit(jít s kůží na trh). Anebo máš pravdu, já se mýlím a můžeš nás všechny poučit. Jak říkám stačí nebýt LÍNÝ JAKO CIGÁN.
PSSS. já už si v tom několik programů( to i vč. GUI - abych si to pořádně otestoval) za poslední dva roky udělal, co ty ?

Desktop sector? Native-image ma praveze velky zmysel v cloude,kde potrebujete okamzity start sluzby - idealne ak si pamata svoj stav a po vykonani zase uspat...aspom co sa tyka resource managementu...
Viete vy vobec ako dlho trva inicializacia springoveho (spring boot) kontaineru v beznych podmienkach?

Spravne a preto ma Go native-image vyznam v micro-sluzbach...

> změna licenčních podmínek u Oracle Java

Oracle Java je primarne urcena pro platici zakazniky. Nejsi jim? Tak potom je pro tebe AdoptOpenJDK.

> - rychlejší vydávání verzí JavySE

V cem je tohle presne nevyhoda?

> Java prakticky DESKTOP sektor prohrála a ani toto to nezmění.

Souhlas. Java desktop sektor prohrala a desktop trh navic jeste umrel:))

GraalVM je pro microservices a ne pro desktop.

"jako kdyby to psaly Indové"? No ještě že to nepíšeš ty.

Glassfish mal mat odnoz Paraya, vraj je to rychlejsie opravovane. Raz som to skusal, ani mi to neslo. S Glassfish som mal vzdy nejake problemy. Jedine co mi poriadne funguvalo z volne dostupnych bol Wildfly.

K spomenutym negativam Javy by som este pridal neistotu ohladom buducnosti (kvoli Oracle) a neexistenciu normalnych funckii. Nutnost trepat vsetko do tried je velke minus Javy. Dalej je to extremna celkova narocnost a strma krivka ucenia. Onedlho nebude nik, kto by chcel do toho ist.

Co se týče budoucnosti Javy, toho bych se nebál. Osobně vkládám velké naděje do Correto což je JDK od Amazonu, který se rozhodl udržovat vlastní verzi Javy 8 ještě dalších 5 let a plně zadarmo(plus nové verze také jsou). Myslím že Oracle na svou nenažranost dojede a změna licence javy se mu vymstí. Amazon to sice dělá kvůli cloudu ale je to bezproblému použitelné pro linux desktop i mac.

Jak čtu ten článek, tak mě napadá z ufologie klasický Fermiho Paradox - "Tak kde tedy všechny jsou"?
Reálných Javovských programů (tedy ne akademických cvičení) jsem viděl pěknou řádku, některé z nich musím občas provozovat (třeba až na nenažranou Javu velmi povedené Serviio, kde ale sežere java víc paměti než ffmpeg pod tím kterej dělá online transcoding, což je ostuda, JDownloader nebo FRD, Minecraft server pro děti, pracovně pak nějaké applety v ILO nebo pár managementů) a ač se snažím sebevíc, nevzpomínám si na ani jeden jediný případ, který je svižný a nežravý.

Nevím, jak tohle vysvětlit. Třeba jazyk vede k používání krajně neoptimálních konstrukcí? Nebo je psaní efektivních programů sice možné, ale dostatečně komplikované, takže to nikdo nedělá? Netuším. Ale (pravda, ta rozšířenost není tak velká takže to není až tak fér srovnání) příklad podobného molocha v go by se asi hledal velmi těžko.

tak třeba zrovna ten Minecraft (klient) je celkem optimalizovaný. Až mě to u něj překvapilo jak je to rychlý.

(Při nastavení grafiky běží svižně i na starších strojích - testováno mým mladším bratrem.)

A tráva je zelená.
Píše o Minecraft SERVERU. Ne KLIENTU. Mezi serverem a klientem je rozdíl. Slovo rozdíl znamená, že to není totéž. Už?

Ve skutecnosti je spatnej i klient ... nastav si trochu vetsi dohled a uvidis sam. Server je na tom samo radove hur, protoze na stroj kterej udrzi 100 lidi abys nakoupil HW za 1/2M. Pokud si nekdo chce jen tak zahrat s kamosema a nema dedikovanej HW na server, tak ma problem. Protoze i7 se zapoti uz pri 2 lidech.

A to vse vyhradne a pouze proto, ze to je v jave. Coz, jak tu zaznelo, prozmenu prinasi pohodovou a snadnou modifikovatelnost ... ale vykon je proste tragickej. Coz ostatne opakovane uznal i autor.

> prinasi pohodovou a snadnou modifikovatelnost ... ale vykon je proste tragickej
Přesně vystiženy vlastnosti programování a programů v Java.

> Třeba jazyk vede k používání krajně neoptimálních konstrukcí?

Je to jen a jen můj dojem, ale snad každý kód napsaný v Javě, který jsem viděl, byl nehorázně ukecaný a rozplizlý. Občas to ve mě vyvolávalo dojem, že by autor nejraději vytvořil pár interfaců a tříd i na porovnání dvou integerů.

Když už zmiňujete ten Fermiho Paradox, tak by vás možná zajímalo i Toupée fallacy. To je pojem, který vám vysvětlí, kde všechny jsou.

https://rationalwiki.org/wiki/Toupee_fallacy

Jakoby to psal Mára. ROTFL

Ano když mám Java tým tak se budu zajímat o graalvm.
Mít ale minuty tým závaru a c++káru tak bych s novým projektem
Šel spíš do to.

ta autokorekce na mobilu.

Ano když mám Java tým tak se budu zajímat o graalvm.
Mít ale mixnuty tým javaru a c++-karu tak bych s novým projektem
sel spíš do GO.

Nepomohlo

Máš pravdu, s Jawou srovnání zcela určitě nesnese.

Díky za super článek. Koukám, že to v diskuzi bude chtít obrnit se trpělivostí proti haterům. Těším se na pokračování.

Ja teda Javu nemusim, ale pokud jste nekdy delali s Bigdata/IoT infrastrukturou, tak s prekvapenim zjistíte, ze se pouziva ve velkem (proc, to nedokazu rict). Mam na mysli projekty jako: Hadoop, Nifo, ElasticSearch, Cassandra a pod. Asi je to kvuli skalovatelnosti a moznosti pouzit odlisne architektury.­..nevim.

Ne Nifo, ale Nifi :-) od Apache foundation. Sorry za preklep

Presne a este by som doplnil, vela dodavatelov su vlastne dodavatelia hotovych rieseni tretich stran. Vzdy sa ide po cene a Java ma kopec hotovych modulov, kniznic a rieseni takze sa len nieco dolepilo a predava sa to ako hotove riesenie. Nic nezvycajne ked tool na management je vlastne Eclipse s plugin modulmi.

K tomu bych i doplnil, že nad Javou se daleko lépe (čti levněji) zajišťuje QA než s C/C++. Zajišťovat v dnešní době nad Go LTS je také problematické a v Javě nikoliv, ono se to v budoucnu možná překlopí, i v Apache Foundation jsou slyšet kritické hlasy vůči Javě, ale v současné době se jde primárně za funkcionalitou a nikoliv za výkonem.

Nedavno tu byl clanek na tema GraalVM, staci najit, nebo domovska stranka prpjektu taku funguje, pry i Google :)

Tak ve strucnosti: Nastavovat max pamet nemusis.(ale muze se hodit nekdy),Java jako jazyk zadny konkretni GC nema, Hotspot (coz je asi pro tebe ta Java) jako JVM jich zase ma nekolik, SubstrateVM ma zase jine.

Už víme, jak dlouho trvá spočítat sto prvočísel. Ale ještě by mne zajímalo, jak dlouho trvá spočítat jedno prvočíslo? Tj. jak dlouho trvá, než se ten testovací program (Java/Go) spustí a ukončí?

Dobrá otázka. Rychlost startu je totiž přesně to, v čem native-image z GraalVM vyniká!

Takže jsem nelenil a přepsal ten svůj příklad tak, aby počítal jen jedno prvočíslo. Nu a zde je výsledek:

sieve/go$ go build; time ./go
First prime is 2
One prime number in 0 ms

real    0m0.001s
user    0m0.000s
sys     0m0.000s

java/algorithm$ JAVA_HOME=/graalvm mvn clean install -Psvm -DskipTests
sieve/java/algorithm$ time ./target/sieve
First prime is 2 and took 0 ms

real    0m0.001s
user    0m0.000s
sys     0m0.000s

Tak asi tak. Nula nula nic. Prostě zkuste uvěřit, že kód vygenerovaný pomocí native-image není ta stará a pomalá Java. Je to dost dobrá náhrada v místech, kde se do teď hodilo používat Go.

PS: Omlouvám se, že jsem tento příklad neuvedl v článku. Hodil by se tam.

Ještě mne napadlo přidat to samé měření na normální JVM:

java/algorithm$ time java -jar target/sieve-algorithm-1.0-SNAPSHOT.jar
First prime is 2 and took 1 ms

real    0m0.091s
user    0m0.092s
sys     0m0.008s

Startuje to asi tak stokrát pomaleji. Jak jsem psal: nenažraný interpretovaný bumbrlíček.

Tak to jsem čekal zhruba o řád víc (tj. pomalejší), včetně toho JVM! To je pěkné. Děkuji za rychlé doplnění i za celý článek: já ho neberu jako "reklamu na Grál" - jak jinak informovat ostatní, než podobnými články?

Souhlas. Moc rád přestanu své hraní s embedded projekty v linuxu dělat v pythonu a přesunu je do javy, když bude střídmá a rychlá.

Ano, je to tak. Pokud přežijete fázi interpretování a necháte JIT kompilátor vygenerovat pořádný kód, může to být velmi rychle (minule jsem napsal rychlejší než Céčko a dost jsem to schytal, ale asi tak nějak):

sieve$ mvn -f java/algorithm/ package exec:java
Hundred thousand primes computed in 90 ms
sieve$ JAVA_HOME=/graalvm mvn -f java/algorithm/ exec:java
Hundred thousand primes computed in 84 ms
sieve$ ./c/sieve
Hundred thousand prime numbers in 98 ms
sieve$ git log | head
commit 64aed1ac16a71b193449898b5c79d97b89401f3e

Problém standardní Javy není v tom, že by její JITovaný kód nemohl být rychlý, ale v tom, že k tomu potřebuje strašně moc metadat. S native-image je kód o něco pomalejší, ale běžící proces je výrazně úspornější hlavně z pohledu spotřeby paměti.

Myslím, že srovnaní Go a Javy z hlediska vláken není vůbec na místě. Oba jazyky k nim přistupují úplně jinak. A podpora green threads je právě ta věc která je na go podstatná. A vypočet prvočísel opravdu tuto vlastnost nemůže odhalit. Malý http server a testování 10k souběžných spojení už ano.

Zajímavé. Java nemá koroutiny. Ale protože native-image pracuje s jakýmkoli JVM jazykem, tak by mělo být možné použít Kotlin. Tam koroutiny jsou. Výsledek by snad měl být podobný goroutinám (alespoň nevidím důvod, proč by to mělo dopadnout výrazně jinak), ale muselo by se to samozřejmě vyzkoušet.

No brzy snad bude https://wiki.openjdk.java.net/display/loom/Main

Bylo by možná dobré připomenout jeden z důvodů, proč se Go relativně dobře rozšířilo. Je to mj. i díky gorutinám a kanálům, jak jejich podpoře v jazyku, tak i jejich "lehkotonážnost" při použití. Co takto namísto mikrobenchmarků nahodit něco paralelního, kde se dají kanály a gorutiny použít?

Ano, na potřebu "skutečného" benčmárku jsme již také narazili. Hrál si s tím Michal, můj kolega z jiného týmu a patra. Vytvořil web-fmwks-perf-comparision, kde chce testovat reálné scénáře: HTTP, parsování JSONu, přístup do databáze, atd. Zatím je tam to HTTP.

Pomáhal jsem mu to uchodit s native-image. Bylo dost těžké Go dohnat, ale nakonec se to snad povedlo. Akorát jsem musel nahradit Netty za NanoHTTPD. Zdá se, že v Netty je příliš mnoho abstrakcí a na obyčejném Hello World příkladu to příliš zpomaluje. Po přepsání a znovu využití vláken ta Java verze přeložená native-image dokázala odpovědět na patnáct tisíc dotazů za sekundu. Asi tak stejně jako Go.

Ale zrovna HTTP server je příklad použití, kde by normální JVM po dosažení optimálního stavu (po pár tisících dotazech) zřejmě fungovala rychleji než native-image...

"Pomáhal jsem mu to uchodit s native-image"
ono to teda neni jednoduchy na pouziti?

Chtěl jsem zkusit ten native-image, rychlý start pro cli programy by byl pěkný.

$ java -version
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (build 1.8.0_192-20181024121959.buildslave.jdk8u-src-tar--b12)
GraalVM 1.0.0-rc9 (build 25.192-b12-jvmci-0.49, mixed mode)

$ cat HelloWorld.java
public class HelloWorld {
    public static void main(String[] args) throws Exception {
        System.out.println("Hello, World");
    }
}

$ javac HelloWorld.java && java HelloWorld
Hello, World

$ native-image --static -cp . HelloWorld
Build on Server(pid: 32471, port: 44227)
[helloworld:32471]    classlist:     171.66 ms
[helloworld:32471]        (cap):     103.20 ms
[helloworld:32471]        setup:     174.61 ms
fatal error: com.oracle.svm.core.util.VMError$HostedError: java.nio.charset.UnmappableCharacterException: Input length = 1
        at com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:70)
        at com.oracle.svm.hosted.c.codegen.CSourceCodeWriter.writeFile(CSourceCodeWriter.java:183)
        at com.oracle.svm.hosted.c.codegen.CSourceCodeWriter.writeFile(CSourceCodeWriter.java:160)
... zkráceno
Error: Processing image build request failed

Zdá se, že to ještě má mouchy, ale třeba jsem tomu jen nevěnoval dost času...

Děkuji za vyzkoušení. Je mi líto, že to spadlo. Můžete zadat chybu na https://github.com/oracle/graal/issues a přidat nějaké detaily, protože mně to na Kubuntu 16.04 prošlo...

Tohle se děje, když je GraalVM nainstalováno v nějakém adresáři s diakritikou. V jakém adresáři je vaše instalace?

Pokud vše funguje, jak má, tak je to jednoduché. Ale pokud se něco zadrhne, začne to být obtížnější. Například výsledný "exáč" se ladí pomocí gdb a to je při přechodu z tradiční Javy takové hodně dřevní. A tak dále.

No, mám tady na stole jednu desku. Procesor honím na 168MHz (vychází tak nejlíp časování periferek, dal by o něco víc). Má to 4x64 kiB RAM + 2x 1MB FLAH.

Mám tam ovladače pro Ethernet dělat v Javě? VM tam nedostanu ani omylem, nevím co Java přibalí z knihoven a jestli toho nebude v té binárce 0,5GB - pokud jo, nic s tím neudělám. Zaintegrovat HW pro HASH a HW crypto engine by byla ještě o level větší sranda... A nesmí to kleknout kvůli fragmentaci paměti.

A v go ten driver budeš psát? Článek není o náhradě Cčka.

Článek je o tom, že je Java použitelná i na low level věci. Tak se ptám, jestli by Java dala i takovouhle věc.
Ono totiž
- C blbě pracuje s objektama (socket atd. se jako třída přímo nabízí, takže to smrdí OOP)
- C++ má náročnou správu paměti
- Go - zatím jsem nezkoumal možnosti
- Java - viz komentáž výše. Nevím, co všechno se tam pokusí narvat

Napadá někoho jiný řešení?

Rust

> - C++ má náročnou správu paměti

I C++11 s make_ptr? Protože evoluce smart pointerů se podle mě docela povedla.

"S native-image se z Javy a ostatních JVM jazyků stávají jazyky pro vývoj nízkoúrovňových programů pro operační systémy" - uz tohle staci, takoba blbost se napise nejvice jednou za feset let, hodte na nej sit....

Vidím to úplně stejně.

Existuje vůbec nějaký jazyk který není na <> a není dávno mrtvý či brzo nebude?

Tak ten byl dobrej :D :D :D

Přece malbolge: https://cs.wikipedia.org/wiki/Malbolge

Ok, ted vážně. Chceš jeden jazyk na všechno?
C++ 17 je dobře použitelné. Rust je dobře použitelný.

Python i přes všechny jeho pitomosti používám sám velmi často, protože se mi hodí.

@/dev/iant

Nechci jazyk na všechno. Ona ta poznámka byla napůl sarkasmus nad tím, jak se v podstatě každá diskuze o jazyku zvrhne na naprostý řev o zrůdosti ... neznám jazyk pod kterým by to tu nebylo - zapoměl jsem tam dát hashtag #half_sarkasm ....

Ano jazyk D, teda az na to ze nikdy nebyl zivy a asi nebude ale misto <> pouziva ! coz ho kvalifikuje :P

Myslím, že to s Javou v pohodě doklepu až do důchodu a ještě budu s úsměvem vzpomínat na všechny ty nové, lepší a rychlejší jazyky s jepičím životem co jí měly v průběhu těch let nahradit. :-D

Jedna formální poznámka:

Proč je v článku kolem 10 odkazů na native-image, která vede na dvě věty?

1) Nešlo by se držet praxe třeba z Wikipedie, kdy se odkazuje pouze při prvním výskytu výrazu? Taklhe to vypadá jako špatně udělaný SEO článek.
A u člověka se střídá stav očekávání, že konečně bude nějaký lepší odkaz, se stavem zklamání, že je to pořád ten stejný,
2) Opravdu neexistuje lepší zdroj?

Jinak receno problem je v tom, ze autor je Java fanboy a neni Go fanboy ?:-D

ne, problem je manipulativnost clanku a argumentovanie, ktore je len jednosmerne.

Javu jsem zavrhl kvůli
- alchymii statických a dynamických objektů (které spolu nemohou kooperovat, jak by bylo potřeba),
- totálně nepřehledné a nelogické syntaxi
- a naprosto šílené dokumentaci.
K tomu poslednímu: Člověk by potřeboval vědět něco ve smyslu "třída ta a ta má ty a ty metody, metoda A má ty a ty argumenty a dělá s nimi to a to a pro ty argumenty jsou nastaveny (při jejich nezadání) ty a ty implicitní hodnoty". Dolovat tento údaj z oficiální dokumentace, představující z 99% slovní salát a jen asi jediné procento smysluplné informace mě opravdu nebavilo.

S blbou syntaxí souhlasím, ale nerozumím, co ti vadí na té dokumentaci. Když náhodou kliknu třeba na dokumentaci ConcurrentHashMap

https://docs.oracle.com/javase/7/docs/api/

co v té dokumentaci není přesně tak, jak popisuješ, že by se ti líbilo? Je tam seznam metod třídy, u každé metody se píše k čemu slouží parametry, a že java umí nezadané argumenty ani nevím. A slovního salátu jsem si moc nevšiml, v popisu třídy jsou podle mě dost relevantní věci.

Pardon, ta dokumentace k ConcurrentHashMap je zde: https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ConcurrentHashMap.html

WTF? :( Toto nie je dokumentacia toto vyzera ako 5. diel Война и мир od Tolstoja.
Mna ucili ze programovanie je o kompozicii malych jednotiek do vacsich celkov. Zdoraznujem "malych". A teraz pozeram do kodu... trieda ConcurrentHashMap ma vyse 6000 riadkov! SRSLY ?!?!?!? :(

1) Toto je dokumentace, a řekl bych, že má všechny vlastnosti, o kterých původní tazatel tvrdil, že tam chybí. To, že je dlouhá, souvisí s tím, že toho ConcurrentHashMap umí hodně a jsou to netriviální věci. Kdyby byla tato dokumentace krátká, OP by nadával, že není zdokumentované všechno. Nadávat, že rozsáhlá věc má rozsáhlou dokumentaci, mi přijde takový.. no asi si dovedeš domyslet.

2) Obecně s poučkou souhlasím, ale ConcurrentHashMap mi přijde jako dost atomická věc. Ale rád se nechám poučit. Jak by jsi dekomponoval funkcionalitu ConcurrentHashMap do menších jednotek? Jsem velmi zvědavý.

Pockej az jednou uvidis zdrojaky jadra:))

ty si dobry amater

objekt - je instancia triedy. Staticky/dynamicky objekt - to si kde cital? Niekde v referate nejakeho stredoskolaka, ktory nieco skopiroval z wiki a ani sam nevie o com pisal? Prosimta, ja som uz som programoval kdeco, ale nikdy som nemusel riesit nejake dynamicke/staticke objekty ale iba objekty.

A keby si vedel aspon zaklady objektoveho programovanie tak by si mohol vediet, ze rozhranie netvoria iba metody, argumenty, triedy ale ze maju aj svoje stavy a svoje spravanie - to je ten salat co k tomu potrebujes vies. Lebo bez toho nemozes ani len tusit, co sposoby spustenie jednej metody. myslis ze Object.clone() to len tak nakolonuje objekt lebo sa vola clone a netreba ti poznat teoriu za tym?

A co multiparalelne prostredie na serveri ty macher? Kodil si uz aj nieco ine ako jednudchy konzolovu appku s jednym vlaknom? Naco ti bude nazov metody, ak nevies ci je thread safe? A co rozne factories a buildery v multivlaknovom rpostredi? Takym ako ty dat nakodit serverovu appku, tak ak by to bola banka asi vsetci ludia pridu o svoje uspory.

S tvojim pristupom, staci pozriet na zdrvojaky Linux kernela - tamen subor ma take a take funkcie a hned ovladas cely kernel do podrobna.

Nelogicka syntax - uplne najlogickejsia - ved vychadza z Ccka. To si este nezazil asi funcionalny pristup v Java 8 a funkcionalne programovanie v JavaScripte alebo moderne jazyky ako Ruby. Uz radsej ani nehovorim o C++ ktoreho syntax ti umoznuje spravit uplne vsetko preto je oproti Jave sialna, pretoze Java syntax je zuzena na objektove programovanie. Mimochodom pointre a nieco medzi pointrom a referenciou mas uz aj v C# a kvoli prehladnosti to asi nebude.

Tohle má být nějaký pokus o reklamu na apidesign.org (web od autora článku)?

Practical API Design je dobrá knížka. Sám si v ní občas rád zalistuji.

K těm odkazům. Články píši v MediaWiki a používám odkazy na ostatní wiki stránky. Tak je napsána původní anglická verze Forget Go. Go, Java go!. Při přepisu do češtiny jsem tam ty odkazy nechal. Potěšilo mne, že je tam redakce nechala také a že se dostaly až na Root. Je to hezká reklama, ale nelpím na nich.

Tak zkusil to. :-)

Java je největší zlo ... z pohledu systémáka tohle platilo před 10ti lety a platí to i dneska.

Souhlad instaloval jsem SAP na HP-UX a bylo to o tom, že jedna část vyžadovala 1.4.1 a jiná verzi 1.4.2, atd. O nenažranosti na paměť nemluvně. Dodnes musím virtuál s CentOS5, starou Javou a Firefoxem, abych mohl přistupovat na KVM do serverovny... Nekompatibilní Java od Sunu a Microsoftu a pod. Se divim, že Java kompletně neumřela a stala se COBOLem dnešní doby...

Taky se divim co je to za systemaka, ktery netusi jak provozovat vice aplikaci vyzadujicich ruzne java verze na jednom stroji... mel jsem pocit ze tohle se uci i ve skolce po myti rukou, ale patrne ne vsude...

No jasne, co na tom nechapes ?:-D

Stejne tak jako Java 1.4, rok vydani 2002 pokud me pamet neklame, je velice vypovidajici o dnesni Jave :-)
A to ani nemluve o tech problemech s applety, protoze to neni vubec tak 10 let nejmin mrtva technologie :-)

Jop, Applety, to je presne aktualni vec dnesni Javy :-)

Pripravit prostredi pro prasata, jako je Software Aus Pakistan nebo IBM (prozmenu vesmes z Indie) je naopak s Jawou pro systemaka uloha prajednoducha.

Staci rozzipovat JRE ve verzi, se kterou SAP/IBM style zprasek cirou nahodou jede a nastavit $JAVA_HOME - problem solved.
V pripade appletu je nutno si drzet cele stare image s browserem, kde to nahodou jede, SAP/IBM style prasata dokazou v Jave neuveritelne veci, treba dokazou zcela zamerne vyuzivat znamou chybu ve stare JVM nebo vyrobit v Jawe memory leak, jsou hodne dobri.
Termin "Deprecated" znamena po indicku "per to tam".

Systemak, ktery ma problem rozjet java program musi byt opravdu pripad, naopak poradne peklo dokaze pripravit bare OS, HP UX fixne deravou knihovnu, soft se seype a delat s tim nejde nic. Bezne jsem potkaval pripady, kdy na jednom stroji jel soft jenom s knihovnou verze 1.0 a jiny soft jenom s verzi 1.1. Prakticky neresitelne, v jave trivialita rozbaleni jednoho zipu a $JAVA_HOME

Problem nativneho prekladu javy je hlavne v tom, ze vseci radi generuju/stahuju bytekod. GCJ malo v sebe koli tomu interpreter a cele to nestalo za nic.

Samozrejme, ide to aj bez toho (android), ale velke riesenia (spring) sa bez toho nepohmu, nie ze by sa nedali prerobit (na annoation procesory/reflec­tion/java.lan­g.reflect.Pro­xy), ale znizuje to hodnotu existujuceho ekosystemu.

No ale Spring prafe tu reflection / reflect.Proxy pouziva :-) Diky cemuz bylo mozne tohle:

https://jira.spring.io/browse/SPR-16991

Samozrejme, je to jen pocatek podpory, ale nevypada to jako nic neresitelneho.
A obecne prechod k annotation procesorum je urcite vhodny i z mnoha jinych duvodu.

Obecně záleží na tom, jak se různé variace (Javy) ujmou. Android byl z počátku nekompatibilní s kde čím, ale díky jeho popularitě jej mnoho knihoven začalo podporovat. Což zřejmě vyžadovalo změny v kódu speciálně pro Android. S native-image je to podobné. Funguje to trochu jinak, ale zdá se to být užitečné. Budou-li si to myslet tvůrci knihoven a frameworků, tak se do pár let přizpůsobí.

Znáte Micronaut? Tam se pánové dost snaží a mají i speciální mód pro podporu GraalVM. Nedávno jsem zahlédl, že mají i podporu hlavních anotací ze Springu. Zkuste to. Jestli odvedli dobrou práci, tak to bude fungovat téměř samo.

bolo by fajn keby sa tu nevyjadrovali kinder- programatory a "seniory" ktorych seniorita spociva akurat v tom, ze 20 rokov bastlia kod pre jeden korporat na jednej stolicke a nepresli si desiatkami technologii

mudrlanti - piseste tu o .NET Core a ani neviete o com to je ... kazdy architekt by Vas vysmial, ze ako architekti zlyhavate a maximalne kvakate ako programatory ktory vidia len po svoj nos a kazdy silou mocou presadzuje len tie svoje naoblubenejsie technologie nevidiac aky a ci vobec maju z pohladu architektury prinos - a pre "pravovernych" Linuxakov - myslim skutocnu softverovy architekturu a nie to, ako spojit zopar Linux strojov cez siet a nainstalovat tam podporny softver

nechapem ako moze niekto napisat: ".Net Core je cool" a potom "jasne ze trpi syndromom novej technologie"

preto ju Java EE pretoze nim netrpi a kto chce najnovsie cool vychytavky tak pouzije Spring, ktory dokaze zavadzat novsie technologie ako EE a stale ostat co najviac bez toho aby trpel syndroom novej technologie

ak chcete technologiu so syndromom novej technoloigie - vykaslite na sa .Net Core - pouzite Ruby on The Rails - toto je daleko daleko daleko (uz minimalne 5 rokov) pred .Net-om aj pred Javou, akurat - trpi syndromom novej technologie, ale oproti Railsom je cely .Net brutalny overkill .... bolo by fajn, keby sa tu prestali vyjadrovat decka, ktory o technologiach nic nevedia ..... a hlvne - nezacnite argumentovat rychlostou kompilovanych aplikacie pokial nie ste architekti ktory sa staraju o portfolio 10 aplikacii s vysokoou dostupnostou a vysokou skalovatelnostou a vyskym loadom ktore pouzivaju nie miliony ale desiatky milionov pouzivatelov z celej Europy

takze este raz pre vsetkych kinder zastancov .Net - chcete technologiu ktora trpi syndromom novej technologie - vykaslite sa na .Net, pouzite Rails, alebo Node.js ... ale kludne aj PHP Symfony - tie vase web appky kde v jednom case prihlaseny jeden uzivatel pobezia rovnako rychlo aj v tychto ovela jednoduchsich technologiach ... .Net Core a serverovu Javu prenechajte profikom, ty uz budu vediet zvazit, ktora ma ake vyhody/ nevyhody a v akom prostredi je ktora viac prinosom

> preto ju Java EE

Uz neni :-D

Nebaví mne chodit na čistě Java konference, kde všichni věří, že Java je to pravé. Tam už se nic nového nedozvím. Na Rootu je skvělé, že tak polovina čtenářů Javu moc ráda nemá. Občas je to drsnější, ale najdou se tu i skvělá pozorování. Zatím si diskuzi užívám.

Takový článek patří spíš na živě

celkove vzato:
- clanek psal fanda do javy, ktery se snazi jakkoliv argumentovat pro Javu a proti cemukoliv
- je tady hodne silna zakladna javistu, kteri jakoukoliv kritiku, ci negativni nazor na Javu, 'odmenuji' minuskovanim

chapu to, akceptuji jejich nazor, ale ... proste maji svoje kladivo a ve vsem hledaji ty slavne hrebiky.

zpocatku jsem to bral jako formu recese :)

Dalsi obet koroporatniho vymejvani mozku, az to uz neni ani vtipne.

Posledne nam jisty Svedek Oracluv s podobne zaslepenym nadsenim cpal Truffle Ruby. Nebudu napinat, nechali jsme to dojit az tak daleko, ze se na nem pustily integracni testy a dopadlo to katastrofalne. Jednak vykonnostne a spotrebou pameti a nektery ani regulerne nedobehly. Pad s behovou chybou, rucni sestreleni pri neukonceni ani po vic nez dvojnasobne dobe behu. Pritom bez problemu bezi nad JRuby i CRuby.

Mozna to casem vychytaji, ale nemeli s tim prijit v takovem pre-alfa stavu. Znovu to ale pokouset uz nebudeme.

Je mi lito, ale clanek je ryzi demagogie.
Snazi se postavit argument, ze hlavni hype go je jeho rychlost a moznost staticke kompilace.

Ve skutecnosti hlavni vyhodou go oproti jave je, ze je to proste lepsi jazyk. I kdyby bylo 5x pomalejsi, porad stoji za to.
Pochopil bych, kdyby se autor snazil srovnat go treba s kotlinem, ale java je opravdu mimo.

Go je trivialni jazyk (syntakticky jednodussi nez cecko), coz vam umoznuje prijit defacto k jakemukoliv projektu a okamzite vidite, co se deje. Nepouzivaji se zadne silene frameworky, zadne builder patterny. Zadne desitky trid a interfacu jen proto, ze nekdo v nejake knize napsal ze to tak ma byt.

V go mate moznost predavat hodnoty ...hmm...hodnotou. Ze zacatku to cloveku uplne nedojde, ale vlastne to supluje imutabilitu, protoze volana funkce nema sanci zmenit strukturu(aka tridu), kterou si drzi volajici. Zaroven to umoznuje kompilatoru drzet si hodnotu na stacku a tim omezit garbage.
Nemusite resit null pointery.
Ne vazne, kolik jste v zivote videl zbytecneho kodu a padu programu kvuli null pointerum? Kolik nevysvetlitelnych chovani programu, protoze nekde nejaka funkce zmenila neco v objektu co dostala, co menit nemela? Kolik popasnych stranek vymyslejicich, jak udelat objekt immutable, jen proto, ze samotny jazyk na neco takoveho nepamatuje?