Produktiv es hatekony szerver oldali programnyelv?

Produktiv es hatekony szerver oldali programnyelv?
2019-10-20T16:31:46+02:00
2019-10-25T18:50:44+02:00
2022-10-18T05:35:36+02:00
  • A js-el szemben sajnos fenntartásaim vannak... undorító egy olyan nyelv amiben nincs 64-bites egész szám. Jó, tudom... lassacskán lesz már...
    Mutasd a teljes hozzászólást!
  • Kényszer, elterjedt, tisztességes szabványok esetén működik

    Az értelmes dolgokra kényszerítés szerintem egy jó dolog egy projektben.

    Lehet eltérő platformok között is korrekt bináris adatcserét csinálni, lásd a Protobuf-ot.

    Lehet, de az szerintem nem ad validálást csak szerkezetet.

    de a a propertyk setterei pontos validációkat is csinálnak, az osztálypéldánynak az elemek közötti összefüggéseit és megszorításait vizsgáló validációk is működnek

    Ez oké, de szerintem semmi gond abban, hogy ezek különböző nyelvben azonos eredeti definícióból generálódnak.

    Vagy nem csak elemenként lehet az áthozott osztálypéldány mezőit módosítani, de rendelkezésre állnak azok a feltöltő függvények, amik a belső összefüggések betartásával módosítják az osztálypéldányt.

    Ez szintén generálható vagy mixin-elhető.

    Mióta alap hogy a kliensen is legyen vizsgálat és a szerver oldalon is, azóta ez egy azonos kódbázis nagy előny, hiszen az inkompatibilitás bölcsője a dupla implementálás, nem is szólva az időmegtakarításról

    Ha ezt tényleg kétszer kell implementálni az valóban dupla implementálás és időveszteség. Ha viszont ezt kétszer kell generálni egy definícióból akkor ugyanott tartunk, de 2 (vagy több) nyelvi környezet is támogatható konstans költséggel (a generátor megírása egy új nyelvre), ami konstans költség hosszú távon elamortizálódik.

    Értem amit mondasz, csak túl nagy árnak tartom, illetve bizonyos cégeknél ahol túl sok fejlesztő nem ért a közös nyelvhez nem működik a dolog.
    Mutasd a teljes hozzászólást!
  • Lehet, és néha elég is. Ezért írtam, hogy egy js kliens és asp.net szerver is simán jó kombó. De néha tényleg nem árt, ha tudsz komplett kódokat mozgatni a kliens és a szerver között, különösen mobilos kliens esetén.
    Mutasd a teljes hozzászólást!
  • Ennyire azért nem kell azonos technológia.

    Persze, nem kell, de nem is árt :)

    A szöveges adatcsere formátumokat nem szívlelem. Kényszer, elterjedt, tisztességes szabványok esetén működik, de akkor is egy kényszerpálya, szerintem az informatika tévútja.

    Lehet eltérő platformok között is korrekt bináris adatcserét csinálni, lásd a Protobuf-ot.

    De az adatcsere csak egy kis része a kommunikációnak.
    Annál nincs felemelőbb, ha egy osztálypéldánynak nem csak a tartalma megy át egyik gépről a másikra, de a a propertyk setterei pontos validációkat is csinálnak, az osztálypéldánynak az elemek közötti összefüggéseit és megszorításait vizsgáló validációk is működnek. Vagy nem csak elemenként lehet az áthozott osztálypéldány mezőit módosítani, de rendelkezésre állnak azok a feltöltő függvények, amik a belső összefüggések betartásával módosítják az osztálypéldányt. 

    Mióta alap hogy a kliensen is legyen vizsgálat és a szerver oldalon is, azóta ez egy azonos kódbázis nagy előny, hiszen az inkompatibilitás bölcsője a dupla implementálás, nem is szólva az időmegtakarításról.
    Mutasd a teljes hozzászólást!
  • Egyszerűen nincs biztosabb mód a kommunikáció adatstrukturáinak (és pl. az adatok validálásának) egységben tartására, mint ha teljesen azonos technologiát használsz mindkét oldalon.

    Ennyire azért nem kell azonos technológia.

    Elég ha valami szabványos sémadeklarációs módszet (pl. XML schema, JSON schema, schematron, stb.) használsz, és olyan validációs technológiát ami mindkét nyelven implementálva van vagy mindkét nyelvre generál validátort azonos forrás adat (expression-ök) alapján (amennyiben a sémadeklaráció típus/pattern/range/stb. validálási szabályainál bonyolultabbra van szükséged).

    Pl. XSD / JSON schema a sémadeklarációhoz, és valamilyen expression alapú validátor a plusz validációhoz.
    Mutasd a teljes hozzászólást!
  • De pont az a lényeg, ami miatt a node.js is létrejött, hogy a kliens/szerver nyelv közös lehessen, így a kódmegosztás problémamentes.
    És ez nem egyszerűen kényelmi kérdés. Egyszerűen nincs biztosabb mód a kommunikáció adatstrukturáinak (és pl. az adatok validálásának) egységben tartására, mint ha teljesen azonos technologiát használsz mindkét oldalon. Ha kétszer implementál az ember valamit, akkor garantáltan bevihet inkompatibilitást. 

    A "virágozzon száz virág" okán a JS-et nem legyőzni kell, hanem alternatívát teremteni neki, mert a monopolisztikus helyzet soha nem jó.
    Mutasd a teljes hozzászólást!
  • Konkrétan az idézett mondatoddal nem
    értek egyet, minden másban igen:

    Ez nem elsõsorban a Nadellán múlt

    Ballmer alatt indult az Azure, de az még Windows-központú volt, tehát igenis, pont Nadella volt az, aki kimozdította a Microsoftot a Windows központúságból.

    Ez merész és veszélyes lépés volt, és nagyon könnyen rosszul is elsülhetett volna, tisztelet érte neki, hogy ilyen jól
    levezényelte és ne vitassuk el az érdemeit.
    Mutasd a teljes hozzászólást!
  • Azt azért nem hiszem, hogy a blazor le fogja söpörni a színrõl a javascript alapú dolgokat, ehhez picit túl sok a javascripten felnõtt webfejlesztõ. Viszont így szépen le lehet majd fedni .NET-tel mindent, az üzleti appoktól a microservice-en át, a mobiltól a játékfejlesztésen át a webig.
    Persze ugyanezt a javascriptes is mondhatja, elvégre neki is van node.js-e, three.js-e, cocos studio-ja, és persze ma a web az övé.
    Mutasd a teljes hozzászólást!
  • Itt valóban nagy elõny, hogy simán tudok kódot ide-oda pakolni a szintek között, mert hogy a kliens xamarin, a middleware .net core, a felhõ pedig azúr.

    És mellé téve a Blazor koncepciót egyre kerekebb a világ :)

    Mintha felcsillanna némi esély, hogy valamilyen területen megint a MS legyen az úttörő, a vezérhím.
    Mutasd a teljes hozzászólást!
  • De ugye egy agyonfizetett csúcsvezetőtől elvárható az a munkaköri feladat, hogy átlássa azt amit a fél világ szaksajtója nyomat, hogy a hangsúly a PC-ről áthelyeződött a netre és mobil eszközökre, általános 'mindenen elfutó' alkalmazásokra?
    Mutasd a teljes hozzászólást!
  • Nadella szerintem csak megértette az idõk szavát. A MS nyilván eltökölhetett volna még pár évig a haldokló desktop árnyékában, de akkor úgy járnak mint az IBM akik szép csöndben kihalnak a széntüzelésû mainframe-ekkel. Pedig ha idõben kapcsolnak, azzal a tudással és kapacitással ami náluk volt, világelsõk lehettek volna a felhõ területén...
    Mutasd a teljes hozzászólást!
  • Valóban nem teljesen értem. Van a szerver oldal. Ez nyilván lehet egy szerver, lehet több, akár egy fürt, vagy lehet egy serverless megoldás is a felhõben. És lesz valamilyen kliens. Vagy több. Lehet egy .net-core-os szerver oldal mögé csinálni typescriptes angularos webes klienst, de kiszolgálhatsz nodejs-sel xamarin forms-os mobil appot is. Vagy lehet olyan szolgáltatásod pythonban, amit egy javás másik szolgáltatás használ fel, hogy aztán az egészet egy egyedileg megírt linuxos C++ progi használja egy beágyazott rendszerben. A lehetõségek korlátlanok, de itt a kérdezõ a szerver oldali nyelvre kérdezett rá, és gondolom általános üzleti jellegû dolgokat szeretne csinálni, és nem a galaxis korát akarja kiszámolni szerver oldalon. Mi köze ehhez annak, hogy kliensként mit és hogyan használ ? Ez max. akkor érdekes, ha meg akarsz osztani kódot a kliens és a szerver között. Erre elég ritkán van mód, de én speciel pont most épp egy ilyen rendszeren dolgozom: a mobilos kliens alapjában offline mûködik, de tud szinkronizálni egy közös szerverhez, ahol szintén van logika, és az is egy felhõbe, ahol szintén van egy másik logika, és itt lehet adatokat megosztani az egyes szintek között. Itt valóban nagy elõny, hogy simán tudok kódot ide-oda pakolni a szintek között, mert hogy a kliens xamarin, a middleware .net core, a felhõ pedig azúr.
    Mutasd a teljes hozzászólást!
  • Ha az adott nyelvre van egy szénné optimalizált, valamilyen alacsony szintû nyelvben megírt könyvtár amit az csak hívogat, akkor nyilván az is tud hatékony lenni, legalábbis addig a percig, amíg fõleg csak ennek a már kész könyvtárnak a függvényeit hívogatod. A gond akkor kezd lenni, ha nem.
    Mutasd a teljes hozzászólást!
  • Ez nem elsõsorban a Nadellán múlt szvsz, hanem azon, hogy ma már nem a windows a fõ platform, hanem az azúr.

    És ez szerinted kinek a döntése volt?

    Amikor Nadella jött, még Windows Azure volt a platform neve és a windowsazure.com címen lehetett elérni.
    Mutasd a teljes hozzászólást!
  • Szerintem legalább egyikünk nem értette meg a célzást 

    Ha szerver oldali fejlesztés a kérdés, akkor tuti biztos lesz hozzá egy kliens oldal. Az lesz, amilyenre tervezik. Egy személyes felhasználásnál egy kávédarálón elfut bármi kód, de ha millió felhasználó felé mész, már nem is egy szerver fog kelleni, hanem legalább 30+ tagú fürt. Minden egyes alkalmazás feature pénzben számítható költséggel fog járni az üzemeltetés miatt. A kliens oldal választása nem kérdés lesz, hanem a feladat, hogy olyan kliens, ami a legköltséghatékonyabb üzemeltetést biztosítani tudja.

    És a vége úgyis mindig a kassza. Billió alkalmazás van már, aminek a világ nem azért nem szavazott bizalmat, mert ne lenne jó ötlet, vagy ne lenne szükség rá, hanem mert az üzemeltetést nézték be a hitvita-kóros fejlesztői ahelyett, hogy kiszámolták volna az üzleti matekot.
    Mutasd a teljes hozzászólást!
  • Általános implementációkban, csak a saját alap nyelvi elemeit felhasználva valóban lassú. Egyszer egy rekurzív algoritmust írtam át pythonból Javára, kb. dupla olyan mèlysègig elèrtem ugyanazzal az erőforrással. Viszont mátrix műveletekben egy numpy vagy akár egy Floyd gráf algoritmus a megfelelő libekkel simán hozza a Java szintet. Mondjuk ezek alapvetően C-ben vannak implementálva.
    Mutasd a teljes hozzászólást!
  • Õszintén szólva nemigen pythonoztam még felhőben, és én azúrban felhőzök és nem aws-ben, viszont ez alapján picit kétlem, hogy a pythont bármilyen környezetben a sebességéért szeretjük. Persze pythonból van elég sok implementáció...
    Mutasd a teljes hozzászólást!
  • Gyors googleval itt egy benchmark:
    Comparing AWS Lambda performance of Node.js, Python, Java, C# and Go

    Nyilván van több is. Amúgy Python is tele van high performance package-el. Numpy, pandas, vagy akár a tensorflow is. Aztán ott van a pypy ami arra lett kitalálva hogy a Pythonból egy elfogadható teljesítményt hozzon ki. Itt mondjuk a serverless kompatibilitás már kèrdèsesebb.
    De tènyleg azon múlik hogy mit szeretne valaki csinálni. Ha nem milliós nagyságrendű kèrèsek jönnek, akkor framework nèlkül a sebessèg ès a memória használat is ugyanolyan lesz. Ha megy nagyobbat szeretne valaki számolni azt úgysem functionbe/lambdaba teszi.
    Mutasd a teljes hozzászólást!
  • Léteznek valamerre releváns tesztkódok, amit meg lehetne futtatni aws lambda-val?

    Mit érdemes mérni?

    Valami egyszerűbbet?: Mennyi egy helloworld, vagy pár adatbázis lekéréssel, validálással egy request?
    Vagy websocket alapú kiszolgálás?

    Szívesen megnézném, hogy mennyit számít serverless-nél egy python vs .net core esetén. Mert nálunk is közelgő téma egy projektnél...

    Nyilván nagyobb adatkezelés memóriában más téma, bár arra is van hatékony lib python alá (pandas), sőt talán megkockáztatnám, hogy nem is nagyon létezik hasonló, nagyobb körben támogatott .net alá.

    Keresgéltem 1-2 éve, és voltak ilyen pandas-ra hajazó dataframe kezelős lib-ek, de csak gyerekcipőben jártak.
    Mutasd a teljes hozzászólást!
  • Ez nem elsõsorban a Nadellán múlt szvsz, hanem azon, hogy ma már nem a windows a fõ platform, hanem az azúr.
    Mutasd a teljes hozzászólást!
  • A kliens oldal más kérdés. Ha webes, akkor célszerû mostanság valami javascript/typescript alapú cuccot összerakni Pl. Angularrel, de ez ettõl a szerver oldal szolgáltatásaira támaszkodik, legalábbis ha jót akar magának. Plusz, ha Pl. microservice-rõl beszélünk, akkor korántsem biztos, hogy a szolgáltatásod felhasználója egy webes kliens.
    Mutasd a teljes hozzászólást!
  • Bár már többször írtam itt de a 2014 előtti Microsoft mentalitást réges-rég el lehet felejteni. Új vezérigazgató van (Nadella) és teljesen mások a prioritások és az irányok mint előtte. Gondoltad volna 2014 előtt valaha is, hogy a Microsoft fő programozási platformja a .net majd open source lesz? Vagy gondoltad volna, hogy a Windowsban egy komplett Linuxot tudsz futtatni?
    Szóval nem kell attól félned, hogy fizetőssé teszik mert szerintem nem fogják. Amúgy ha cégként csinálod és új a céged akkor érdemes egy Bizsparkra bejelentkezni. 3 évig az összes fizetős cuccot is megkapod (Windows, Office, MSsql) fejlesztési céllal plusz jelentős havi Azure ingyen kreditet.
    Microsoft for Startups – Building Startups
    Mutasd a teljes hozzászólást!
  • Ha a kassza súlyozott kérdés, én a bináris platformot is csak korlátozottan használnám. Szerver oldalon ssl óta a cpu mindig szűk keresztmetszet. Azzal lehet spórólni belőle, ha a kliens oldali cpu-t is használod, amire csak használhatod. Olajozott gyakorlat kliens oldali végrehajtásra csak webes platformon van. Ami persze alapos overhead lesz kliens oldalon extrában is, de az nem a szerver problémája. Bináris platform kapcsolatra meg ott a websocket. A websocket-nak ugyan még kellhet 1-2 év, de lassanként már kipárnázott framework van hozzá.
    Mutasd a teljes hozzászólást!
  • Használhatsz bármit, de a kasszánál már nem biztos hogy mindegy, hogy mennyi erõforrásból szolgáltad ki a kérést.
    Mutasd a teljes hozzászólást!
  • A régi netbõl a finoman szólva nem annyira szerencsés csillagzat alatt született webformst kidobták a fenébe, az MVC és a razor maradt, sõt vannak új fejlesztések is (blazor). EF6 és EF Core van, az utóbbi az elõremutatóbb, viszont azzal a szintén nem annyira szerencsés csillagzat alatt született edmx-et elfelejtheted. De ép ésszel amúgy is code first dolgozik az ember. Ami jobban fájhat az a WCF hiánya, de mostanság amúgy is inkább REST API-t csinál az ember ha kommunikálni akar, vagy a perverzebbek GraphQL-t.
    Mutasd a teljes hozzászólást!
  • Serverless valóban egy jó megoldás lehet az esetek többsègèben, azon belül meg szinte bármilyen programnyelvet lehet használni. Itt viszont az lehet a hátrány hogy a platformhoz vagy kötve
    Mutasd a teljes hozzászólást!
  • Szerintem a .net framework-el kapcsolatban nem tett még soha semmit fizetőssé az ms.

    Kb a nem community-s visual studio-ért kell fizetni. A community verzió meg az individual developereknek ingyenes.

    Ráadásul régebben meg nem is volt community verzió, csak fizetős, szóval ezen a téren is inkább csak a fejlesztőknek kedvezett.
    Mutasd a teljes hozzászólást!
  • Tettszik amit irsz!
    Tudom hogy egesz jo a Visual Studio...ha nem a legjobb IDE a piacon.

    Nyilvan amikor szerveroldalrol beszelek, alapveto dolog, hogy skalazhato legyen es optimalisan mukodjon, ezt a tobbieknek irom, ezert megse fordult a fejembe komolyabban a Python es a NodeJS.

    A Swift igen .... .NET Core van annyira produktiv es jol hasznalhato mint a "regi" .NET?
    A MS termekeket  a support miatt utalom, mi ra a garancia, hogy 2 ev mulva nem mondjak, hogy ja bocs, fizetos lesz, vagy ...aaaa nem is eri meg nekunk leallitjuk?

    Nem vitatkozni akarok, csak lattam mar par ilyet (Silverlight, WPF, LightSwitch, WindowsPhone7 - ...) es ezert lettem Apple fejleszto...jelentsen ez barmit is.

    A WindowsPhonet nagyon sajnalom, szerintem nagyon jo rendszer volt, kivalo android ellenfel lehetett volna...
    Mutasd a teljes hozzászólást!
  • Nekem a C# és a .NET core a kedvencem. Sok IDE-vel használható, windowson ott a jó Visual Studio, MacOS-ssel megvert gépeken ott a Visual Studio for Mac, és mindenütt (incl. linux) ott a Visual Studio Code, illetve az Omnisharppal emacs, vim. Szerintem xamarin studio-val / monodeveloppal is lehet, de azokat ezer éve nem használtam. Kisebb dolgokra szerintem a VS code a legjobb, nagyobbakra a Visual Studio. Ja, és fizetõsben ott a JetBrains Rider, elvben ez a legjobb, bár õszintén szólva nekem a fentiek bármelyike is bõven elég. Felhõnek leginkább Azure, de elvben kb. bármin elmegy ami elvisz legalább egy linuxos docker konténert, de szvsz a legtöbb lehetõség az azúrban van vele (Pl. azure functions).
    Mutasd a teljes hozzászólást!
  • Majd vedd figyelembe a serverless vs container topikot is! 

    Serverless v Containers
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd