Jaki nowy język programowania wybrać?

A nie lepiej mikroserwisy i szybciej napisać w Django, Ror, Node.js czy PHP7 i jakimś frameworku.

Pijany Szczur napisał(a):

A nie lepiej mikroserwisy i szybciej napisać w Django, Ror, Node.js czy PHP7 i jakimś frameworku.

Szczerze to według mnie jedną z najszybszych opcji jest... Spring Boot.

A co to są te mikroserwisy (micoservices)? Bo chyba nie chodzi o małe, niewielkie serwisy? ;)

O https://www.scala-js.org/ wiem tyle co nic, ale czytałem że jeśli chodzi o języki które są "przerabiane" na JS, to CoffeSctipt i TypeScript robią się coraz bardziej popularne.

Weź coś popularnego zamiast cudować.

@spartanPAGE - no shit sherlock.

@spartanPAGE no i?
Pisalem o szybkosci i wygodzie, malej ilosci konfiguracji i latwym testowaniu.
A samo rozwiazanie tez ma oczywiscie wady. W ogolnym rozrachunku sa lepsze rozwiazania. Nawet w samej javie. I glownie o javie mowi sie w kontekscie mikroserwisow. Ale spring boota tez mozna pooptymalizowac.

A porownywany byl z php, node.js czy railsami. One moze wad nie maja?

O https://www.scala-js.org/ wiem tyle co nic, ale czytałem że jeśli chodzi o języki które są "przerabiane" na JS, to CoffeSctipt i TypeScript robią się coraz bardziej popularne.

W CoffeeScript czy TypeScript się backendu nie pisze. Dzięki scala-js można pisać w Scali zarówno backend jak i frontend, zachowując silny system typów w obu przypadkach.

Jakoś pisałem strony www pod kątem front endu i wydaje mi się to dość nudne zajęcie. Tak wiec jeśli dobrze rozumiem to aktualnie najlepiej stawiać na web i tworzenie w nim aplikacji bo i tak prędzej czy pózniej wszystko zostanie do niego przeniesione?? Wtedy nauka rusta miała by małe znaczenie bo lepiej wybrać go lub elixir z tych co mnie interesują lub ewentualnie zastanowić się nad scalą która została wyżej wspomniana.Jak to jest??

@kornelgora desktop nie umrze ale bedzie tego coraz mniej. Przegladarki maja ograniczenia. Backend w web jest ciekawy, milosnicy frontu tez maja duzo wyzwan. Technologii i pracy mnostwo.

Ogolnie Cie nie rozumiem. Nie masz doswiadczenia a probujesz wybrac niszowe jezyki o ktorych pewnie tez nie masz pojecia. Bedzie trudno o pomoc w takim rust czy elixir.

Naucz sie czegos popularnego, javy czy c#. Pozniej bedzie Ci lawtwiej przy rzadkich jezykach.

Masz dziwne uprzedzenia.

c# odpada bo na windowsa poza tym swego czasu w nim nawet sporo pisałem , to samo z java tez uczyłem sie swego czasu ale nie odpowiada mi kompletnie .Długo by wymieniać dlaczego.Wiec na pewno w te języki programowania nie pójde. Moim celem jest pisac aplikacje na desktopy lub aplikacje które bedą obsługiwane w chmurze.Nie chce się bawić przy tworzeniu stron internetowych czy robienia do nich backendu .Chce po prostu móc robić aplikacje jakie tylko sobie wymyśle.Dlatego mocno się zastanawiam jaki język i co będzie najbardziej odpowiednie.Z tąd przejrzałem neta i wybrałem języki programowania które mnie zainteresowały.Rust,go,elixir to bardzo ciekawie zapowiadające się języki w które chętnie bym poszedł.Dlatego chce wybrac jeden z nich który najbardziej odpowiedni będzie do moich zastosowaniach i go się uczyć.

