mboost-dp1

The State of Developer Ecosystem 2021


Gå til bund
Gravatar #1 - arne_v
18. jul. 2021 01:28
JetBrains har udgivet deres årlige survey resultat:

https://www.jetbrains.com/lp/devecosystem-2021/
Gravatar #2 - arne_v
18. jul. 2021 01:32
#1

Min summary:

Used language:

JavaScript 69%
Python 52%
Java 49%
PHP 32%
TypeScript 29%
C++ 23%
C# 21%
C 19%
Go 17%
Kotlin 14%

Primary language:

JavaScript 39%
Java 32%
Python 29%
PHP 22%
TypeScript 13%
C# 12%
C++ 11%
Go 8%
Kotlin 7%
C 5%

Most likely future primary language change:

JavaScript: TypeScript, Go, Python
Java: Kotlin, Go
Python: Go, Kotlin
PHP: Go, TypeScript, Python
TypeScript: Go, Rust
C#: Go
C++: Kotlin, Go, Rust
Go: Rust
Kotlin: Go

(nogle af disse skift må inkludere et skift af applikations type!)

NB: resultatet er formentligt påvirket af hvilke produkter JetBrains har og derfor hvilke udviklere de er i kontrakt med.
Gravatar #3 - larsp
18. jul. 2021 11:17
Når javascript (og relateret) feberen køler ned, hvad bliver mon det næste hotte sprog?

Så godt er javascript altså heller ikke. Det forekommer mig temmelig rodet og ukonsekvent sammenlignet med f.eks. python. Tag f.eks. løkker hvor man nogle gange er nød til at lave C-style for (i = 0; i < len(something); i++), nogle gange kan bruge forEach og en lambda funktion, og nogle gange for ( of ). Rodet. Og hvordan deklarerer man mutable og immutable i javascript? Hurtige js-motorer er nød til at bruge meget avanceret sort magi for at finde ud af hvordan koden kan eksekveres bedst muligt. Typescript hjælper enormt meget, men er når det kommer til stykket kun en lap på javascript.

(edit: man kan selvfølgelig bruge const til at specificere immutable)
Gravatar #4 - Claus Jørgensen
18. jul. 2021 13:14
#3

Det handler mere om ecosystem end sprog. Python's package manager (pip) er elendig, python's versioning er elendig (og mangler noget ala. nvm), og Python har concurrency problemer.

Derudover hvis du synes for(;;) vs. foreach vs. for of er et rodet, så vil jeg begynde at tvivle på dine programmeringsevner :p
Gravatar #5 - larsp
18. jul. 2021 15:08
#4 Der er faktisk også for ( in ). Jeg har kun brugt js/ts i hobbyprojekter og har ikke noget ego på spil her, så jeg er da lidt interesseret i at høre fra herrrr programeringsguru hvad relevansen er for fire måder at iterere på? Python har kun én. Spørgsmålet handler ikke om alle mulige andre aspekter ved sprog og økosystemer.
Gravatar #6 - larsp
18. jul. 2021 15:19
Jeg er iøvrigt enig i at python er grundlæggende et scriptsprog der har vokset sig for stort. Det er ikke et robust sprog til store projekter, men bliver i stigende grad brugt til dette.

#4 Hvad mener du med concurrency problemer? Python threading giver mulighed for lightweight threads som faktisk har nogle unikke fordele, og python multiprocessing giver mulighed for ægte multithreading. Igen. Det er noget der kan være smart i en hurtig vænding i scripts og mindre projekter. Det er ikke rigtig industrial strength IMO.
Gravatar #7 - Claus Jørgensen
18. jul. 2021 16:48
#5

Python næsten har ligeså mange som JavaScript. https://book.pythontips.com/en/latest/map_filter.h... -- men syntaxen for lambdas i python er horribel.

Og for(;;) problemet er jo løst med et enumerate() "hack" i python: https://stackoverflow.com/questions/522563/accessi...
Gravatar #9 - arne_v
18. jul. 2021 20:56
larsp (6) skrev:

