Vill du vara del av diskussionerna i forumet, ställa frågor eller hjälpa andra? Registrera dig här!

Vad skulle Java behöva göras som för att slå Python i PYPL-index?

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008

Vad skulle Java behöva göras som för att slå Python i PYPL-index?

Java är det populäraste språket enligt TIOBE och språket växer uppåt.

Men i PYPL så har Python gått om Java med marginaler.
http://pypl.github.io/PYPL.html

Då kan man undra: Vad skulle Java behöva göras om för att Java ska bli mer attraktivt? Jag vet om att Python är enkelt språk att komma igång jämfört med Java. Men jag tror inte det är som är orsaken varför Python växer mer än Java.

Jag tror det är något annat som driver marknaden mot Python-hållet än Java-hållet. Vad tror ni? Vad skulle Java behöva göras om?

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Medlem
Plats
Luleå
Registrerad
Aug 2008

Java kommer nog tappa ytterligare i och med licensförändringen.

Lite länkar kring ämnet/förändringen
Artikel
Sweclockers tråd

Stationär: i7 9900k | 32GB DDR4 | Aorus Master | 2080s | Evolv X | 970 1TB + 970 0.5TB + 850 1TB | G915 | G604 | Acer XB271HU | Dell U2719D
Homelab: I3 6100 | 16GB DDR4 | Node304 | 6x 4TB 7.2k | 850 250GB
Bärbart: Lenovo Carbon X1 | Shield Tablet | Galaxy S8 | Tab S5e |

Trädvy Permalänk
Entusiast
Testpilot
Plats
Göteborg
Registrerad
Aug 2011
Skrivet av heretic16:

Då kan man undra: Vad skulle Java behöva göras om för att Java ska bli mer attraktivt?

Komma in i matchen, om du frågar mig. Nu definierar man ju inte om ett helt språk hur som helst, men Kotlin verkar i hög grad vara Java done right. Det gläder mig att det verkar gå starkt i PYPL (fyra gröna pilar uppåt), samtidigt som Java tappar. Det har haft sin tid. Jag kommer inte sakna det.

Citat:

Jag vet om att Python är enkelt språk att komma igång jämfört med Java. Men jag tror inte det är som är orsaken varför Python växer mer än Java.

Varför tror du inte det?

Trädvy Permalänk
Medlem
Registrerad
Nov 2019

Jag ger inte mycket för statistiken: The PYPL PopularitY of Programming Language Index is created by analyzing how often language tutorials are searched on Google
Detta google-resultat kommer självklart vara ett resultat där ett enkelt språk som väldigt många bara testar på kommer få höga poäng. Resultatet återspeglar dåligt hur många systemutvecklare som har språket som sitt huvudspråk.

Angående java så var det coolt runt 1997, man kunde då göra fräcka saker på internet med detta. Idag, ja android har java, men annars är min känsla på windowssidan att javalösningar = dåliga lösningar. Där c#, c++ hade kunnat löst problemen bättre.
Kommer någon med en java lösning och vill ha in på en server, så får vi noggrant utreda om java bör installeras på servern. När jag för tag sedan installerade SQL server, så fick jag bocka ut något då det krävde att java installerades och den vill jag ej ha på servern.

Trädvy Permalänk
Medlem
Registrerad
Jan 2014
Skrivet av lillaankan_i_dammen:

Angående java så var det coolt runt 1997, man kunde då göra fräcka saker på internet med detta. Idag, ja android har java, men annars är min känsla på windowssidan att javalösningar = dåliga lösningar. Där c#, c++ hade kunnat löst problemen bättre.
Kommer någon med en java lösning och vill ha in på en server, så får vi noggrant utreda om java bör installeras på servern. När jag för tag sedan installerade SQL server, så fick jag bocka ut något då det krävde att java installerades och den vill jag ej ha på servern.

Ja, om man pratar om applikationer som körs under windows så är knappast Java någon höjdare. Men det är vanligtvis inte så java används idag som tur är. Java körandes på applikationsserver under docker eller liknande är helt okay och motsvarar liknande lösningar under .net core eller liknande.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008
Skrivet av Alling:

Komma in i matchen, om du frågar mig. Nu definierar man ju inte om ett helt språk hur som helst, men Kotlin verkar i hög grad vara Java done right. Det gläder mig att det verkar gå starkt i PYPL (fyra gröna pilar uppåt), samtidigt som Java tappar. Det har haft sin tid. Jag kommer inte sakna det.

Varför tror du inte det?

Jag har inte testat Kotlin. Har varit sugen på det, men många av mina bibliotek jag använder är gjord i Java. Sedan känns det som att Kotlin kommer inte överleva. Jag menar...Kotlin har ju sin styrka i Android, men nu när Flutter finns...så känns det som...Varför Kotlin för Android när man kan använda Flutter mot Iphone, Android, Windows med mera? Notera att GluonHQ finns också, men det är gjort för Java.

Jag tror att mycket bygger på att Java är anpassat för industrin. Ungefär som att marknaden väljer C istället för C++ många gånger.
Tråkiga språk brukar vara attraktiva.

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008
Skrivet av lillaankan_i_dammen:

Jag ger inte mycket för statistiken: The PYPL PopularitY of Programming Language Index is created by analyzing how often language tutorials are searched on Google
Detta google-resultat kommer självklart vara ett resultat där ett enkelt språk som väldigt många bara testar på kommer få höga poäng. Resultatet återspeglar dåligt hur många systemutvecklare som har språket som sitt huvudspråk.

Angående java så var det coolt runt 1997, man kunde då göra fräcka saker på internet med detta. Idag, ja android har java, men annars är min känsla på windowssidan att javalösningar = dåliga lösningar. Där c#, c++ hade kunnat löst problemen bättre.
Kommer någon med en java lösning och vill ha in på en server, så får vi noggrant utreda om java bör installeras på servern. När jag för tag sedan installerade SQL server, så fick jag bocka ut något då det krävde att java installerades och den vill jag ej ha på servern.

Alla vet att Java Applets var det coolaste som finns!! Runescape typ.

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Medlem
Plats
NördCentrum
Registrerad
Jun 2011
Skrivet av heretic16:

Jag har inte testat Kotlin. Har varit sugen på det, men många av mina bibliotek jag använder är gjord i Java. Sedan känns det som att Kotlin kommer inte överleva. Jag menar...Kotlin har ju sin styrka i Android, men nu när Flutter finns...så känns det som...Varför Kotlin för Android när man kan använda Flutter mot Iphone, Android, Windows med mera? Notera att GluonHQ finns också, men det är gjort för Java.

Jag tror att mycket bygger på att Java är anpassat för industrin. Ungefär som att marknaden väljer C istället för C++ många gånger.
Tråkiga språk brukar vara attraktiva.

Kotlin kör ju på JVMen, så det borde inte vara något direkt strul med att använda Java-bibliotek om Kotlin-ekvivalent inte redan finns. https://kotlinlang.org/docs/reference/java-interop.html

Gibb: Win10 - Ryzen 5 3600 - RX 580 - 16G 3000MHz DDR4
Server: Arch - 2 * Xeon X5570 - R9 280X - 32G DDR3 ECC

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008
Skrivet av Bryal:

Kotlin kör ju på JVMen, så det borde inte vara något direkt strul med att använda Java-bibliotek om Kotlin-ekvivalent inte redan finns. https://kotlinlang.org/docs/reference/java-interop.html

Om jag liks ska köra Java-kod så kanske det är bättre att skriva allt i Java, istället för Kotlin?
Jag väntar några år på om Kotlin kommer växa och slå Java.

Jag tror att Oracle kommer ta många fördelar från Kotlin om Java börjar falla.

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Medlem
Registrerad
Feb 2013

Python används ju mycket i AI-världen så det är nog en drivkraft för ökat användande. Tror inte att Python ersätter Java så mycket, dom har ju bägge sina nischer.

Kotlin är helt klart ersättaren till Java i Android-världen. Man kan blanda fritt i koden så Kotlin får nog anses vara default numera. Här blir Java ersatt och mycket av det drivs av Oracles svinerier.

Dart/Flutter är rätt väg för cross-platform Android/iOS, inte Javascript, men som alltid, om man inte måste vara cross-platform så är det bättre att köra native, alltså Kotlin. Cross-platform har sitt pris.

En svaghet med Python är att det inte skalar så bra på många kärnor. Julia är nog ett bättre val i den nischen. Swift/Kotlin/Dart är också generellt bättre än Java för att köras på många kärnor.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av heretic16:

Jag har inte testat Kotlin. Har varit sugen på det, men många av mina bibliotek jag använder är gjord i Java.

Java var "state of the art" på 90-talet, men med åren har man insett att ett flertal designval man gjorde då var allt annat än optimala. Dessa misstag kan inte fixas inom ramen för Java utan att bryta bakåtkompatibilitet, så man (likt ISO-kommittén för C++ allt mer smärtsamt insett) är fast med dessa misstag.

Kotlin designades aldrig för Android, det är ett "Java done right post-2000". Majoriteten av Kotlin-användarna finnns utanför Android. Att Kotlin så snabbt blivit så populärt inom Android-sfären beror på att man länge insett att Java inte är ett lika bra val för detta område som t.ex. Swift och man sökte aktivt efter en ersättare (Oracles stämningar mot Google lär har oljat på denna process en hel del).

De goda nyheterna för dig är att Kotlin är, precis som språket Java, helt designat för att köras på plattformen Java (d.v.s. den ISA som definieras av JVM). Rent konkret betyder det att alla bibliotek som är skrivna i Java kan utan problem användas från Kotlin och det finns ingen "översättningskostnad" associerat med detta. Java-bibliotek är precis lika "native" för Kotlin-kod som Kolin-bibliotek då båda använder samma binära gränssnitt (vilken är plattformen Java).

Ställt mot .Net världen är språket Java det C# är för .Net. Plattformen Java är det CIL är för .Net. Det lite ironiska här är att Sun aldrig riktigt designade plattformen Java för att innefatta andra språk, medan Microsoft från start designade CIL (som initialt kallades MSIL) specifikt för att kunna användas från andra språk än C#. Ändå har JVM:en (plattformen Java) blivit långt mer framgångsrik som plattform för en rad olika språk som Clojure, Scala, Kotlin, Groovy (är det Jenkins använder), Jython, m.fl.

Alla språk som kör på JVM kan utan problem använda bibliotek skrivna i Java eller något av de andra JVM-språken helt utan "översättningskostnad"!

Java kommer vara ett viktigt språk under väldigt många år framöver, det av samma anledning som C, C++, Cobol och är/har varit viktiga: de används inom många viktiga områden. Men precis som C och C++ skulle ingen designa språk på just det sättet, utvecklingen har gått framåt och om man inte måste använda Java är Kotlin ett långt bättre val. Det precis som Go och Rust (beroende på om man skriver applikationer eller systemprogramvara likt OS) idag är tekniskt långt vettigare val än C och C++.

Det betyder inte att vare sig Java, C eller C++ kommer dö inom kort. Finnas massor med anledningar varför man inte kan gå ifrån dessa språk. Men i varje nytt projekt bör man verifiera om det är möjligt, för alla dessa språk har massor med designbeslut som man idag aldrig skulle välja att göra!

Skrivet av Lars Celander:

Python används ju mycket i AI-världen så det är nog en drivkraft för ökat användande. Tror inte att Python ersätter Java så mycket, dom har ju bägge sina nischer.

Kotlin är helt klart ersättaren till Java i Android-världen. Man kan blanda fritt i koden så Kotlin får nog anses vara default numera. Här blir Java ersatt och mycket av det drivs av Oracles svinerier.

Dart/Flutter är rätt väg för cross-platform Android/iOS, inte Javascript, men som alltid, om man inte måste vara cross-platform så är det bättre att köra native, alltså Kotlin. Cross-platform har sitt pris.

En svaghet med Python är att det inte skalar så bra på många kärnor. Julia är nog ett bättre val i den nischen. Swift/Kotlin/Dart är också generellt bättre än Java för att köras på många kärnor.

Python är väldigt lätt att komma igång med, det är av allt att döma just nu det mest populära språket inom utbildning. Så är långt mer än inom AI Python är populärt!

Att Python inte skalar så bra med CPU-kärnor måste vara årets största underdrift (fast vi är trots allt mindre än en dag in i det nya året)... CPython, vilket är den "normal" Python-implementationen, skalar faktiskt överhuvudtaget inte förbi en CPU-kärna! Varianter som Jython och Pypy kan skala, men de är inte i närheten lika vanliga som CPython.

Enda sättet CPython kan utnyttja flera kärnor är via extensioner (som typiskt är skrivna i C eller C++), likt t.ex. NumPy (som bl.a. är populärt inom AI). Men att det skalar där är specifikt för att man inte kör i kontext av CPyton.

Så Pythons stora värde ligger helt uppenbarligen utanför saker som: jag behöver skriva prestandakritisk programvara som skalar väl med CPU-kärnar

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008
Skrivet av Yoshman:

Java var "state of the art" på 90-talet, men med åren har man insett att ett flertal designval man gjorde då var allt annat än optimala. Dessa misstag kan inte fixas inom ramen för Java utan att bryta bakåtkompatibilitet, så man (likt ISO-kommittén för C++ allt mer smärtsamt insett) är fast med dessa misstag.

Kotlin designades aldrig för Android, det är ett "Java done right post-2000". Majoriteten av Kotlin-användarna finnns utanför Android. Att Kotlin så snabbt blivit så populärt inom Android-sfären beror på att man länge insett att Java inte är ett lika bra val för detta område som t.ex. Swift och man sökte aktivt efter en ersättare (Oracles stämningar mot Google lär har oljat på denna process en hel del).

De goda nyheterna för dig är att Kotlin är, precis som språket Java, helt designat för att köras på plattformen Java (d.v.s. den ISA som definieras av JVM). Rent konkret betyder det att alla bibliotek som är skrivna i Java kan utan problem användas från Kotlin och det finns ingen "översättningskostnad" associerat med detta. Java-bibliotek är precis lika "native" för Kotlin-kod som Kolin-bibliotek då båda använder samma binära gränssnitt (vilken är plattformen Java).

Ställt mot .Net världen är språket Java det C# är för .Net. Plattformen Java är det CIL är för .Net. Det lite ironiska här är att Sun aldrig riktigt designade plattformen Java för att innefatta andra språk, medan Microsoft från start designade CIL (som initialt kallades MSIL) specifikt för att kunna användas från andra språk än C#. Ändå har JVM:en (plattformen Java) blivit långt mer framgångsrik som plattform för en rad olika språk som Clojure, Scala, Kotlin, Groovy (är det Jenkins använder), Jython, m.fl.

Alla språk som kör på JVM kan utan problem använda bibliotek skrivna i Java eller något av de andra JVM-språken helt utan "översättningskostnad"!

Java kommer vara ett viktigt språk under väldigt många år framöver, det av samma anledning som C, C++, Cobol och är/har varit viktiga: de används inom många viktiga områden. Men precis som C och C++ skulle ingen designa språk på just det sättet, utvecklingen har gått framåt och om man inte måste använda Java är Kotlin ett långt bättre val. Det precis som Go och Rust (beroende på om man skriver applikationer eller systemprogramvara likt OS) idag är tekniskt långt vettigare val än C och C++.

Det betyder inte att vare sig Java, C eller C++ kommer dö inom kort. Finnas massor med anledningar varför man inte kan gå ifrån dessa språk. Men i varje nytt projekt bör man verifiera om det är möjligt, för alla dessa språk har massor med designbeslut som man idag aldrig skulle välja att göra!

Du menar att Java och C++ har målat in sig i ett hörn? Jag skulle vilja veta mera vad som skiljer kotlin mot Java, av dig. Jag har hört att Kotlin har nullsäkerhet. Detta har jag hört ska vara bra. Men borde inte null vara bra att använda om man vill beskriva något som inte finns?

Du tror inte Oracle kommer bygga om Java så att den tar Kotlins egenskaper? Jag skulle vilja se Lombok inbyggt i Java. Jag skulle vilja se @Autowired vara innyggt i Java. Jag skulle villja se JavaFX vara inbyggt i Java. Där efter är jag ganska nöjd.

Själv kör jag C istället för C++. C är så mycket enklare att jobba med och programmet blir så mycket mer nogrannt skrivet då man jobbar med små detaljer hela tiden.

Rust har jag aldrig testat. Det ser krångligt ut och den har lite stöd för hårdvara t.ex inbyggda system

Citat:

Python är väldigt lätt att komma igång med, det är av allt att döma just nu det mest populära språket inom utbildning. Så är långt mer än inom AI Python är populärt!

