Přepsání serveru v Javě

[zboj]

Pokud je čas a chuť to přepsat do něčeho jiného a nebude vadit že to má někdo jiný udržovat, tak by byl hřích to nevyužít.
V tomto případě je Go nejlepší volba, protože je to jazyk (resp. "platforma") přesně pro tento účel.

Něco jiného je někde ve firmě, kde se řeší věci jako náklady nebo zastupitelnost. Tam pak platí, že by se mělo zjistit co je přesně špatně a podle toho pokračovat.

V Go to bude z obecných jazyků nejsnadnější. Kdo má chuť experimentovat, může ještě zkusit GCD, když už je verze v C.

[Reklama]

[kimec]

Než řešit výběr JVM, GC a nevím co ještě, to je fakt lepší to přepsat do něčeho moderního.

Pokud je čas a chuť to přepsat do něčeho jiného a nebude vadit že to má někdo jiný udržovat, tak by byl hřích to nevyužít.
V tomto případě je Go nejlepší volba, protože je to jazyk (resp. "platforma") přesně pro tento účel.

Něco jiného je někde ve firmě, kde se řeší věci jako náklady nebo zastupitelnost. Tam pak platí, že by se mělo zjistit co je přesně špatně a podle toho pokračovat.

V Go to bude z obecných jazyků nejsnadnější. Kdo má chuť experimentovat, může ještě zkusit GCD, když už je verze v C.

Presne tak, a kedze je Go uz zastarale, ja by som to pisal v Pony. Naco traposit s gorutinami, ked mozem mat plnohodnotnych aktorov?

[zboj]

Problém Javy je, že neumožňuje nějakou aspoň pseudotransparentní alokaci dat na zásobníku.

Ne, to problém Javy není.

Mělo by být pravidlem nepsat o něčem, čemu nerozumím. Courtesy of the rascal: http://www.infoworld.com/article/3202066/java/jvm-may-get-upgrade-to-support-todays-multicore-processors.html

[dustin]

Projekt Valhalla http://www.jesperdj.com/2015/10/04/project-valhalla-value-types/ už pár let běží, snad se jej dočkáme v javě 10. Rozhodně to bude užitečné, zpřísněním typování kódu (value types) i výkonově (právě např. jejich kolekce). Už aby byly...

[zboj]

Projekt Valhalla http://www.jesperdj.com/2015/10/04/project-valhalla-value-types/ už pár let běží, snad se jej dočkáme v javě 10. Rozhodně to bude užitečné, zpřísněním typování kódu (value types) i výkonově (právě např. jejich kolekce). Už aby byly...

Ano, tím by Java vstoupila (konečně) do 21. století. Ještě teda chybí typová inference, to je taky opruz, zvlášť když všichni významní konkurenti to mají.

[Reklama]

[Ondra Satai Nekola]

Projekt Valhalla http://www.jesperdj.com/2015/10/04/project-valhalla-value-types/ už pár let běží, snad se jej dočkáme v javě 10. Rozhodně to bude užitečné, zpřísněním typování kódu (value types) i výkonově (právě např. jejich kolekce). Už aby byly...

Ano, tím by Java vstoupila (konečně) do 21. století. Ještě teda chybí typová inference, to je taky opruz, zvlášť když všichni významní konkurenti to mají.

Java ji ma, jen ji ma malo. Pouziva se u diamondu.

A ano, je to skutecne jeden z podstatnych opruzu.

[zboj]

Projekt Valhalla http://www.jesperdj.com/2015/10/04/project-valhalla-value-types/ už pár let běží, snad se jej dočkáme v javě 10. Rozhodně to bude užitečné, zpřísněním typování kódu (value types) i výkonově (právě např. jejich kolekce). Už aby byly...

Ano, tím by Java vstoupila (konečně) do 21. století. Ještě teda chybí typová inference, to je taky opruz, zvlášť když všichni významní konkurenti to mají.

Java ji ma, jen ji ma malo. Pouziva se u diamondu.

A ano, je to skutecne jeden z podstatnych opruzu.

Ano, myslel jsem na úrovni konkurence. Hlavně že se shodneme. Osobně mě to teda už netrápí, protože za problém považuji hlavně molochovitost JVM, ale čistě z pohledu jazyka by stačila ta inference.

[Ladislav Thon]

Kromě Valhally bych si dovolil upozornit na následující:

Typová inference pro lokální proměnné: http://openjdk.java.net/jeps/286

Pattern matching: http://openjdk.java.net/jeps/305

Declaration-site variance: http://openjdk.java.net/jeps/300