#4 Hvad mener du med concurrency problemer? Python threading giver mulighed for lightweight threads som faktisk har nogle unikke fordele, og python multiprocessing giver mulighed for ægte multithreading. Igen. Det er noget der kan være smart i en hurtig vænding i scripts og mindre projekter. Det er ikke rigtig industrial strength IMO.


Python eller mere præcist mange Python implementationer heriblandt standard CPython har et concurrency problem eller mere præcist et threading problem.

Python threading virker logisk set som threading i andre sprog, men p.g.a. GIL er der kun 1 tråd der kan eksekvere Python kode af gangen. En ren Python beregning vil ikke køre hurtigere med 16 tråde på en 16 core CPU end 1 tråd på en 1 core CPU. Der er stadig store fordele ved threading hvis man har en masse tråde som er blocked p.g.a. IO.

Python multi-processing er ikke multi-threading. Den starter processer op med hver sin kopi af Python. Det gør at de kan køre ægte parallelt idet hver Python har sin egen GIL. Men der er mere overhead ved at starte en process end en tråd (specielt på non-nix OS som ikke har en effektiv fork) og der er mere overhead ved kommnikation mellem processerne som nødvendigvis bliver IPC.




Gravatar #10 - arne_v
18. jul. 2021 21:28
#3

Jeg tvivler på at JavaScript bliver erstattet af noget andet i nærmeste/mellemste fremtid.

På client side er situationen:
- der er meget eksisterende JS kode og der er mange udviklere med JS skills
- det er meget svært at få en ny runtime ind i browserne (jeg tror ikke at WebAssembly vil kunne tage over)

Så der er ikke nogen reel konkurrence til JS.

Og så er det ligegyldigt at:
* JS ikke er type sikker
* at sproget bærer præg af at have udviklet sig fra et formål (små script snippets) til noget andet (store client side applikationer)
* at JS frameworks har en meget kort levetid

Man lever med ulemperne eller finder workarounds (TS etc.).

For server side kode så er node.js hot lige nu, men moden kunne ændre sig om nogle år. Men jeg kunne nu godt forestille mig at node.js vil vise sig langtidsholdbar.

Årsag:
* client side udbredelse sikrer udviklere, libraries og tools
* fundamental sund arkitektur
og så lever man igen med sproget.



Gravatar #11 - arne_v
18. jul. 2021 21:37
#4

Jeg tror godt at folk kan leve med pip og virtual environments. Det virker fint for de fleste.

Men GIL sucks.

Og strengt taget er indrykning til kode struktur vel ikke optimalt.

Men hvilket sprog kan afløse det??

Python kode er kort (lav LOC/FP). De fleste traditionelle sprog (C++, Java, C# etc.) kræver langt flere linier tild et samme og er derfor diskvalificeret. PHP er for web centric.

Hvad er der så af muligheder?

Der dem som mener at Julia kunne være en afløser for Python. Men intet er givet idag.

Disclaimer: jeg kan ikke programmere i Julia, så jeg kan ikke selv vurdere.

Gravatar #12 - Claus Jørgensen
18. jul. 2021 22:45
#11

Python som erstatning for Perl, ja der ser jeg heller ikke så mange andre muligheder (Ruby er en, men Ruby har stort set alle de samme problemer som Python)

Swift er en mulighed på Apple platforme.

JavaScript er faktisk også fint, jeg bruger det mere og mere til batch job scripting (simple parsing etc.)
Gravatar #13 - arne_v
18. jul. 2021 23:35
#12

JS er fint til det formål.

Jeg har leget lidt med JS som script sprog på VMS. JS på JVM så jeg kan bruge JDBC, JPA etc. men stadig JS.
Gravatar #14 - arne_v
19. jul. 2021 00:30
#for

Der er vel 5 forskellige typer løkker:

1) generel top test (while loop)
2) generel bund test (do while loop i C familien, repeat until loop i Pascal familien)
3) generel vilkårlig test (meget sjælden - jeg kender kun 2 sprog med den: Modula-2 og TPU, men den kan altid emuleres med en uendelig løkke og en conditional break)
4) index (Pascal for loop, Fortran do loop, Basic for loop)
5) iteration (foreach i mange sprog men for i andre)