Att Python inte skalar så bra med CPU-kärnor måste vara årets största underdrift (fast vi är trots allt mindre än en dag in i det nya året)... CPython, vilket är den "normal" Python-implementationen, skalar faktiskt överhuvudtaget inte förbi en CPU-kärna! Varianter som Jython och Pypy kan skala, men de är inte i närheten lika vanliga som CPython.

Enda sättet CPython kan utnyttja flera kärnor är via extensioner (som typiskt är skrivna i C eller C++), likt t.ex. NumPy (som bl.a. är populärt inom AI). Men att det skalar där är specifikt för att man inte kör i kontext av CPyton.

Så Pythons stora värde ligger helt uppenbarligen utanför saker som: jag behöver skriva prestandakritisk programvara som skalar väl med CPU-kärnar

Jag använder inte python för att jag uppfattar många pythonanvändare för bluff. Import kan man inte ta beröm för

Skickades från m.sweclockers.com

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Medlem
Plats
Västra götaland (Borås)
Registrerad
Sep 2012
Skrivet av heretic16:

Du menar att Java och C++ har målat in sig i ett hörn?
...
Du tror inte Oracle kommer bygga om Java så att den tar Kotlins egenskaper?

De kan inte göra större ändringar då större ändringar hade inneburit breaking changes. Visst, du hade kunnat göra toggles och sådant men i slutet så blir då frågan varför ens kalla det java vid det laget. Typexemplet på det är ICloneable interface'n som är felstavad i Java sedan den först skrevs, ska vara IClonable. (Fler språk har också stavat fel avsiktligt för att folk ska hitta det vilket nu har gjort det till en accepterad variant på stavningen.) Det har varit bedömt för mycket av en breaking change sedan första releasen med interface'n. Att ändra fundementalla saker i språket är avsevärt mycket svårare. Inte för själva utvecklingen av ändringarna utan att faktiskt få användare av språket att använda det. Tänk om en höjning av java version skulle kräva att du skriver om stora delar av hela programmet, hur många av dina gamla projekt skulle faktiskt få den kärleken?

Skrivet av heretic16:

Jag skulle vilja veta mera vad som skiljer kotlin mot Java, av dig. Jag har hört att Kotlin har nullsäkerhet. Detta har jag hört ska vara bra. Men borde inte null vara bra att använda om man vill beskriva något som inte finns?

Det har nullable types som ger säkrare hantering av null. Det kan liknas med monaden optional. Så när du använder datatyper så säger du om du förväntar dig att null är accepterbart värde. Det görs i syntax av "MyClass?" där frågetecknet anger att det är ok att det är null. Notera däremot att eftersom de kör JVM runtime fortfarande så är det primärt en kompileringssäkerhet då den kan utföra statisk analys så man inte matar in null till funktioner som inte stödjer null. Det gör så man slipper ha null checks i varje metod för att kunna få en solid funktion, någonting som inte är rimligt i praktiken.

Skrivet av heretic16:

Jag skulle vilja se Lombok inbyggt i Java. Jag skulle vilja se @Autowired vara innyggt i Java. Jag skulle villja se JavaFX vara inbyggt i Java. Där efter är jag ganska nöjd.

Varför ska det vara inbyggt i Java? Minskar ju portabiliteten enormt. Disclaimer på att jag inte har använt Lombok eller Autowired, men Lombok ser ut att vara workarounds på designfel i Java och Autowired är en lösning för spring att göra dependency injection? JavaFX är ett semi-portabelt GUI bibliotek och hör i min åsikt verkligen inte hemma i standard biblioteken för ett språk. Det är ju inte ens kompatibelt med majoriteten av plattformar där java körs i praktiken, vilket är headless. Det är också någonting som är sannolikt att ändras någon gång i framtiden igen vilket gör att de får massor legacy kod i standard biblioteken vilket de vill undvika. Se bara på AWT och Swing som fortfarande ligger kvar och skräpar ner.

Skrivet av heretic16:

Själv kör jag C istället för C++. C är så mycket enklare att jobba med och programmet blir så mycket mer nogrannt skrivet då man jobbar med små detaljer hela tiden.

Du ökar komplexiteten desto mer implementationsdetaljer din business logik innehåller. Det minskar generellt även återanvändbarheten av kod då de inte blir särskilt generiska, fast det är ett problem med samtliga imperativa språk. Att kunna göra prestandaoptimeringar på lågnivå är en viktig förmåga för ett språk, men du vill inte klottra ner kod som varken utnyttjar eller har nytta av det. Sedan ger bättre abstraktionslager ofta i praktiken bättre prestanda tack vare hur mycket lättare det är att göra korrekt multitrådning, SIMD, distribution etc.

Skrivet av heretic16:

Rust har jag aldrig testat. Det ser krångligt ut och den har lite stöd för hårdvara t.ex inbyggda system

Rust har väldigt bra stöd för inbyggda system och det är väldesignat språk för att vara svårt att göra logikfel men lätt att göra rätt. Det är inte krångligt, det är bara annorlunda gentemot vad majoriteten (inklusive mig) är vana vid.

Skrivet av heretic16:

Jag använder inte python för att jag uppfattar många pythonanvändare för bluff. Import kan man inte ta beröm för

Jag gillar inte heller python av helt andra skäl som exempelvis @Yoshmans exempel på att multitrådningstödet är under all kritik. Men förstår inte alls resonemanget av att värdera ett språk baserat på åsikten av användare som använder det. Om du inte gillar hur vissa individer har skrivit sin kod så skriv bara inte på det viset?

Kan låta oavsiktligt aggressiv.
Citera eller @philipborg om du vill att jag ska läsa dina svar.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008
Skrivet av philipborg:

De kan inte göra större ändringar då större ändringar hade inneburit breaking changes. Visst, du hade kunnat göra toggles och sådant men i slutet så blir då frågan varför ens kalla det java vid det laget. Typexemplet på det är ICloneable interface'n som är felstavad i Java sedan den först skrevs, ska vara IClonable. (Fler språk har också stavat fel avsiktligt för att folk ska hitta det vilket nu har gjort det till en accepterad variant på stavningen.) Det har varit bedömt för mycket av en breaking change sedan första releasen med interface'n. Att ändra fundementalla saker i språket är avsevärt mycket svårare. Inte för själva utvecklingen av ändringarna utan att faktiskt få användare av språket att använda det. Tänk om en höjning av java version skulle kräva att du skriver om stora delar av hela programmet, hur många av dina gamla projekt skulle faktiskt få den kärleken?

Jag förstår vad du menar. Men jag tror att Oracle kommer lyckas göra Java mer modernt. Snart släpps ju Java 14. För 2 år sedan så släpptes Java 11. Så Java gör otroliga framsteg nu då Oracle verkar känna på att det bränns lite.

Citat:

Det har nullable types som ger säkrare hantering av null. Det kan liknas med monaden optional. Så när du använder datatyper så säger du om du förväntar dig att null är accepterbart värde. Det görs i syntax av "MyClass?" där frågetecknet anger att det är ok att det är null. Notera däremot att eftersom de kör JVM runtime fortfarande så är det primärt en kompileringssäkerhet då den kan utföra statisk analys så man inte matar in null till funktioner som inte stödjer null. Det gör så man slipper ha null checks i varje metod för att kunna få en solid funktion, någonting som inte är rimligt i praktiken.

Jaha. Trodde Kotlin ej kunde få null error över huvud taget.

Citat:

Varför ska det vara inbyggt i Java? Minskar ju portabiliteten enormt. Disclaimer på att jag inte har använt Lombok eller Autowired, men Lombok ser ut att vara workarounds på designfel i Java och Autowired är en lösning för spring att göra dependency injection? JavaFX är ett semi-portabelt GUI bibliotek och hör i min åsikt verkligen inte hemma i standard biblioteken för ett språk. Det är ju inte ens kompatibelt med majoriteten av plattformar där java körs i praktiken, vilket är headless. Det är också någonting som är sannolikt att ändras någon gång i framtiden igen vilket gör att de får massor legacy kod i standard biblioteken vilket de vill undvika. Se bara på AWT och Swing som fortfarande ligger kvar och skräpar ner.

Det är bra om det är inbyggt i JVM:en för om jag bygger ett program med JavaFX och sedan får du det programmet. Då slipper du först installera JavaFX för att köra programmet. Java AWT är ju rent snusk. Java Swing är ju riktigt stiligt Men det är väll sagt att all Java ska vara bakåtkompatibelt.

Citat:

Du ökar komplexiteten desto mer implementationsdetaljer din business logik innehåller. Det minskar generellt även återanvändbarheten av kod då de inte blir särskilt generiska, fast det är ett problem med samtliga imperativa språk. Att kunna göra prestandaoptimeringar på lågnivå är en viktig förmåga för ett språk, men du vill inte klottra ner kod som varken utnyttjar eller har nytta av det. Sedan ger bättre abstraktionslager ofta i praktiken bättre prestanda tack vare hur mycket lättare det är att göra korrekt multitrådning, SIMD, distribution etc.

Jag menar mer att när man kör C så tänker man djupare och programmerar långsammare. Man dessutom håller sig till funktionell programmering, vilket jag anser blir så mycket bättre än objektorienterad programmering. När jag skriver Java så försöker jag endast låtsats som språket endast kan funktionsprogrammering. OOP kan verkligen gröta till det.

Citat:

Rust har väldigt bra stöd för inbyggda system och det är väldesignat språk för att vara svårt att göra logikfel men lätt att göra rätt. Det är inte krångligt, det är bara annorlunda gentemot vad majoriteten (inklusive mig) är vana vid.

Nej. Rust har INTE stort stöd för inbyggda system. Språket är en bluff och kan ej mätas mot C. Rust dör ut före C. Om ens C dör ut...

Citat:

Jag gillar inte heller python av helt andra skäl som exempelvis @Yoshmans exempel på att multitrådningstödet är under all kritik. Men förstår inte alls resonemanget av att värdera ett språk baserat på åsikten av användare som använder det. Om du inte gillar hur vissa individer har skrivit sin kod så skriv bara inte på det viset?

Jag tycker språket är OK. Men det är just kulturen kring Python som jag inte gillar. Allt känns bara nybörjarattityd och "jag skiter i hur koden ser ut, så länge det fungerar"-attityd i pythonprojekt. Noll fokus på kvalité och CPU och RAM har en pythonprogrammare ej tänkt på.

Riktiga språk heter C, C++, C#, Java, MATLAB, PHP, JavaScript. Ja, dom är dom mest tråkiga också, men mest använda.

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Hedersmedlem
Plats
Linköping
Registrerad
Okt 2006

@heretic
Jaja, lite har väl din åsikt ändrats iaf. Förut hette det ju att Java var allsmäktigt och var språket för allt. Tids nog kanske du ser kan tänka steget längre och förstå styrkan i Python, Rust och andra språk. Det är inte så att du är sur för att Python är mer populärt än Java? Du har ju själv sagt att återanvändning av vad andra gjort är det bästa man kan göra. Så att köra Python och importera borde ju falla dig jättebra i smaken.

Trädvy Permalänk
Medlem
Plats
Västra götaland (Borås)
Registrerad
Sep 2012
Skrivet av heretic16:

Jag förstår vad du menar. Men jag tror att Oracle kommer lyckas göra Java mer modernt. Snart släpps ju Java 14. För 2 år sedan så släpptes Java 11. Så Java gör otroliga framsteg nu då Oracle verkar känna på att det bränns lite.

De kommer väldigt troligen modernisera det en hel del och det kanske till och med kan bli någorlunda OK, men när en hel del av grund-designen är omodern så kan de bara göra så mycket.

Skrivet av heretic16:

Jaha. Trodde Kotlin ej kunde få null error över huvud taget.

Det är mer att det är väldigt mycket lättare att hantera det då när du använder en nullable type så måste du antingen explicit säga vad du vill göra när den är null eller göra "myVar!!" som säger i princip "jag vet att det är en nullable men jag vill hämta värdet och är det null så kasta ett exception". Men ja, du kan fortfarande få null exceptions i situationer som när anropar kotlin kod från java då java inte har ett koncept av null reference typer.

Skrivet av heretic16:

Det är bra om det är inbyggt i JVM:en för om jag bygger ett program med JavaFX och sedan får du det programmet. Då slipper du först installera JavaFX för att köra programmet. Java AWT är ju rent snusk. Java Swing är ju riktigt stiligt Men det är väll sagt att all Java ska vara bakåtkompatibelt.

Nu var det ett rätt bra tag sedan jag satt med vanlig JavaFX, tror det var runt 2011-2014 sporadiskt, men vad jag minns så var det bara en dependency som vilken som helst? Ingenting man behövde installera på datorn. Satt även med ScalaFX vid årskiftet 2017-2018 och även där var det bara en helt vanlig dependency.

Skrivet av heretic16:

Jag menar mer att när man kör C så tänker man djupare och programmerar långsammare. Man dessutom håller sig till funktionell programmering, vilket jag anser blir så mycket bättre än objektorienterad programmering. När jag skriver Java så försöker jag endast låtsats som språket endast kan funktionsprogrammering. OOP kan verkligen gröta till det.

Då hänger jag med mer och att skriva funktions orienterad kod är väldigt trevligt. Försöker till och med personligen gå över till Haskell för privata hobby projekt (från Scala/Kotlin iofs) just för att jag också ser problematiken med ren imperativ OOP, nämnligen refaktorisering.

Skrivet av heretic16:

Nej. Rust har INTE stort stöd för inbyggda system. Språket är en bluff och kan ej mätas mot C. Rust dör ut före C. Om ens C dör ut...

Utveckla gärna, har inte suttit så mycket med Rust i inbyggda system utan har bara läst en del bloggar om folk som kört det på inbyggda system. Sedan tror jag inte varken Rust eller C lär dö inom någon snar framtid. Programmeringsspråk har väldigt svårt att dö, bara titta på COBAL som fortfarande rätt många fintech företag sitter och utvecklar på.

Vet däremot inte om det är ett så bra måttstock på vilket språk jag vill lära mig och utveckla i. Knappast en brist på arbetsplatser inom denna branchen så man kan faktiskt fördjupa sig inom språk som man faktiskt gillar. Pratar vi däremot ur ett företags perspektiv av livstid för mjukvaran så brukar det snarare vara plattformar och bibliotek som dör innan språken. Men det är givetvis lite personligt, jag gillar att byta språk då jag finner det uppfriskande med nya tankesätt och lösningar på designproblem.

Skrivet av heretic16:

Jag tycker språket är OK. Men det är just kulturen kring Python som jag inte gillar. Allt känns bara nybörjarattityd och "jag skiter i hur koden ser ut, så länge det fungerar"-attityd i pythonprojekt. Noll fokus på kvalité och CPU och RAM har en pythonprogrammare ej tänkt på.

Jo, det är en giltig punkt speciell när man ser på det ur ett informations perspektiv och man vill hitta en bra lösning till ett problem och man bara ser riktiga fulhack. (Typ exempel är busy loop för sleep i javascript som bara får mig att må lite illa, vilket först nu de senaste åren har fått en ordentlig lösning.)

Skrivet av heretic16:

Riktiga språk heter C, C++, C#, Java, MATLAB, PHP, JavaScript. Ja, dom är dom mest tråkiga också, men mest använda.

Att någonting är populärt betyder inte att det är bra, samt att allt utom möjligen esoteriska språk är riktiga programmingsspråk. Bara kolla på vad folk som använder github sitter med så kommer du se att Python är det näst mest populära programmeringsspråket just nu som varken du eller jag iaf är särskilt förtjusta i. En stor anledning till att de språken du nämner är populära är tack vare "legacy" applikationer och platformsstöd, inte för att de faktiskt är bra språk. Exempelvis så är en överväldigande andel av PHP sidorna på versioner av PHP som har passerat end-of-life vilket är ett tecken på att de inte längre aktivt förvaltas.

C# har haft massor designbrister som först nu i C# 7/8 börjar fixas till och mycket kvarstår, det är däremot ändå ett rätt schysst språk men långt ifrån något optimum. Java handlar tråden om så där behöver jag nog inte nämna så mycket. PHP är ju rätt värdelöst designat då grundaren aldrig avsåg att det skulle användas av andra och funktionsnamn namngavs efter hash distribution istället för programmeraren. Javascript var aldrig designat för att faktiskt skriva hela webbsidor i utan var enbart tänkt att användas som lim för att visa Java Applets och utvecklades under kraftig tidspress. C/C++ var båda rätt banbrytande för sin tid men det har hänt mycket sedan dess och som @Yoshman sa hade man designat C/C++ idag så hade mycket sett annorlunda ut. Så är det med mycket, exempelvis så ångrar sig uppfinnaren av null refences väldigt mycket och kallar det idag "The Billion Dollar mistake".