No to jak chcesz na desktopa pisać to C++ w standardzie 11, 14 lub 17 i do tego QT 5.7. Możesz też C i GTK3, są jakieś kompilowane języki jeszcze jak Rust, D no i Vala od RedHata. Możesz też Python z QT jak Ci nie zależy na szybkości i wydajności programów. Miałem gdzieś taki benchmark porównanie szybkości języków kompilowanych względem Javy i C# i pod desktopem C, C++, Rust i D sporo zostawiały w tyle te dwa pierwsze. Jak znajdę to podam ten benchamrk.

Chce po prostu móc robić aplikacje jakie tylko sobie wymyśle

W domu możesz klepać w czym chcesz i co chcesz. W firmie to nie ty będziesz miał decydujący głos w sprawie stosu technologicznego. Będziesz musiał się dostosować.

Jak pójdziesz do roboty to będziesz miał zderzenie z rzeczywistością i szok nie mniejszy niż u mnie. Zamiast się jakoś napalać na cudaczne rozwiązania, sprawdź jakie są trendy na rynku i wybierz coś co wygląda ciekawie.

Co w tym desktopie się robi co cię tak interesuje? Podaj przykłady programów i technologie w których zostały wykonane.

Miałem gdzieś taki benchmark porównanie szybkości języków kompilowanych względem Javy i C# i pod desktopem C, C++, Rust i D sporo zostawiały w tyle te dwa pierwsze. Jak znajdę to podam ten benchamrk.

Pewien popularny benchmark jest tutaj: http://benchmarksgame.alioth.debian.org/
Wnioski z benchmarka są takie:

• wiele programów używa funkcji wbudowanych napisanych w językach natywnych, np Pythonowe programy korzystają z wbudowanych struktur danych, a interpreter ma napisane w C funkcje do ich obsługi - z tego powodu używając tych funkcji nie mierzymy szybkości czystego Pythona, a szybkość wbudowanych operacji,
• mimo powyższego i tak są duże różnice między językami,
• Java jest ze 2 - 3 razy wolniejsza od C,
• Erlang jest z 5 razy wolniejszy od Javy,
• Python jest ze 2 -3 razy wolniejszy od Erlanga,

Elixir bazuje na ErlangVM, więc będzie miał prawdopodobnie podobną prędkość.

@kornelgora gadasz glupoty. To NIE sa jakies tam stronki...

A ogolnie mysle, ze najlepiej jakbys poszedl w mobilne.

A na poczatek najlepiej jakbys cokolwiek powaznego napisal.
Bo szczerze watpie zebys napisal cos poza projektami w stylu studentow.

Bardzo mnie ciekawia te Twoje aplikacje w chmurze. W czym to chciales napisac?

Powoli jestem coraz bardziej przekonany aby nie upierać się przy desktopach. Dlatego coraz bardziej myśle o tym aby pisac aplikacje webowe.Jakie aplikacje to w webie jestem w stanie napisać??Jaki język najlepszy do takich zastosowań jeśli tym chciał się zająć??

Python, Node.js, Ruby, PHP i ich frameworki. No i te korporacyjne kobyły.

Nie zaczynaj od javascriptu.

Wybierz na poczatek c# dot.net lub jave spring\java ee. Materialow do nauki masa, duze community, wiele standardow, szybko zalapiesz dobre podstawy.

Ale jak ktos lubi desktopa to moim zdaniem ios albo android sa warte sprawdzenia.

No ale autor Ci napisał że nie chce pod Windowsa tylko bo woli pod Linux, ewentualnie multi platformowe rozwiązanie. Rider od Jetbrains jeszcze nie wyszedł, a pisanie w C# pod Monodevelop nie dość że jest uciążliwe i marnie się przenosi, to programy po skompilowaniu są dwa razy większe niż ich windowsowe odpowiedniki. Samo Visualstudio core jest pod web na Linuskie, Xamarin jest pod Apple. Nie ma szans aby na dzień dzisiejszy pisać sprawnie w C# pod Linux, jest niby Unity 3D, do tego wszystkie książki, poradniki, tutoriale skierowane są pod Windows, i większe projekty do których dodawane są składniki Windows będa pluć błędami pod Monodevelop, a ty będziesz się wkurzał, czemu to nie działa jak tam w książce. To samo było na początku z C++ gdy prawie wszystkie książki, tutoriale, kursy były skierowane na Windows. Nawet potem pan Grębosz dodawał dwie wersje kodów pod openSUSE i KDevelop w swojej symfonii standard.