#5 kan så ofte laves implicit via metode på iterabelt objekt, men de er en detalje.

Bemærk at C familie for loop funktionsmæssigt er en #1 løkke ikke en #4 løkke. Det er bare sådan at idiomatisk brug af den er en #4 løkke.

De herrer K&R skulle aldrig have kommet op med sådan en kontrol struktur, men det gjorde de og en masse sprog har arvet den.

Gravatar #15 - arne_v
19. jul. 2021 00:37
arne_v (14) skrev:
1) generel top test (while loop)
...
4) index (Pascal for loop, Fortran do loop, Basic for loop)
...
Bemærk at C familie for loop funktionsmæssigt er en #1 løkke ikke en #4 løkke. Det er bare sådan at idiomatisk brug af den er en #4 løkke.

De herrer K&R skulle aldrig have kommet op med sådan en kontrol struktur, men det gjorde de og en masse sprog har arvet den.


Og hvis nogen undrer sig over hvad jeg fabler om, så 2 eksempler.


#include <stdio.h>

int main()
{
int i;
for(i = 0; i < 10; i++)
{
printf("%d\n", i);
}
return 0;
}



#include <stdio.h>

int main()
{
FILE *fp1, *fp2;
for(fp1 = fopen("z.1", "r"), fp2 = fopen("z.2", "w"); !feof(fp1); fputc(fgetc(fp1), fp2));
return 0;
}

Gravatar #16 - larsp
19. jul. 2021 07:13
@concurrency Jep, tråde startet med Thread() i CPython slås om GIL og vil ikke speede CPU begrænset python kode op. Men f.eks. numpy operationer kan køre parallelt med disse tråde fordi GIL ikke holdes hele tiden. Og ja, med multiprocessing forkes hele programmet i flere processer og man må bruge tricks for at dele variable, f.eks. multiprocessing.Manager().dict().

Men der er mig bekendt ikke et concurrency *issue* i den forstand at man kan komme galt af sted og lave ulykker, mere end ved andre sprog. Man får bare ikke optimal performance. Python er iørvigt ekstremt langsomg og bør ikke bruges til CPU tung processering i første omgang.
Gravatar #17 - larsp
19. jul. 2021 07:18
#15 Ja, for konstruktionen i C kan misbruges horribelt, og er et af mange eksempler på nødvendigheden af disciplin hvis man vil skrive god C kode.
Gravatar #18 - larsp
19. jul. 2021 07:23
@løkker Min pointe var vedrørende simpel iteration over elementer i datastrukturer og ikke andre typer løkker og lambda konstruktioner.

I python er syntaksen altid: "for <var> in <iterable>". I js er det ikke så ensartet og hvad lige præcis for ( in ) og for ( of ) gør lyser ikke ligefrem ud af koden.

Ligesom forskellen på scope ved "var" og "let" heller ikke stråler ud af koden selv. Js er mindre intuitiv end f.eks. python.
Gravatar #19 - larsp
19. jul. 2021 07:53
arne_v (10) skrev:
For server side kode så er node.js hot lige nu, men moden kunne ændre sig om nogle år. Men jeg kunne nu godt forestille mig at node.js vil vise sig langtidsholdbar.

Årsag:
* client side udbredelse sikrer udviklere, libraries og tools
* fundamental sund arkitektur
og så lever man igen med sproget.

Jeg må sige at npm med package.json mv. er enormt smart og et stærkt værktøj til at håndtere dependencies.

Hver gang denne type værktøjer opfindes bliver de bedre og bedre, og npm løftede helt klart barren. Det tror jeg også er med til at gøre node.js populært.
Gravatar #20 - Claus Jørgensen
19. jul. 2021 08:14
#18

Ah, du er forvirret fordi at JavaScript kan itererer over både arrays og dictionaries.

for...of er array value iteration
for...in er dictionary key iteration
Gravatar #21 - arne_v
19. jul. 2021 12:51
larsp (16) skrev:

@concurrency Jep, tråde startet med Thread() i CPython slås om GIL og vil ikke speede CPU begrænset python kode op. Men f.eks. numpy operationer kan køre parallelt med disse tråde fordi GIL ikke holdes hele tiden.


Fordi numpy er native kode.

larsp (16) skrev:

Og ja, med multiprocessing forkes hele programmet i flere processer og man må bruge tricks for at dele variable, f.eks. multiprocessing.Manager().dict().


Jeg ved ikk eom det er tricks. Men det vil være en eller anden form for IPC.

Jeg synes at Queue er bekvem.

larsp (16) skrev:

Men der er mig bekendt ikke et concurrency *issue* i den forstand at man kan komme galt af sted og lave ulykker, mere end ved andre sprog. Man får bare ikke optimal performance. Python er iørvigt ekstremt langsomg og bør ikke bruges til CPU tung processering i første omgang.


Det er ikke et concurrency problem i den traditionelle betydning af thread unsafe kode.

arne_v (9) skrev:

Python eller mere præcist mange Python implementationer heriblandt standard CPython har et concurrency problem eller mere præcist et threading problem.

Gravatar #22 - arne_v
19. jul. 2021 13:14
larsp (17) skrev:

#15 Ja, for konstruktionen i C kan misbruges horribelt, og er et af mange eksempler på nødvendigheden af disciplin hvis man vil skrive god C kode.


Mine pointer var:
- at C for ikke er en Pascal for men en sær while
- at jeg synes at K&R skulle have lavet en mere normal for løkke

Mange af C's features er farlige men nødvendige for visse typer kode. Og dermed kan den farlige feature begrundes.

Men her er der tale om en sær feature som kan bruges til det samme som en mere traditionel for løkke eller til grim kode (som vel at mærke ikke er mere effektiv end pænere kode).


Gravatar #23 - Claus Jørgensen
19. jul. 2021 17:50
arne_v (15) skrev:


#include <stdio.h>

int main()
{
FILE *fp1, *fp2;
for(fp1 = fopen("z.1", "r"), fp2 = fopen("z.2", "w"); !feof(fp1); fputc(fgetc(fp1), fp2));
return 0;
}


Der må være bedre måder at skrive det samme kode på...

Jeg ville nok have skrevet det noget ala. dette her


FILE *p_file_read;
FILE *p_file_write;
int buffer;

p_file_read = fopen("z.1", "r");
p_file_write = fopen("z.2", "w");

while (!feof(p_file_read)) {
buffer = fgetc(p_file_read);
fputc(buffer, p_file_write);
}

return 0;
Gravatar #24 - arne_v
19. jul. 2021 19:27
#23

Det ville stort set alle.

(mange ældre C programmører ville vælge kortere fil navne end dig, men det er en detalje)

Men pointen er at en C for løkke er en forklædt while løkke.

for(a;b;c)
{
d
}

er det samme som:

a/,/;/
while(b)
{
d
c/,/;/
}
Gravatar #25 - arne_v
19. jul. 2021 19:32
arne_v (24) skrev:

(mange ældre C programmører ville vælge kortere fil navne end dig, men det er en detalje)


Og det er ikke kun fordi de har en hang til kompakt kode.

C99 definerer op til 63 tegn for interne navne og 31 tegn for eksterne navne, men C89 definerer kun op til 31 tegn for interne navne og 6 tegn for eksterne navne. Og visse K&R C definerede kun op til 6 tegn.

Gravatar #26 - Claus Jørgensen
19. jul. 2021 19:56
#25

6 character variable navne er altså fucked, intet under at C typisk ikke er læsbart.
Gravatar #27 - arne_v
20. jul. 2021 00:39
#26

Ja. 6 er et problem. Og det bliver ikke bedre af at C89 ikke garanterede case sensitivitet af eksterne navne på trods af at sproget som sådan er case sensitivt.
Gravatar #28 - arne_v
20. jul. 2021 01:08
#27

Eksempel:

$ type m.c
void someFUNC();
void SOMEfunc();

int main()
{
someFUNC();
SOMEfunc();
return 0;
}
$ type f1.c
#include <stdio.h>

void someFUNC()
{
printf("someFUNC\n");
}
$ type f2.c
#include <stdio.h>

void SOMEfunc()
{
printf("SOMEfunc\n");
}
$ cc m

void SOMEfunc();
.....^
%CC-W-DUPEXTERN, The declaration of "SOMEfunc" will map to the same external name as the declaration of "someFUNC" at line number 1
in file DISK2:[ARNE]m.c;1.
at line number 2 in file DISK2:[ARNE]m.c;1
$ cc f1
$ cc f2
$ link m + f1 + f2
%LINK-W-WRNERS, compilation warnings
in module M file DISK2:[ARNE]m.OBJ;2
%LINK-W-MULDEF, symbol SOMEFUNC multiply defined
in module F2 file DISK2:[ARNE]f2.OBJ;2
$ run m
someFUNC
someFUNC
$ cc/name=as_is m
$ cc/name=as_is f1
$ cc/name=as_is f2
$ link m + f1 + f2
$ run m
someFUNC
SOMEfunc
Gravatar #29 - larsp
20. jul. 2021 08:56
Claus Jørgensen (20) skrev:
#18

Ah, du er forvirret fordi at JavaScript kan itererer over både arrays og dictionaries.

for...of er array value iteration
for...in er dictionary key iteration

Sjovt som du altid skal kommentere mine programmeringsevner. Jeg synes det er mere interessant at diskutere forskellige sprog og deres egenskaber. Javascript bryder helt klart med principle of least surprise her fordi "in" og "of" ikke kommunikerer ret godt hvad der foregår, ligesom "var" og "let" heller ikke gør. Andre sprog har tilsvarende features uden den slags gotcha'er.
Gravatar #30 - larsp
20. jul. 2021 08:59
arne_v (22) skrev:
Mine pointer var:
- at C for ikke er en Pascal for men en sær while
- at jeg synes at K&R skulle have lavet en mere normal for løkke

Mange af C's features er farlige men nødvendige for visse typer kode. Og dermed kan den farlige feature begrundes.

Men her er der tale om en sær feature som kan bruges til det samme som en mere traditionel for løkke eller til grim kode (som vel at mærke ikke er mere effektiv end pænere kode).

Jeg er enig og man sidder tilbage og undres over at denne for (;;) konstruktion er blevet båret videre til så mange af de nyere sprog med C style syntax.
Gravatar #31 - Claus Jørgensen
20. jul. 2021 09:24
larsp (29) skrev:
Sjovt som du altid skal kommentere mine programmeringsevner.
Du viser ikke ligefrem stor erfaring med forskellige sprog, mens at du samtidigt kritisere dem :p

larsp (29) skrev:
Javascript bryder helt klart med principle of least surprise her fordi "in" og "of" ikke kommunikerer ret godt hvad der foregår, ligesom "var" og "let" heller ikke gør. Andre sprog har tilsvarende features uden den slags gotcha'er.
Python kræver brug af range() for at lave indexed iterations

Det er hvad jeg kalder en gotcha.

Der er ingen perfekte sprog (dog kommer Swift meget tæt på imo.), men jeg sætter altså Python/Ruby/Javascript side om side i "wtf" moments.
Gravatar #32 - larsp
20. jul. 2021 09:50
Claus Jørgensen (31) skrev:
Du viser ikke ligefrem stor erfaring med forskellige sprog, mens at du samtidigt kritisere dem :p

Og? Man lærer en masse når man går ud af ens comfortzone.
Claus Jørgensen (31) skrev:
Der er ingen perfekte sprog (dog kommer Swift meget tæt på imo.), men jeg sætter altså Python/Ruby/Javascript side om side i "wtf" moments.

Python er for mig væsentlig mere intuitivt en javascript. Se bare de mærkværdige konstruktioner (eller hacks) der blev brugt til at lave klasser og objekter i klassisk javascript. Men nyere ECMA standarder hjælper da bestemt på det.