[Kit]

Typová inference pro lokální proměnné: http://openjdk.java.net/jeps/286

K čemu je dobrá typová inference? Když místo "var" použiji název rozhraní, tak mám jistotu, že mohu s objektem přes toto rozhraní pracovat. Používání rozhraní ArrayList místo List považuji za hloupost.

[zboj]

Typová inference pro lokální proměnné: http://openjdk.java.net/jeps/286

K čemu je dobrá typová inference? Když místo "var" použiji název rozhraní, tak mám jistotu, že mohu s objektem přes toto rozhraní pracovat. Používání rozhraní ArrayList místo List považuji za hloupost.

Deklarovat proměnnou jako rozhraní je koncepční chyba, k tomu rozhrani neslouží (a implementačně to je přímo blbost, při statickém typování to s sebou nese zbytečný overhead).

[Ondra Satai Nekola]

Typová inference pro lokální proměnné: http://openjdk.java.net/jeps/286

K čemu je dobrá typová inference? Když místo "var" použiji název rozhraní, tak mám jistotu, že mohu s objektem přes toto rozhraní pracovat. Používání rozhraní ArrayList místo List považuji za hloupost.

Motas lokalni promenne, kde je to povetsinou celkem burt, a interface metod, kde to uz tak moc burt neni.

[Kit]

Typová inference pro lokální proměnné: http://openjdk.java.net/jeps/286

K čemu je dobrá typová inference? Když místo "var" použiji název rozhraní, tak mám jistotu, že mohu s objektem přes toto rozhraní pracovat. Používání rozhraní ArrayList místo List považuji za hloupost.

Motas lokalni promenne, kde je to povetsinou celkem burt, a interface metod, kde to uz tak moc burt neni.

U lokálních objektů přece také potřebuji znát rozhraní, abych věděl, které metody toho objektu mohu volat. Přece to nebudu dolovat reflexí.

[Ondra Satai Nekola]

Typová inference pro lokální proměnné: http://openjdk.java.net/jeps/286

K čemu je dobrá typová inference? Když místo "var" použiji název rozhraní, tak mám jistotu, že mohu s objektem přes toto rozhraní pracovat. Používání rozhraní ArrayList místo List považuji za hloupost.

Motas lokalni promenne, kde je to povetsinou celkem burt, a interface metod, kde to uz tak moc burt neni.

U lokálních objektů přece také potřebuji znát rozhraní, abych věděl, které metody toho objektu mohu volat. Přece to nebudu dolovat reflexí.

Aha, ty jsi ani nepochopil, co je to ta typova inference.

Kód: [Vybrat]

val foo = new Foo(bar);
foo je typu Foo. Rozdil je v tom, ze jsi nemusel Foo psat dvakrat, typ foo za tebe odvodil (inferoval) prekladac. Zadnou reflexi nepotrebujes.

Jeste doplnim: prirazovat muzes libovolny vyraz, ne jen tvorbu noveho objektu. A funguje to porad stejne

Kód: [Vybrat]

val baz = 1.1 * 1.2;

Kód: [Vybrat]

baz je double

[dustin]

Rozdil je v tom, ze jsi nemusel Foo psat dvakrat, typ foo za tebe odvodil (inferoval) prekladac.

Osobně dávám přednost uvedení typu proměnné, vidím ji na první pohled, narozdíl např. při přiřazení vrácené hodnoty metody.

Proměnnou včetně typu i přiřazení vyrobí IDE jednou klávesovou zkratkou, jen následně uvedu její název, přičemž mi často rovnou nabídne ten správný. Přijde mi, že na to má Idea nějakou heuristiku učící se z mého stylu pojmenování proměnných, protože se často trefuje hned první nabídkou.

Ukecanost javy při použití slušného IDE nijak nezdržuje.

[zboj]

Rozdil je v tom, ze jsi nemusel Foo psat dvakrat, typ foo za tebe odvodil (inferoval) prekladac.

Osobně dávám přednost uvedení typu proměnné, vidím ji na první pohled, narozdíl např. při přiřazení vrácené hodnoty metody.

Proměnnou včetně typu i přiřazení vyrobí IDE jednou klávesovou zkratkou, jen následně uvedu její název, přičemž mi často rovnou nabídne ten správný. Přijde mi, že na to má Idea nějakou heuristiku učící se z mého stylu pojmenování proměnných, protože se často trefuje hned první nabídkou.

Ukecanost javy při použití slušného IDE nijak nezdržuje.

  Někdo třeba považuje za slušné IDE vi.