A nie widzisz, że tak naprawde autor nie wie czego chce tylko się coś mu wydaje?
Jak nie c# to java.

kornelgora napisał(a):

Powoli jestem coraz bardziej przekonany aby nie upierać się przy desktopach. Dlatego coraz bardziej myśle o tym aby pisac aplikacje webowe.Jakie aplikacje to w webie jestem w stanie napisać??Jaki język najlepszy do takich zastosowań jeśli tym chciał się zająć??

Aplikacje biznesowe to aplikacje typu klient-serwer. Jest wielu klientów i muszą oni ze sobą współpracować, więc muszą na bieżąco widzieć zmiany dokonane przez innych. Dodatkowo trzeba się integrować z innymi usługami, np systemem, który dostarcza zamówienia, czy systemem, który odbiera zamówienia. Wszystko musi się dziać jednocześnie, nie może być takiej sytuacji, że np strona webowa działa w tych godzinach, integracja z jakimś tam jednym serwerem zewnętrznym w innych godzinach, z kolejnym serwerem w jeszcze innych, generowanie raportów w jeszcze innych, itd

Ja polecam jeszcze raz Scalę, bo tutaj trend jest taki, że w zasadzie unika się kobył. Niby są rozbudowane biblioteki jak Akka, ale to i tak jest lekkie w porównaniu do kontenera JavyEE.

Proponuję taki stos:

• Scala i Akka jako podstawa,
• Slick jako warstwa dostępu do bazy danych (a sama baza to może być np Postgres),
• Gatling jako narzędzie do testów wydajnościowych,
• frontend przy użyciu SPA (single page application), a więc do gry wchodzi Angular, React lub coś podobnego,
• by uniknąć grzebania w JavaScripcie można skierować się w stronę scala-js i bindingów do Reacta: https://github.com/japgolly/scalajs-react
• frontend i backend spięte RESTem wystawionym za pomocą akka-http,
• Google Guice do wstrzykiwania zależności w backendzie o ile zajdzie taka potrzeba (bo wcale nie musi w małych projektach),
• hosting dla hobbystycznych aplikacji na OpenShift,

Zacznij od tego jakiego rodzaju soft chcesz programować? (biznesowy, finansowy, naukowy, rozrywkowy, middleware, systemowy...)
Dla kogo chcesz programować? (dla pracodawcy, charytatywnie, czy dla siebie)
Czy chcesz się uczyć całe życie? (T/N)
Potem zdecyduj się na platformę (wg wielkości: embedded, mobile, PC, midrange/mainframe, HPC)
Potem wybierz język dominujący na danej platformie.

Po dwóch-trzech latach możesz zastanowić się ponownie. Jeśli nie pracujesz to nawet po paru miesiącach.

Wibowit jak ktoś nie zna w ogóle Javy to polecasz Scala od razu? A na Androida ponoć lepszy i bardziej używany Kotlin niż Scala zaraz po Javie.

Programując w Scali będziesz i tak musiał wykorzystywać Javowe API, czy to z biblioteki standardowej czy z dołączanych bibliotek, więc musisz się z tym w miarę komfortowo czuć. Jeśli jednak masz jakieś doświadczenie w OOP to możesz się porwać na Scalę od razu, bo wykorzystywanie Javy nie powinno być trudne w opanowaniu. Przez wykorzystywanie Javowego API mam na myśli odpalanie metod z Javowych klas i dziedziczenie po Javowych klasach czy interfejsach, ale dalej pisząc wszystko w Scali.

Jeśli chodzi o Androida to Scala może być trochę niefortunnym wyborem bo biblioteka standardowa jednak trochę waży. Wybór Scali może wydłużyć czas ładowania aplikacji o całe sekundy na starszych telefonach i wersjach Androida (bez kompilacji AOT). Kotlin na Androidzie wygląda znacznie sensowniej.