Apropos løkker. Har nyere sprog ikke efterhånden fået metoder til at skrive løkker der bliver automatisk og smertefrit paralleliseret? Synes jeg læste om det en del år siden. C#? Java? Andre?
Gravatar #33 - Claus Jørgensen
20. jul. 2021 10:28
#32

Parallel.ForEach i C# har eksisteret i snart et årti.

Men problemet var jo aldrig at parallelisere løkker. Det var at vente på at de alle sammen blev færdige.

Promises er en populær måde at løse det på i JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaS...

Og Combine i Swift har samme funktionalitet https://developer.apple.com/documentation/combine
Gravatar #34 - arne_v
20. jul. 2021 12:21
larsp (30) skrev:
arne_v (22) skrev:
Mine pointer var:
- at C for ikke er en Pascal for men en sær while
- at jeg synes at K&R skulle have lavet en mere normal for løkke

Mange af C's features er farlige men nødvendige for visse typer kode. Og dermed kan den farlige feature begrundes.

Men her er der tale om en sær feature som kan bruges til det samme som en mere traditionel for løkke eller til grim kode (som vel at mærke ikke er mere effektiv end pænere kode).

Jeg er enig og man sidder tilbage og undres over at denne for (;;) konstruktion er blevet båret videre til så mange af de nyere sprog med C style syntax.


Det er mit indtryk at når designerne af nye sprog i perioden fra sidst i 80erne til først i 00erne skulle designe kontrol-strukturer bevidstløst valgte at kopiere fra C.

for løkken er et eksempel. Et andet eksempel er switch case fall through. Der findes ganske få eksempler hvor det er nyttigt, men ikke nok til opveje risikoen for fejl. Det var først C# som fik det stoppet.
Gravatar #35 - arne_v
20. jul. 2021 18:37
Claus Jørgensen (33) skrev:
#32

Parallel.ForEach i C# har eksisteret i snart et årti.


.NET 4.0 April 2010
Gravatar #36 - arne_v
20. jul. 2021 18:51
larsp (32) skrev:

Apropos løkker. Har nyere sprog ikke efterhånden fået metoder til at skrive løkker der bliver automatisk og smertefrit paralleliseret? Synes jeg læste om det en del år siden. C#? Java? Andre?


Der er to tilgange til problemet.

A)

Sætter direktiver omkring løkken som får compileren til at parallelisere.

Det er hvad OpenMP gør.

Fortran:

!$omp ...

C:

#pragma omp ...

Og det er ikke ny teknologi: Fortran 1997 og C 1998.

B)

Erstatte løkken med et metode kald hvor løkkens indhold sendes over som argument.

Det er tilgangen i de fleste nyere sprog.

C# fik Parallel.ForEach(something, ...) i 4.0 (2010). Bemærk at IEnumerable<T> ikke har en ForEach/For metode, så man kan ikke something.AsParallel().ForEach(...).

Java fik something.stream().parallel().forEach(...) i 1.8 (2014).

Scala har something.foreach(...).

Kotlin har something.forEach(...).
Gravatar #37 - arne_v
28. jul. 2021 23:32
larsp (16) skrev:

Python er iørvigt ekstremt langsomg og bør ikke bruges til CPU tung processering i første omgang.


Hvis du vil have mere fart på din Python kode så check GraalVM Python.

Jeg har et CPU test Python program med et totalt urealistisk sæt rene CPU beregninger.

