Nim vs Crystal vs Go

Czy może ktoś podać jakiś benchmark z tymi językami programowania, aby sprawdzić który z nich jest wydajniejszy? Wszystkie są kompilowane, chyba nie mają wskaźników ale mają odśmiecanie pamięci.
https://nim-lang.org/
https://crystal-lang.org/

Z uwagi na to ze Nim kompiluje sie do C zalozylbym ze przy zadaniach bez dynamicznej alokacji bedzie wygrywac Nim.

Natomiast jesli chodzi o GC to juz raczej dwa pozostale. Ale nie mam i nie znam na to benchmarkow.

@vpiotr: AFAIK nie da się używać Nim bez GC, więc nie ma to znaczenia.

@tedy wszystkie te języki mają wskaźniki, ale nie mają arytmetyki wskaźników (GC w końcu działa tylko na dynamicznie alokowanej pamięci, więc musisz mieć jakiś wskaźnik na nią). Co do pytania w temacie, to szybszy w jakich zastosowaniach? Czy do szybkości wliczasz czas developmentu albo refactoringu? Jaki program chcesz napisać? Czy znasz którykolwiek z tych języków lub ich "języki rodziców" (Python w przypadku Nim i Ruby w przypadku Crystal).

Jeśli chodzi nowe języki programowania oraz niszowe języki programowania to w tym zestawieniu tylko Rust dogania C i C++, a Go jest niesamowice wolny. Wolniejszy nawet od Javy w której na co dzień programuję.

IMO to nie ma znaczenia, bo często to algorytmy są wolne a nie języki programowania. Do czego potrzebny jest Ci ten benchmark? Pod jakim kątem? Poza tym np sieć potrafi tak spowolnić, że to będzie obojętne co chodzi pod maską. No chyba, że piszesz coś baaardzo niskopoziomowego, to wybiera się język pod usecase. Bez szerszego kontekstu ciężko powiedzieć.

Uczę się dopiero C i chciałem tworzyć programy okienkowe. Na razie wybrałem C potem nauczę się GTK3. Ale interesuje mnie drugi język programowania, który jest prostszy od C, ma czytelną składnie, jest bardziej nowoczesny, czyli posiada GC, brak wskaźników, mniejsze problemy z wyciekami pamięci, jest kompilowany, brak nullów i ma statyczne typowanie. Języki skryptowe mnie nie interesują. A do maszyn wirtualnych jvm. clr jakoś nie mam przekonania, zawsze te programy desktopowe działały wolno.

A do maszyn wirtualnych jvm. clr jakoś nie mam przekonania, zawsze te programy desktopowe działały wolno.

Scala ma wersję Native https://github.com/scala-native/scala-native podobnie jak Kotlin, ale jest narzędzie, które potrafi przekompilować już istniejące projekty Javowe, Scalowe, Kotlinowe, Clojurowe, etc do samodzielnego pliku wykonywalnego. Jest to native-image z GraalVM.
Instrukcja użycia native-image: https://www.graalvm.org/docs/reference-manual/aot-compilation/
Reszta dokumentacji: https://www.graalvm.org/
Repo GraalVM na GitHubie: https://github.com/oracle/graal

Szybkość takiej Javy skompilowanej AOT (ahead-of-time w przeciwieństwie do JIT = just-in-time) jest niestety obecnie sporo niższa niż zJITowanej: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-substratevm.html jednak AOT znacznie przyspiesza uruchamianie programów, np tutaj koleś skompilował Javowego klienta HTTP i ten staruje szybciej niż cURL: https://sites.google.com/a/athaydes.com/renato-athaydes/posts/a7mbnative-imagejavaappthatrunsin30msandusesonly4mbofram

Scala-Native już teraz osiąga wysoką wydajność, porównywalną z rozgrzaną JVMką: https://github.com/scala-native/scala-native/releases/tag/v0.4.0-M2 a przebija ją mocno w czasie uruchamiania (Scala-Native nie potrzebuje JITa oczywiście). Za jakiś czas (kilka lat?) GraalVM AOT powinien dogonić Scala-Native będąc jednocześnie dużo bardziej uniwersalnym (Scala-Native nie obsługuje zwykłych JARów). Oracle mocno w Graala inwestuje.

Jesli GUI jest Twoim celem to sprobuj:

• Free Pascal plus Lazarus
• C++ i Qt lub wxWidgets
• Java plus Swing i Netbeans

@tedy: odpowiadam na komentarz, bo nie chce schodzić z merytoryką do komentarzy gdzie miejsce offtopu.

Pascal czy Lazarus a może nawet Delphi zupełnie nie jest tym samym co C. Niemniej też bym nie szedł w tym kierunku, bo Embarcadero to troll licencyjny i trzeba bulić ciężkie pieniądze za nie do końca dopracowane narzędzia (Delphi), a Lazarus nie nadaje się do użycia produkcyjnego (mimo, że są tutaj zapaleńcy co walczą dzielnie i tworzą w tym soft, ale to wszystko hobbystycznie, niszowo). Warto liznąć C++, ale nie nauczysz się go łatwo i mało kto tak na prawdę go potrafi. Ja bym polecił Tobie C# - jest multiplatformowe, no poza tym, że GUI to jedynie dobre na Windows a GUI multiplatformowe jeszcze w powijakach (Avalonia UI), lub Jave. Jeśli masz złe doświadczenia to z programem danych a nie z jvm czy clr - dobrze napisany soft działa szybko i wcale nie tak łatwo zepsuć mu wydajność. Sam używając C# pisałem systemy real time i serio się da i obecnie rozbudowane programy będą działały szybciej niż kompilowane, szczególnie jeśli kod pisze początkujący.