Bezpieczniej zaczynać od javy i poznac funkcyjne rzeczy z Javy 8 i przeskoczyc do Scali.

Scala robi kariere bardziej ze Sparkiem. Z webem mam nieco mieszane uczucia.

Przeanalizowałem plusy i minusy wszystkich rozwiązań i pójdę w stronę aplikacji mobilnych.Myśle ze wybiorę objective c i dalej bede rozwijał znajomosc swifta.

kornelgora napisał(a):

Przeanalizowałem plusy i minusy wszystkich rozwiązań i pójdę w stronę aplikacji mobilnych.Myśle ze wybiorę objective c i dalej bede rozwijał znajomosc swifta.

To trochę bez sensu, swift od dwóch lat wypiera objective-c.

A czy dobrze wam działa to IDE Xcode pod Linuksem? Programuje ktoś z was w tym pod Ubuntu, bo widzę na stronie Swift są wersje Xcode 7.3 i 8 beta do pobrania pod Ubuntu 15.10. Na Arch Linux i Manjaro nie ma w AUR a szkoda. Ale takie programowanie pod Linuksem Swift to chyba ma się podobnie do C# i MonoDevelop.

Jak chcesz pisac na ios to musisz miec maca.

Wibowit napisał(a):

• Python, PHP, JavaScript itd są powolnymi językami, bo oficjalne implementacje to interpretery. Z tego powodu ich szybkość jest o rzędy wielkości niższa niż szybkość C, C++, Javy, etc
• Java jest szybka - ma JIT i wydajnościowo wypada bardzo dobrze, zwykle jest mniej niż 2x wolniejsza od C/ C++. Z drugiej strony, czysty Python czy podobne interpretowane standardowymi interpreterami są dziesiątki albo setki razy wolniejsze od C/ C++/ Javy (polecam sprawdzić mój benchmark: https://github.com/tarsa/TarsaLZP ),

1. Wrzucasz wszystkie języki (silniki) do jednego wora, gdy są tak naprawdę między nimi ogromne różnice.
2. Najpopularniejsze implementacje JavaScriptu to nie zwykły interpreter a JIT compiler - nawet w Twoim (niemiarodajnym) benchmarku widać, że najpopularniejsze V8 daje wyniki tego samego rzędu wielkości co Java.
3. Jeśli komuś zależy na wydajności to użyje lepszego silnika, dlatego bajki o "rzędach wielkości" są bez sensu - jak potrzebujesz wydajności w Pythonie to użyjesz PyPy lub czegoś podobnego.
4. Jako wzorcowy benchmark proponujesz swój projekt, mierzący czasy dla bardzo wymagających obliczeniowo algorytmów - co chcesz tu udowodnić? Że języki skryptowe nie są dobrym wyborem przy nieidiomatycznych dla nich zadaniach? Brawo.

• JavaScript ma być niby lekką platformą, ale dzisiaj typowa kolorowa strona w Chrome potrafi zjadać setki MiB RAMu,

Tego to już całkiem nie ogarniam. Twoim argumentem przeciwko JS jest to, że przeglądarka + kupa grafik + html + css + js + nie wiadomo co jeszcze zabiera dużo RAMu? Może porównaj sobie serwis o identycznej funkcjonalności odpalony w Javie i Node.js - wtedy to będzie miało jakiś sens. Do poczytania: https://brainhub.eu/blog/2016/05/30/9-famous-apps-using-node-js/

Dawno nie czytałem bardziej nieuczciwego posta. JVM to niewątpliwie świetna platforma, ale litości - mniej fanbojstwa, więcej obiektywizmu.

1. Wrzucasz wszystkie języki (silniki) do jednego wora, gdy są tak naprawdę między nimi ogromne różnice.

Jakie?

1. Najpopularniejsze implementacje JavaScriptu to nie zwykły interpreter a JIT compiler - nawet w Twoim (niemiarodajnym) benchmarku widać, że najpopularniejsze V8 daje wyniki tego samego rzędu wielkości co Java.

Akurat starałem się pisać tak, by V8 dobrze zoptymalizował kod. Eksperymentowałem z różnymi stylami i wybrałem ten który działa najszybciej. Jednak pisanie pod konkretnego JITa jest trochę słabe.

1. Jeśli komuś zależy na wydajności to użyje lepszego silnika, dlatego bajki o "rzędach wielkości" są bez sensu - jak potrzebujesz wydajności w Pythonie to użyjesz PyPy lub czegoś podobnego.

Jak ktoś chce wysokiej wydajności to wybierze coś co ma przewidywalnie wysoką wydajność, a nie będzie zdawał się na łaskę optymalizacyjnych heurystyk.

1. Jako wzorcowy benchmark proponujesz swój projekt, mierzący czasy dla bardzo wymagających obliczeniowo algorytmów - co chcesz tu udowodnić? Że języki skryptowe nie są dobrym wyborem przy nieidiomatycznych dla nich zadaniach? Brawo.

Chciałem przetestować wydajność czystego kodu, a nie funkcji wbudowanych. Czy mierzenie szybkości regexa z benchmarka shootout ma jakiś sens? Moim zdaniem niewielki.

Idiomatyczne to są konstrukcje językowe, a nie zastosowania.

Tego to już całkiem nie ogarniam. Twoim argumentem przeciwko JS jest to, że przeglądarka + kupa grafik + html + css + js + nie wiadomo co jeszcze zabiera dużo RAMu? Może porównaj sobie serwis o identycznej funkcjonalności odpalony w Javie i Node.js - wtedy to będzie miało jakiś sens. Do poczytania: https://brainhub.eu/blog/2016/05/30/9-famous-apps-using-node-js/

Dawno nie czytałem bardziej nieuczciwego posta. JVM to niewątpliwie świetna platforma, ale litości - mniej fanbojstwa, więcej obiektywizmu.

Dla równowagi można podać takie porównania: https://www.linkedin.com/pulse/nodejs-vs-java-which-faster-apis-owen-rubel
W artykule podanym przez ciebie są opisane przypadki, gdzie aplikacje są przepisywane od zera. Przy przepisywaniu można się zastanowić jakie były błędne decyzje podczas poprzedniego projektu i zrobić go lepiej.

Z porównania tutaj http://benchmarksgame.alioth.debian.org/u64q/javascript.html wynika, że:

• oprócz testowania regexów, gdzie testowany jest kod czysto Javowy (regexy w Javie są robione za pomocą zwykłego kodu Javowego) kontra kod w C++ (bo regexy w JS to funkcja wbudowana) to V8 jest kilka razy wolniejsze niż Java,
• Java ma większy stały narzut pamięciowy, ale to tylko kilka megabajtów różnicy,
• przy testach gdzie wymaga się większej ilości pamięci V8 może zabrać jej wiele razy więcej niż Java (jak już wcześniej napisałem, regex-dna jest niemiarodajny),

To nie moja wina, że Javowcy lubią sobie używać ciężkich kobył do tworzenia aplikacji. Kobyły mają jednak to do siebie, że mają mnóstwo wbudowanych bajerów. Z porównania serwisów przepisanych na node.js nie wynika też czy ich architektura nie została zmieniona. Jeżeli np przeniesiono logikę i/ lub stan na stronę klienta to już porównanie robi się trochę nie fair. Miarodajne porównanie byłoby gdyby np zrobić dwa backendy (jeden w Javie, a drugi w JavaScripcie) RESTowe dla tego samego frontendu.

@Wibowit
Jasne, wiele zależy od architektury, jakości kodu itp., jednak nie sądzę, żeby wymienione firmy nie wiedziały co robią. Wiadomo, że historie sukcesu do takich artykułów są dobrze dobierane. Wrzuciłem ten link dla równowagi, bo z Twojego posta wynika, że takie aplikacje nie powinny istnieć.