[[email protected] graal]$ python3 py_test.py 10
6.28 million integer operations per second
6.30 million integer operations per second
6.31 million integer operations per second
6.31 million integer operations per second
6.31 million integer operations per second
6.32 million integer operations per second
6.32 million integer operations per second
6.31 million integer operations per second
6.32 million integer operations per second
6.39 million integer operations per second
6.63 million floating point operations per second
6.57 million floating point operations per second
6.53 million floating point operations per second
6.45 million floating point operations per second
6.56 million floating point operations per second
6.47 million floating point operations per second
6.57 million floating point operations per second
6.47 million floating point operations per second
6.58 million floating point operations per second
6.47 million floating point operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
0.77 million string operations per second
[[email protected] graal]$ ../graalvm-ce-java11-21.2.0/bin/graalpython py_test.py 10
7.34 million integer operations per second
10.85 million integer operations per second
217.39 million integer operations per second
212.77 million integer operations per second
181.82 million integer operations per second
256.41 million integer operations per second
178.57 million integer operations per second
212.77 million integer operations per second
178.57 million integer operations per second
212.77 million integer operations per second
5.83 million floating point operations per second
25.00 million floating point operations per second
38.31 million floating point operations per second
38.02 million floating point operations per second
38.61 million floating point operations per second
41.84 million floating point operations per second
181.82 million floating point operations per second
166.67 million floating point operations per second
178.57 million floating point operations per second
178.57 million floating point operations per second
0.53 million string operations per second
0.53 million string operations per second
1.46 million string operations per second
1.46 million string operations per second
1.43 million string operations per second
1.42 million string operations per second
1.43 million string operations per second
1.43 million string operations per second
1.43 million string operations per second
1.43 million string operations per second
[[email protected] graal]$

Det er ligesom en forskel som vil noget.

Koden er ikke typisk for noget som helst, men måske vil der også være en forskel ved mere typiske koder.
Gravatar #38 - larsp
30. jul. 2021 07:38
#37 Blæret! Det ligner at VM efterhånden får optimeret hotspots og så kommer der fart på.

Det kunne være interessant at se de samme beregninger i et native kompileret sprog til sammenligning.
Gravatar #39 - arne_v
30. jul. 2021 11:58
#38

C:\Code\NativePerf>cl /D_CRT_SECURE_NO_DEPRECATE native_test.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30037 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

native_test.c
Microsoft (R) Incremental Linker Version 14.29.30037.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:native_test.exe
native_test.obj

C:\Code\NativePerf>native_test 10
64 bit
369.39 million integer operations per second
369.95 million integer operations per second
370.49 million integer operations per second
370.71 million integer operations per second
370.25 million integer operations per second
370.35 million integer operations per second
368.69 million integer operations per second
369.95 million integer operations per second
369.80 million integer operations per second
370.44 million integer operations per second
133.41 million floating point operations per second
133.38 million floating point operations per second
133.39 million floating point operations per second
133.38 million floating point operations per second
133.51 million floating point operations per second
133.34 million floating point operations per second
133.27 million floating point operations per second
133.33 million floating point operations per second
133.53 million floating point operations per second
133.49 million floating point operations per second
12.65 million string operations per second
12.65 million string operations per second
12.62 million string operations per second
12.73 million string operations per second
12.62 million string operations per second
12.61 million string operations per second
12.59 million string operations per second
12.67 million string operations per second
12.65 million string operations per second
12.66 million string operations per second

C:\Code\NativePerf>cl /D_CRT_SECURE_NO_DEPRECATE /O2 native_test.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30037 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

native_test.c
Microsoft (R) Incremental Linker Version 14.29.30037.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:native_test.exe
native_test.obj

C:\Code\NativePerf>native_test 10
64 bit
1049.91 million integer operations per second
1053.26 million integer operations per second
1052.01 million integer operations per second
1052.75 million integer operations per second
1052.01 million integer operations per second
1053.64 million integer operations per second
1051.74 million integer operations per second
1052.67 million integer operations per second
1052.44 million integer operations per second
1054.58 million integer operations per second
238.40 million floating point operations per second
238.17 million floating point operations per second
238.16 million floating point operations per second
237.81 million floating point operations per second
238.41 million floating point operations per second
238.27 million floating point operations per second
238.44 million floating point operations per second
237.68 million floating point operations per second
238.38 million floating point operations per second
237.76 million floating point operations per second
13.77 million string operations per second
13.66 million string operations per second
13.68 million string operations per second
13.73 million string operations per second
13.62 million string operations per second
13.73 million string operations per second
13.66 million string operations per second
13.74 million string operations per second
13.68 million string operations per second
13.73 million string operations per second

Gravatar #40 - arne_v
30. jul. 2021 14:41
#38

GraalVM er iøvrigt et underligt projekt.

What is GraalVM?
A) An OpenJDK build
B) A JVM JIT compiler written in Java (so that it actually JIT compiles itself)
C) A JVM capability to use the JIT compiler to do AOT compilation (similar to .NET NGEN)
D) A way to integrate Java byte code and LLVM intermediate code (bit code)
E) A script engine on top of JVM (similar to how MS a decade ago planned DLR on top of CLR)
F) A node.js implementation
G) A Python implementation
H) A Ruby implementation
I) All of the above

The correct answer is I.
Gravatar #41 - Claus Jørgensen
30. jul. 2021 14:45
#40

Det siger altså noget, at nogen fandt det nødvendigt og ikke totalt-gakkelak at finde på sådan et projekt.

Gravatar #42 - arne_v
30. jul. 2021 15:01
#41

Og det er Oracle der står bag det - selvom det er et open source projekt på Github.

Gravatar #43 - Claus Jørgensen
30. jul. 2021 15:13
#42

Ah, Oracle. Det forklare lidt galskaben.

De er vel så heavily invested i Java at der er umuligt for dem at køre noget som helst koden uden at det først går igennem noget Java miljø :D
Gravatar #44 - arne_v
30. jul. 2021 15:41
#43

Måske.

Men det er ikke Java teamet hos Oracle som laver det men et seperat team.

Og de inkluderede B og C i Oracle Java builds i Java 9 til 15, men fjernede det igen i 16.

Det markedsføres (Oracle sælger en supporteret version) heller ikke under Java brand.

Så mystisk.
Gravatar #45 - larsp
31. jul. 2021 10:04
Det er vel ikke unormalt at store firmaer med masser af ressourcer lancerer projekter der konkurrerer med deres egen eksisterende teknologi for at holde sig skarp og ikke sidde fast i fortiden med en masse legacy. GraalVM er sikkert tænkt som "den hellige gral" inden for runtime environments. Og den er open source. Man kan da ikke brokke sig.
Gravatar #46 - arne_v
31. jul. 2021 22:31
#45

Alle store amerikanske virksomheder bruger mange penge på research i ny teknologi.

Konkurrence med virksomhedens andre produkter kan godt være lidt farlig. Se f.eks. hvad der skete med CentOS.

Der er ingen grund til at brokke sig - dem der vil have gratis downloader CE versionen fra Github + og dem der vil betale for support køber EE versionen fra Oracle - begge typer kunder bør være tilfredse.
Gravatar #47 - arne_v
12. aug. 2021 16:50
Der er lige kommet en uddybning til .NET delen.

https://blog.jetbrains.com/dotnet/2021/08/12/the-n...

C# 9 : 30%
C# 8 : 50%
C# 7 : 39%
C# 6 : 27%
C# 5 : 27%

.NET Fx 1-4 : 62%
.NET Core 1-3 : 66%
.NET 5 : 33%
Gravatar #48 - iCBM
13. aug. 2021 05:59
javascript er noget skrald men det er lynhurtigt at kode noget op i

#40

jeg håber godtnok det skrald er mega optimeret

Gravatar #49 - iCBM
13. aug. 2021 06:06
larsp (30) skrev:
arne_v (22) skrev:
Mine pointer var:
- at C for ikke er en Pascal for men en sær while
- at jeg synes at K&R skulle have lavet en mere normal for løkke

Mange af C's features er farlige men nødvendige for visse typer kode. Og dermed kan den farlige feature begrundes.

Men her er der tale om en sær feature som kan bruges til det samme som en mere traditionel for løkke eller til grim kode (som vel at mærke ikke er mere effektiv end pænere kode).

Jeg er enig og man sidder tilbage og undres over at denne for (;;) konstruktion er blevet båret videre til så mange af de nyere sprog med C style syntax.

jeg ved ikke rigtigt... jeg syntes den konstruktion fungerer fint

#12

jeg har ikke leget ret meget med python men hvorfor skulle det erstatte perl? er det pga den "specielle" (nogle ville kalde det en svært læselige) syntax i perl?
Gravatar #50 - arne_v
13. aug. 2021 12:29
#49

Så du rædselen i #15?
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login