Z takich waznych rzeczy pamietaj ze ani nim ani crystal nie sa jeszcze w stabilnych wersjach. Jesli juz celujesz w cos "niszowego" to proponuje RUST'a lub właśnie Golang'a (chociaż sam jestem zhajpowany na nim'a ale raczej wole nie pisać czegoś co ma trafić na produkcję w rozwiązaniu które nie jest jeszcze w wersji stabilnej)

Mój kolega programista Javy mówi do mnie, że wypadałoby się w końcu nauczyć C++ bo wypada go znać. Skoro on go nie umie, a zawodowo programuje w Javie przeszło 20 lat to raczej nie biorę się za C++.

To taki trochę dziwny argument - skoro jest programistą Javy to żadna niespodzianka, że nie musiał nigdy uczyć C++. Skoro zaś sam nie chcesz zostać Javowcem, tylko zdryfować w jakieś kompletne odmienne rejony z programowaniem aplikacji okienkowych, to nie wiem czemu tak bardzo się inspirujesz tym co on robił albo i nie robił. Qt/wxWidgets to solidne biblioteki.

Wybieranie języka po wydajności to jeden z głupszych pomysłów - zwłaszcza jeśli człowiek się uczy.
Generalnie jak jeden jezyk nie jest 10 razy wolniejszy od drugiego to zwykle spokojnie da się zastąpić.
Warto raczej zaczynac od języków wyższego poziomu, a potem jesli potrzeba spojrzeć w dół bagna.

Jak chcesz tworzyć reponsywne programyu okienkowe to umiejetności programistyczne są dużo ważniejsze od jezyka.

Jezyki statycznie kompilowane wcale nie są by default szybsze od tych na VM - na razie różne vmki są średnie, ale formalnie VMki powinny być szybsze od statycznej kompilacji - w koncu są w stanie zoptymalizowac dużo wiecej, bo wiecej wiedzą o kodzie. Fakt,na razie tak bywa dość rzadko. Słabości VM to zużycie pamięci, które praktycznie zawsze będzie większe od native.
GC może czasem powodować, że program jest szybszy dla użytkownika niz ten z ręcznym odśmiecaniem.

Z tej całej listy to Crystal wygląda najciekawiej. Nim nie znam, ale wygląda jak python dla laika. Go mnie rozczarował (rozjazd hype z rzeczywistością, to nie jest zły język, ale niektórzy ludzie krzyczeli, że wyprze javę... - chyba tylko na zasadzie, że język gorszy może być wyparty przez jeszcze gorszy :-) ).

Ale tak szczerze, jak chcesz robić okienka, to najpierw pytanie jaki rodzaj okienek, a potem wybierz coś w czym te okienka się robi wygodnie i będziesz miał przykłady.
Jak chcesz drugi jezyk inny niż C to polecam:

• javę ze względu na tony przykładów i okienka i IMO lepiej wziąć starego Swinga niż javafx (wiecej przykładów),
• kotlin - bo to ciekawy i prosty jezyk ze zwięzła składnią (i okienka na JVM możesz robić),
• haskell - bo najciekawszy i IMO najbardziej przyszłościowy - ale w tym okienek nigdy nie robiłem i nie widziałem,
  (btw. nie sądze, że w przysżłości bedziemy programować w Haskellu, ale nowsze jezyki coraz bardziej się haskelizują i tworzone sa ciekawe jezyki na bazie haskella (Idris, purescrupt, elm). A Scala nadal rżnie z haskella :-).

Książka The Go Programming Language jest ok + na ich stronie jest pełno tego: faq, effective go no i specyfikacja. Tak na start pewnie wystarczy :D Kursy video nie dla mnie, więc sie nie wypowiem. Co do wychwalania golanga to akurat opiniami devów z googla bym się nie sugerował za bardzo

• w tym wpisie, który podałeś nie ma ani jednego argumentu za Go ._. jedynie narzekanie o oraclowych jdk

https://przemelek.blogspot.com/2018/10/czas-porzucic-javae.html

Pffff. Gość napisał mniej więcej: nie umiem zainstalować Javy, więc przerzucę się na Go. No ludzie, trzymajcie mnie. Jak ktoś zbuduje Javę z oficjalnych źródeł to to jest Java, a nie jakieś UFO, więc można instalować. Zresztą zajrzałem głębiej do blogasa tego kolesia i wychodzi na to, że dalej programuje w Javie, a do Go nie wraca mimo iż pisał o nim w 2011 roku.

ja ogólnie to zgadzam się ze zdaniem @jarekr000000. Język powinno się wybierać pod konkretny case + jak łatwo jest mi wejść w tę technologię. Nie na odwrót. Lubię Go, ale okienek bym w nim nie pisał :)