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

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.

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.

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.

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.

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.

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.)

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".

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).

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.

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).

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)

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.

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>) {
   ...

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).

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.