Kan låta oavsiktligt aggressiv.
Citera eller @philipborg om du vill att jag ska läsa dina svar.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av heretic16:

Jag tycker språket är OK. Men det är just kulturen kring Python som jag inte gillar. Allt känns bara nybörjarattityd och "jag skiter i hur koden ser ut, så länge det fungerar"-attityd i pythonprojekt. Noll fokus på kvalité och CPU och RAM har en pythonprogrammare ej tänkt på.

Humor

Language

Time (sec)

Memory (MB)

C++

1.94

1.0

Rust

2.16

4.8

Java

4.03

513.8

Python

314.79

4.9

Java är snabbt, men en förutsättning för att Java ska kunna vara snabbt är att man har rejält med RAM att "offra". Har man skräpsamlare (som Java, Python, C#, Go och de flesta språk förutom C, C++ och Rust har) måste man göra ett val mellan minnes-hog eller relativt hög overhead. Java har valt det förra, Python det senare.

I övrigt skrev @philipborg ett lysande svar jag bara kan stämma in i.

Just att Kotlin inte helt kan eliminera "null pointer exception" är en av (rätt få) nackdelar att återanvända en existerande populär runtime-plattform som Java. Vissa saker kan man inte fixa inom ramen för runtime:en

En annan sak som jag länge avskytt är exceptions. Vissa kallar dem "gotos-on-steriods", jag anser att det är en allt för snäll beskrivning då goto normalt sett inte kan hoppa ur existerande funktion. Exceptions är "longjmp-on-steriods" för att använda C-lingo. Skönt att se att trenden till slut kommit till att eliminera detta i moderna språk, både Rust och Go saknar detta (vilket i.o.f.s. även C gör, så pluspoäng där men man har å andra sidan både goto och longjmp()/setjmp()...). Kotlin kan inte följa den trenden, utan är tvungen att på något sätt hantera exceptions då det är del av Java-runtime.

Gillar man Java finns inget att frukta inom överskådlig tid, det kommer användas lång tid framöver just då det är så otroligt välanvänt. Men Oracle kommer inte kunna fixa de fundamentala problemen med språket utan att bryta bakåtkompatibilitet, och det kan man inte göra med mindre att göra språket helt irrelevant.

Mottot för C++ är "zero-cost-abstractions", "you only pay for what you use". D.v.s. fokus är extremt mycket på att ge bra stöd till de mest prestandakritiska applikationerna. Men där brottas man just nu med att man gjort designval som man nu inser påverkar prestanda negativt, vissa designval finns inte ens i standarden men tyvärr förutsätter många kodbaser vissa egenskaper som kommit av hur t.ex. GCC, LLVM och MSVC valt att implementera saker en gång i tiden.

Det är en segdragen debatt nu om man ska göra s.k. "ABI-breaking changes" i nästa standard (C++23). Att man ens diskuterar detta visar hur extremt kritisk bakåtkompatibilitet är, för ISO C++ definierar faktiskt ingen standard (man nämner explicit att standarden inte innefattar ABI). Men i praktiken finns en implicit ABI som väldigt mycket programvara/bibliotek beror på -> inte alls självklart att man ska fixa vissa saker man bevisat försämrar prestanda.

Ur den aspekten är C, C++ och Java rätt lika. De används på så extremt många ställen att bakåtkompatibilitet är superkritiskt. Att göra ett nytt språk som Kotlin är så bra man kan hantera det hela och ändå ge ett enkelt sätt att använda existerande kod.

Rust har samma grundtanke. C är och kommer vara superviktigt under överskådlig tid, därför är kompatibilitet med C kod en del av standarden i Rust. Går tyvärr inte göra något liknande mot C++, det just p.g.a. avsaknad av standardiserad ABI... Fördelen Rust har över Kotlin är att man saknar runtime och därmed slipper det bagaget.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Hedersmedlem
Plats
Linköping
Registrerad
Apr 2004
Skrivet av heretic16:

Man dessutom håller sig till funktionell programmering, vilket jag anser blir så mycket bättre än objektorienterad programmering. När jag skriver Java så försöker jag endast låtsats som språket endast kan funktionsprogrammering.

Nu kanske du menar procedurell programmering snarare än funktionell, men om det är det senare du är intresserad av borde väl det givna valet (som javafrälst) vara clojure?

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008
Skrivet av Elgot:

Nu kanske du menar procedurell programmering snarare än funktionell, men om det är det senare du är intresserad av borde väl det givna valet (som javafrälst) vara clojure?

Javafrälst för marknaden säger det. Skulle Kotlin vara mer populärt än Java så hade jag kört Kotlin.
Jag tycker det är intressant att diskutera programmeringsspråk. Men i slutändan så är det ändå industrin som bestämmer vad man ska köra.

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jun 2008
Skrivet av Yoshman:

Humor

Language

Time (sec)

Memory (MB)

C++

1.94

1.0

Rust

2.16

4.8

Java

4.03

513.8

Python

314.79

4.9

Java är snabbt, men en förutsättning för att Java ska kunna vara snabbt är att man har rejält med RAM att "offra". Har man skräpsamlare (som Java, Python, C#, Go och de flesta språk förutom C, C++ och Rust har) måste man göra ett val mellan minnes-hog eller relativt hög overhead. Java har valt det förra, Python det senare.

I övrigt skrev @philipborg ett lysande svar jag bara kan stämma in i.

En annan sak som jag länge avskytt är exceptions. Vissa kallar dem "gotos-on-steriods", jag anser att det är en allt för snäll beskrivning då goto normalt sett inte kan hoppa ur existerande funktion. Exceptions är "longjmp-on-steriods" för att använda C-lingo. Skönt att se att trenden till slut kommit till att eliminera detta i moderna språk, både Rust och Go saknar detta (vilket i.o.f.s. även C gör, så pluspoäng där men man har å andra sidan både goto och longjmp()/setjmp()...). Kotlin kan inte följa den trenden, utan är tvungen att på något sätt hantera exceptions då det är del av Java-runtime.

Gillar man Java finns inget att frukta inom överskådlig tid, det kommer användas lång tid framöver just då det är så otroligt välanvänt. Men Oracle kommer inte kunna fixa de fundamentala problemen med språket utan att bryta bakåtkompatibilitet, och det kan man inte göra med mindre att göra språket helt irrelevant.

Mottot för C++ är "zero-cost-abstractions", "you only pay for what you use". D.v.s. fokus är extremt mycket på att ge bra stöd till de mest prestandakritiska applikationerna. Men där brottas man just nu med att man gjort designval som man nu inser påverkar prestanda negativt, vissa designval finns inte ens i standarden men tyvärr förutsätter många kodbaser vissa egenskaper som kommit av hur t.ex. GCC, LLVM och MSVC valt att implementera saker en gång i tiden.

Det är en segdragen debatt nu om man ska göra s.k. "ABI-breaking changes" i nästa standard (C++23). Att man ens diskuterar detta visar hur extremt kritisk bakåtkompatibilitet är, för ISO C++ definierar faktiskt ingen standard (man nämner explicit att standarden inte innefattar ABI). Men i praktiken finns en implicit ABI som väldigt mycket programvara/bibliotek beror på -> inte alls självklart att man ska fixa vissa saker man bevisat försämrar prestanda.

Ur den aspekten är C, C++ och Java rätt lika. De används på så extremt många ställen att bakåtkompatibilitet är superkritiskt. Att göra ett nytt språk som Kotlin är så bra man kan hantera det hela och ändå ge ett enkelt sätt att använda existerande kod.

Rust har samma grundtanke. C är och kommer vara superviktigt under överskådlig tid, därför är kompatibilitet med C kod en del av standarden i Rust. Går tyvärr inte göra något liknande mot C++, det just p.g.a. avsaknad av standardiserad ABI... Fördelen Rust har över Kotlin är att man saknar runtime och därmed slipper det bagaget.

Titta på benchmark istället. Där har du en väldigt bra källa på hur snabbt språken är.

Jag gillar inte heller exceptions. Orsaken har inte att det är exceptions, utan för det blir så mycket kod.

Menar du att C++23 kommer vara ej bakåtkompatibel?

Jag gillar Java för marknaden gillar Java. Annars anser jag att man skriver rätt mycket kod i Java för att få något gjort. Bästa är MATLAB. Det är alltid EN rad kod för att lösa ett problem

Jag tycker Rust luktar väldigt B-språk. Alltså B som beta. Rust känns mer hippie och jag har inte sett att de stora företagen för ARM och AVR samt PIC börjar gå mot Rust. Snarare håller dom kvar sig vid C och C++ samt lite Java ibland.

| CPU: MMX 200 MHz Intel Pentium I| GPU: Voodo2 3dfx 8 Mb| RAM: SDRAM 32 Mb 133 Mhz | PSU: 3V fläkt 2W | Chassi: HP Vectra VE 5| Skärm: HP Ergo 1024| HDD: Toshiba 2033 MB | OS: Windows 95 B | Mus: HP |

Trädvy Permalänk
Medlem
Registrerad
Mar 2018
Skrivet av Yoshman:

Humor

Language

Time (sec)

Memory (MB)

C++

1.94

1.0

Rust

2.16

4.8

Java

4.03

513.8

Python

314.79

4.9

Java är snabbt, men en förutsättning för att Java ska kunna vara snabbt är att man har rejält med RAM att "offra". Har man skräpsamlare (som Java, Python, C#, Go och de flesta språk förutom C, C++ och Rust har) måste man göra ett val mellan minnes-hog eller relativt hög overhead. Java har valt det förra, Python det senare.

Vet du själv var de där siffrorna egentligen kommer ifrån? Din "Humor" länk innehåller visserligen den där tabellen men jag hittar ingen källa till den på sidan.

Det är bättre att titta på den riktiga källan till siffrorna https://github.com/mukshs/benchmarks Där ser man att tabellen du postade av någon anledning saknar det språk som var snabbast, Kotlin, vilket är ett jvm språk.

Jag har också valt ut några av de språken som diskuteras här:

Language

Time (sec)

Memory (MB)

Kotlin

1.78

28.4

C++ Gcc

1.94

1.0

Rust

2.16

4.8

C# .Net Core

3.40

8.7

Scala

3.43

120.12

Java

4.03

513.8

Go

5.54

0.9

Python PyPy

22.14

75.9

Python

314.79

4.9

Python3

412.13

5.5

Den här typen av tester har väldigt lite värde och siffrorna påverkas ofta av hur van personen som skriver testen är vid de olika språken osv. Man kan t.ex. titta på minnesanvändningen för de tre olika jvm språken, Kotlin 28, Scala 120, Java 514. Det handlar enbart om hur effektiv kod man skrivit i respektive språk och inte om hur mycket minne jvm som platform kräver. Båda tabellerna är alltså helt ointressanta.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av jclr:

Vet du själv var de där siffrorna egentligen kommer ifrån? Din "Humor" länk innehåller visserligen den där tabellen men jag hittar ingen källa till den på sidan.

Det är bättre att titta på den riktiga källan till siffrorna https://github.com/mukshs/benchmarks Där ser man att tabellen du postade av någon anledning saknar det språk som var snabbast, Kotlin, vilket är ett jvm språk.

Jag har också valt ut några av de språken som diskuteras här:

Language

Time (sec)

Memory (MB)

Kotlin

1.78

28.4

C++ Gcc

1.94

1.0

Rust

2.16

4.8

C# .Net Core

3.40

8.7

Scala

3.43

120.12

Java

4.03

513.8

Go

5.54

0.9

Python PyPy

22.14

75.9

Python

314.79

4.9

Python3

412.13

5.5

Den här typen av tester har väldigt lite värde och siffrorna påverkas ofta av hur van personen som skriver testen är vid de olika språken osv. Man kan t.ex. titta på minnesanvändningen för de tre olika jvm språken, Kotlin 28, Scala 120, Java 514. Det handlar enbart om hur effektiv kod man skrivit i respektive språk och inte om hur mycket minne jvm som platform kräver. Båda tabellerna är alltså helt ointressanta.

Att Java är minneshungrigt borde inte vara något som förvånar någon. Det har ofta nämnts att GC, i teorin, kan vara snabbare än manuell minneshantering. Det är faktiskt sant även i praktiken, förutsatt att man har oändligt med RAM!

Nu har man aldrig oändligt med RAM, det Java (eller specifikt, JVM:er optimerade för prestanda) göra så pass bra approximation av "oändligt med RAM" som är rimligt. Så det är egentligen inte Java i sig äter massor med RAM, utan Java-program som genererar "skräp" kommer blåsa upp sig rätt mycket RAM-mässigt då det leder till betydligt bättre prestanda.

När du tar med alla program, framförallt när även PyPy är med, syns det extra tydligt hur man kan optimera prestanda vs RAM-åtgång. PyPy presterar normalt sett riktigt bra, långt bättre än CPython.

Så är inte språket Java som ställer till det, utan det är hur man optimerar JVM. Alla JVM-språk är relativt RAM-hungriga, att Kotlin och Scala tar väsentligt mindre (men de tar fortfarande långt mer än språken som hanterar RAM manuellt samt CPython) kan bero av flera faktorer. T.ex. finns det argument till JVM samt då Kotlin och framförallt Scala har mer fokus på användning av "immutable" data löser man typiskt problem på ett annorlunda sätt där jämfört med Java.

Moderna JVM:er har i princip alltid något form av escape analysis, i just det här fallet kan det mycket väl förklarar hela skillnaden mellan Java, Kotlin och Scala. Lösningen i Kotlin kan ha resultera i bytekod som långt oftare kan nyttja optimeringen att allokera temporära objekt på stacken -> GC:n kommer inte "blåsa upp" sig lika mycket.

Finns faktiskt JVM-implementationer för IoT-system, dessa drar nog inte mer RAM än CPython (borde egentligen veta detta då jag använder CPython på embedded-system idag och har tidigare kört JVM för embedded system på samma OS, men körde inte Java tillräckligt mycket...), men de presterar inte heller i närheten av en typiskt JVM för servers!

I grunden handlar det om optimeringar för alla GC-språk, för de kommer alltid använda mer RAM om man löser ett problem på exakt samma sätt som i språk som har deterministisk minneshantering. I CPython är inte alls optimerat för prestanda + det länge använts i rätt svaga system. Så optimeringen där är att snåla med RAM. Och var egentligen bara det som det handlade om, CPython kommer i genomsnitt använda mindre RAM jämfört med Java, Kotlin, Scala, Clojure, Groovy eller något annat som kör på en JVM optimerad för prestanda (vilket är normalfallet då JVM-språken primärt är "back-end" språk idag).

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av heretic16:

Titta på benchmark istället. Där har du en väldigt bra källa på hur snabbt språken är.

Jag gillar inte heller exceptions. Orsaken har inte att det är exceptions, utan för det blir så mycket kod.

Jag gillar dem inte för att du kan inte, genom att enbart se signaturen av funktioner och hur de använts, avgöra hur man kommer ta sig igenom ett program.

Endera har man ett fel som är förväntat, i det läget borde returvärdet visa att man kan få ett resultat eller ett fel. Eller så ibland händer fel man inte kan/vill hantera, ett typfall är att disken blivit full, att RAM tagit slut eller man hamnat i ett "omöjligt" tillstånd. I det läget vill man bara skriva ut ett fel och avsluta programmet ("panic").

Exception leder ofta, men inte alltid (man diskutera en variant i C++ som skulle vara "gratis" prestandamässigt), något långsammare funktioner. Just detta är det överlägset minsta problem i min mening.

Skrivet av heretic16:

Menar du att C++23 kommer vara ej bakåtkompatibel?

Man diskuterar det.

Rent formellt är svaret "nej" oavsett vad man kommer fram till då man diskuterar att ändra något som påverkar ABI och C++-standarden definierar ingen ABI. I praktiken kommer svarat bli "ja" om man väljer att göra dessa ändringar, men det är långt ifrån säker att man i slutändan kommer göra (råder väldigt stor oenighet om vad som är rätt väg här).

Skrivet av heretic16:

Jag gillar Java för marknaden gillar Java. Annars anser jag att man skriver rätt mycket kod i Java för att få något gjort. Bästa är MATLAB. Det är alltid EN rad kod för att lösa ett problem

Jag tycker Rust luktar väldigt B-språk. Alltså B som beta. Rust känns mer hippie och jag har inte sett att de stora företagen för ARM och AVR samt PIC börjar gå mot Rust. Snarare håller dom kvar sig vid C och C++ samt lite Java ibland.

Med rätt bibliotek blir ju även alla C-program två rader...

#include <amazing_game.h> int main() { run_the_game(); }

Rust är ett väldigt ungt språk, det var ju i officiella "beta" fram till mitten av 2015.

Det som är unik med Rust, och orsaken till att Linux-gänget, Microsoft och även där jag jobbar (jobbar med en OS-kärna), är ett par saker

  • behöver ingen "runtime", går inte att skriva ett OS i ett GC språk då en GC kräver en "runtime" och OS är i praktiken alltid något en runtime behöver luta sig mot (cirkel-referens)

  • det har deterministisk minneshantering

  • trots "manuell" minneshantering går det inte att göra minnesläckor (sådana buggar genererar kompileringsfel)

  • det riktigt unika med Rust är att det inte går att göra s.k. data-race (sådana buggar genererar kompileringsfel) trots att man tillåter trådar dela data (Erlang kan inte heller ha data-race, men där kan man inte dela tillstånd mellan trådar -> löser problemet men är inte effektivt nog för de mest prestandakritiska applikationerna då det ger dålig CPU-cache-utnyttjande)

De två första egenskaperna har inte existerat i något språk som tagits fram sedan C++ (om man nu bara tittar på språk som fått något relevant spridning, finns massor med forskningsspråk och även icke-standardversioner av t.ex. Java med dessa egenskaper)

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Jan 2011
Skrivet av Lars Celander:

Python används ju mycket i AI-världen så det är nog en drivkraft för ökat användande. Tror inte att Python ersätter Java så mycket, dom har ju bägge sina nischer.

Kotlin är helt klart ersättaren till Java i Android-världen. Man kan blanda fritt i koden så Kotlin får nog anses vara default numera. Här blir Java ersatt och mycket av det drivs av Oracles svinerier.

Dart/Flutter är rätt väg för cross-platform Android/iOS, inte Javascript, men som alltid, om man inte måste vara cross-platform så är det bättre att köra native, alltså Kotlin. Cross-platform har sitt pris.

En svaghet med Python är att det inte skalar så bra på många kärnor. Julia är nog ett bättre val i den nischen. Swift/Kotlin/Dart är också generellt bättre än Java för att köras på många kärnor.

Python är även förbannat trevligt att köra på serverless tjänster. Har massor med Lambdas som kör på AWS på jobbet, väldigt trevligt att slippa mecka med servrar, hantera loggning, resursallkoering etc.

Gamla trotjänaren:Asrock P67 Extreme 4 | i5 2500K@4.5Ghz | Asus GTX 970 black Överklockad | Samsung Evo 960 1TB, 2x WD blue 5TB | 8GB Corsair XMS3 + 8GB Hyper x Fury | EVGA Supernova G2 750W Gold | Silverstone FT02
Laptop: Dell XPS 15 2017
Mobil: Oneplus 6 128GB

Trädvy Permalänk
Medlem
Plats
Västra götaland (Borås)
Registrerad
Sep 2012
Skrivet av Yoshman:

Jag gillar dem inte för att du kan inte, genom att enbart se signaturen av funktioner och hur de använts, avgöra hur man kommer ta sig igenom ett program.

Intressarad i vad du anser är en bra lösning på det problemet. Min personliga åsikt är att Haskell har minimerat det på ett sunt sätt, men du kanske vet någon bättre lösning? För jag håller helt med om att arbeta med exceptions för att hantera ett normalt dataflöde är dålig design, dessvärre så är det en design som är extremt utspridd i många språks standard och tredjeparts bibliotek. 😕 Språken i sig uppmanar även det till en rätt stor grad då du inte kan definera signaturen med specificitet nog för att compile-time valideras.

Kan låta oavsiktligt aggressiv.
Citera eller @philipborg om du vill att jag ska läsa dina svar.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av philipborg:

Intressarad i vad du anser är en bra lösning på det problemet. Min personliga åsikt är att Haskell har minimerat det på ett sunt sätt, men du kanske vet någon bättre lösning? För jag håller helt med om att arbeta med exceptions för att hantera ett normalt dataflöde är dålig design, dessvärre så är det en design som är extremt utspridd i många språks standard och tredjeparts bibliotek. 😕 Språken i sig uppmanar även det till en rätt stor grad då du inte kan definera signaturen med specificitet nog för att compile-time valideras.

Ett sätt är som Go löser det, man har helt enkelt multipla returvärden där ett av dem är felkod. Uppenbar nackdel: går precis som med exceptions att skita i felhantering och det kompilerar ändå gladeligen. Ändå en förbättring då det nu räcker att titta på signaturen för en funktion.

Annat sätt, som är närmare Haskell, är det Rust kör med: Enums kan associeras med data -> man har en Result<Error, Ok> typ. D.v.s Result är en enum med två giltiga värden, Error resp. Ok. Om man får tillbaka ett "Error" hamnar man i den arm som hanterar det fallet och man läser där ut det associerade värdet, hamnar man i "Ok" armen läser man ut det returvärde associerat där.

Ovanpå det går ju alltid att lägga på syntaktiskt socker för att "ignorera" fel som normal aldrig kommer ske. Detta kan då "ignoreras" på ett säkert sätt, d.v.s. om det oväntade ändå inträffar avslutas bara programmet (då man valt att inte hanterat felet). I Rust kan man göra detta genom att endera anropa metoden "unwrap()" eller numera också bara lägga på ett ? förutsatt att omgivande funktion också returnerar "Error<>".

// här kommer processen dödas om should_not_fail() trots allt ger ett "Error" värded let some_val = should_not_fail().unwrap();

// main() ger endera ingenting om allt går bra, eller så får man något form av I/O fel fn main() -> Result((), std::io::Error) { let val = should_not_fail()?; // man kommer bara hit om ovan inte ger ifrån sig något av typen "Error" // Om man får "Error" är det som att man direkt gör ett "return error_value" så nästa rad inte körs do_something_with(val); // allt gick bra, returnera Ok (som i detta fall är associerat med "ingenting"). Ok(()) } // går även att skriva motsvarande kan få "vilket fel som helst" så här // Box<T> betyder "T allokerad på heap" medan std::error::Error säger // vad som helst bara det implementerar kontraktet för ett standard fel fn main() -> Result((), Box<dyn std::error::Error>) { ...

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
NördCentrum
Registrerad
Jun 2011
Skrivet av Yoshman:

Ett sätt är som Go löser det, man har helt enkelt multipla returvärden där ett av dem är felkod. Uppenbar nackdel: går precis som med exceptions att skita i felhantering och det kompilerar ändå gladeligen. Ändå en förbättring då det nu räcker att titta på signaturen för en funktion.

Annat sätt, som är närmare Haskell, är det Rust kör med: Enums kan associeras med data -> man har en Result<Error, Ok> typ. D.v.s Result är en enum med två giltiga värden, Error resp. Ok. Om man får tillbaka ett "Error" hamnar man i den arm som hanterar det fallet och man läser där ut det associerade värdet, hamnar man i "Ok" armen läser man ut det returvärde associerat där.

Ovanpå det går ju alltid att lägga på syntaktiskt socker för att "ignorera" fel som normal aldrig kommer ske. Detta kan då "ignoreras" på ett säkert sätt, d.v.s. om det oväntade ändå inträffar avslutas bara programmet (då man valt att inte hanterat felet). I Rust kan man göra detta genom att endera anropa metoden "unwrap()" eller numera också bara lägga på ett ? förutsatt att omgivande funktion också returnerar "Error<>".

// här kommer processen dödas om should_not_fail() trots allt ger ett "Error" värded let some_val = should_not_fail().unwrap();

// main() ger endera ingenting om allt går bra, eller så får man något form av I/O fel fn main() -> Result((), std::io::Error) { let val = should_not_fail()?; // man kommer bara hit om ovan inte ger ifrån sig något av typen "Error" // Om man får "Error" är det som att man direkt gör ett "return error_value" så nästa rad inte körs do_something_with(val); // allt gick bra, returnera Ok (som i detta fall är associerat med "ingenting"). Ok(()) } // går även att skriva motsvarande kan få "vilket fel som helst" så här // Box<T> betyder "T allokerad på heap" medan std::error::Error säger // vad som helst bara det implementerar kontraktet för ett standard fel fn main() -> Result((), Box<dyn std::error::Error>) { ...

Jag skulle inte likaställa ? och .unwrap() på det viset. .unwrap() ignorerar fel, ja, och är bättre än unchecked exceptions i det att ignoreringen blir explicit och går att söka efter. ? operatorn å andra hand ignorerar inte felet, utan skickar det vidare. Föräldern måste sen i sin tur hantera felet eller skicka det ytterligare vidare -- men det måste hanteras någonstans.

Gibb: Win10 - Ryzen 5 3600 - RX 580 - 16G 3000MHz DDR4
Server: Arch - 2 * Xeon X5570 - R9 280X - 32G DDR3 ECC

Trädvy Permalänk
Medlem
Registrerad
Mar 2018
Skrivet av Yoshman:

Att Java är minneshungrigt borde inte vara något som förvånar någon. Det har ofta nämnts att GC, i teorin, kan vara snabbare än manuell minneshantering. Det är faktiskt sant även i praktiken, förutsatt att man har oändligt med RAM!

Nu har man aldrig oändligt med RAM, det Java (eller specifikt, JVM:er optimerade för prestanda) göra så pass bra approximation av "oändligt med RAM" som är rimligt. Så det är egentligen inte Java i sig äter massor med RAM, utan Java-program som genererar "skräp" kommer blåsa upp sig rätt mycket RAM-mässigt då det leder till betydligt bättre prestanda.

När du tar med alla program, framförallt när även PyPy är med, syns det extra tydligt hur man kan optimera prestanda vs RAM-åtgång. PyPy presterar normalt sett riktigt bra, långt bättre än CPython.

Så är inte språket Java som ställer till det, utan det är hur man optimerar JVM. Alla JVM-språk är relativt RAM-hungriga, att Kotlin och Scala tar väsentligt mindre (men de tar fortfarande långt mer än språken som hanterar RAM manuellt samt CPython) kan bero av flera faktorer. T.ex. finns det argument till JVM samt då Kotlin och framförallt Scala har mer fokus på användning av "immutable" data löser man typiskt problem på ett annorlunda sätt där jämfört med Java.

Moderna JVM:er har i princip alltid något form av escape analysis, i just det här fallet kan det mycket väl förklarar hela skillnaden mellan Java, Kotlin och Scala. Lösningen i Kotlin kan ha resultera i bytekod som långt oftare kan nyttja optimeringen att allokera temporära objekt på stacken -> GC:n kommer inte "blåsa upp" sig lika mycket.

Finns faktiskt JVM-implementationer för IoT-system, dessa drar nog inte mer RAM än CPython (borde egentligen veta detta då jag använder CPython på embedded-system idag och har tidigare kört JVM för embedded system på samma OS, men körde inte Java tillräckligt mycket...), men de presterar inte heller i närheten av en typiskt JVM för servers!

I grunden handlar det om optimeringar för alla GC-språk, för de kommer alltid använda mer RAM om man löser ett problem på exakt samma sätt som i språk som har deterministisk minneshantering. I CPython är inte alls optimerat för prestanda + det länge använts i rätt svaga system. Så optimeringen där är att snåla med RAM. Och var egentligen bara det som det handlade om, CPython kommer i genomsnitt använda mindre RAM jämfört med Java, Kotlin, Scala, Clojure, Groovy eller något annat som kör på en JVM optimerad för prestanda (vilket är normalfallet då JVM-språken primärt är "back-end" språk idag).

Det här handlar mer om hur viktigt det är att vara källkritisk än något tekniskt.
När man ser siffror som de du du rödmarkerade så är det helt uppenbart att det är något konstigt på gång. Den riktiga källan till siffrorna är enkel att hitta med en sökning och då blir det tydligt att sidan du länkar till som "Humor" valt bort resultat som inte stämmer med " But as the benchmarks below show, it is generally believed that Rust performs on par with C++. And performs much better than other interpreter or JIT based languages.." Snabbaste resultatet Kotlin passade helt enkelt inte in i den bild man ville förmedla.
Här är lite nyare resultat från vad som ser ut att vara ungefär samma test https://github.com/kostya/benchmarks

Language

Time (sec)

Memory (MiB)

Kotlin

2.02 ± 00.03

39.50 ± 00.17

Java

2.86 ± 00.16

38.47 ± 00.11

Rust

3.40 ± 00.07

2.11 ± 00.05

Ungefär samma minnesförbrukning för Java och Kotlin vilket stämmer med vad man kan förvänta sig. Siffrorna i sig är relativt ointressanta eftersom testen fortfarande är dålig. Det finns ingen anledning till att försöka hitta på en massa tekniska förklaringar till siffrorna i första testen när det är så uppenbart att något inte stämmer (dålig kod/mätfel osv.)

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av jclr:

Det här handlar mer om hur viktigt det är att vara källkritisk än något tekniskt.
När man ser siffror som de du du rödmarkerade så är det helt uppenbart att det är något konstigt på gång. Den riktiga källan till siffrorna är enkel att hitta med en sökning och då blir det tydligt att sidan du länkar till som "Humor" valt bort resultat som inte stämmer med " But as the benchmarks below show, it is generally believed that Rust performs on par with C++. And performs much better than other interpreter or JIT based languages.." Snabbaste resultatet Kotlin passade helt enkelt inte in i den bild man ville förmedla.
Här är lite nyare resultat från vad som ser ut att vara ungefär samma test https://github.com/kostya/benchmarks

Language

Time (sec)

Memory (MiB)

Kotlin

2.02 ± 00.03

39.50 ± 00.17

Java

2.86 ± 00.16

38.47 ± 00.11

Rust

3.40 ± 00.07

2.11 ± 00.05

Ungefär samma minnesförbrukning för Java och Kotlin vilket stämmer med vad man kan förvänta sig. Siffrorna i sig är relativt ointressanta eftersom testen fortfarande är dålig. Det finns ingen anledning till att försöka hitta på en massa tekniska förklaringar till siffrorna i första testen när det är så uppenbart att något inte stämmer (dålig kod/mätfel osv.)

Fast exakt vad som mäts här spelar ingen roll. "Humor" refererar specifikt till
"Noll fokus på kvalité och CPU och RAM har en pythonprogrammare ej tänkt på."

D.v.s. humorn kommer av att det skulle vara något CPython inte tänkt på när det ställs mot Java, som i normalfallet "by design", äter lika mycket eller mer RAM som CPython!

Inte för att någon egentligen är är sämre, utan därför att den typiska optimeringspunkten för JVMs är "back-end" vilket betyder att man tillåter relativ hög RAM-använding för att få bättre prestanda.

CPython har definitivt tänkt på just RAM delen, men man har valt en annan optimeringspunkt, sämre prestanda men betydligt närmare "ideal" RAM-åtgång. Exakt samma kod kommer dra väsentligt mycket mer RAM med PyPy, bara för att man där valt en annan optimeringspunkt för runtime!

Egentligen var det jag länkade i sig helt irrelevant, mer än att det råkade illustrera ovan i konkreta siffror. Kikade på källkoden, faktum är att det känns märkligt att det skiljer så mycket i just det där exemplet. Fallen som kommer skilja rejält är där man skapar en hel del "skräp", policy för hur det samplas ihop är rejält olika för CPython och typiska JVM-implementationer. Men det är bara en policy, inget fundamental i något av språken.

Just exemplet jag tog kan också användas för att visa hur lite mikrobenchmarks faktiskt säger. Tittar man i C koden inser man att lika gärna kan kompilera det hela med "fast-math" (man använder inga finesser som inte finns när "fast-math" är påslaget), i det läget blir helt plötsligt C versionen mer än dubbelt så snabb! (så en riktigt typisk "mikrobenchmark", blir inte i närheten sådan utväxling i "verkliga" fall).

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Entusiast
Testpilot
Plats
Göteborg
Registrerad
Aug 2011
Skrivet av Yoshman:

Ett sätt är som Go löser det, man har helt enkelt multipla returvärden där ett av dem är felkod. Uppenbar nackdel: går precis som med exceptions att skita i felhantering och det kompilerar ändå gladeligen. Ändå en förbättring då det nu räcker att titta på signaturen för en funktion.

Den andra nackdelen med detta är att det är lätt att klanta till saker utan att kompilatorn har en chans att upptäcka det. Exempelvis kan man råka returnera ett korrekt resultat och ett fel, eller inget vettigt resultat (nil) men ändå inget fel (också nil). Det är även lätt att råka returnera fel fel. Allt detta förstärks av att variabler som representerar fel tydligen bara får heta err i idiomatisk Go.

Löste faktiskt för inte så längesedan en allvarlig bugg i Helm som var en direkt följd av hur felbenägen felhantering i Go kan vara. Läste man koden snabbt, eller inte var så van vid Go, kunde man lätt tro att allt var som det skulle, men i själva verket ignorerades en viss klass av fel helt.