ugrás a tartalomhoz

Is The Go Programming Language Worth Learning?

Hidvégi Gábor · 2014. Feb. 19. (Sze), 17.40
Melyik programnyelv használatában érdemes elmélyülni hosszabb távon?
 
1

Nyaf :)

BlaZe · 2014. Feb. 19. (Sze), 21.50
Mi számít hosszabb távnak? Ha most nincs munkája, miért olyan nyelvet akar tanulni, ami majd 5 év múlva... Tanuljon olyat, ami már évek óta nagyon keresett, és nem csökken a kereslet iránta, amivel MOST el tud helyezkedni. Aki tutira akar menni, válasszon a Java/C#/PHP és hasonlók közül. Egyrészt. Másrészt aki tényleg jó, az mindig el fog tudni helyezkedni, mert a jó programozó nem egy adott nyelven jó programozó. És fordítva. Ezzel könnyű nyugtatni magát az embernek, hogy én azért nem kellettem, mert nem ismerem a gitet, mert nincs tapasztalatom Hibernate-tel, vagy mert rossz színű pólót vettem fel. Persze vannak cégek, akik ilyen alapon utasítanak el, de nekem személyes tapasztalatom, hogy olyanra is lehet váltani, amivel nincs konkrét munkatapasztalata az embernek. Nyilván át kell menni az interjún, ahhoz meg tudni kell dolgokat (ja kérem, egy interjúra készülni kell...), kell működjön a kémia az interjúztatóval stb.

Azok a butaságok meg, hogy valami 20+ másodpercig tart .NET-ben/Javaban, míg C-ben ugyanez pár pillanat... Aki ezt valóban el is hiszi, azt nem is csodálom, hogy nem veszik fel egy adott nyelv specifikus interjún :) Nem azt kétlem, hogy ennyire el lehet b***ni valamit egy high-level nyelvben, hanem hogy valakinek X év programozói tapasztalattal nem tűnik fel, hogy ez tervezési/implementációs hiba, nem a nyelv ilyen lassú, ha már gépi kódra fordul. Már pl ha tudja, hogy arra fordul és nem azt hiszi, hogy pl a Java interpretált nyelv, mert nem exére fordul :) Ha nem tudja, akkor meg azért.

Ja, és még valami. Akinek a tudása elavul a munkahelyén, az meg is érdemli. Ez több dolgot is jelenthet:
- Nem tudja, hogy elévül a tudása
- Tudja, de nem érdekli, hogy elévül a tudása
- Tudja, érdekli is, de nem mer váltani

Ki melyik típust venné fel szívesen?
3

A szerző szerint a Go nyelv

Hidvégi Gábor · 2014. Feb. 20. (Cs), 08.12
A szerző szerint a Go nyelv ígéretes, és azt kérdi, miről lehet felismerni, hogy valami valóban jó-e, mivel érdemes behatóbban foglalkozni.
5

Egyetértek, nekem is a hiszti

bamegakapa · 2014. Feb. 20. (Cs), 13.06
Egyetértek, nekem is a hiszti jött le az egészből.

Egyrészt nem hiszem, hogy C++ programozóra ne lenne kereslet, főleg ha jó. Másrészt ha annyira kell neki munka, és olyan rohadt gyorsan sajátít el egy nyelvet, elmehetne bárhova Javascript/Java/PHP/akármi programozónak, felveszik kevesebb tapasztalattal is (ha tényleg olyan jó, mint mondja), mert nagy a kereslet. Csak akkor valószínűleg végig hisztizne, hogy milyen béna nyelveken kell programoznia, őt senki sem érti meg, ez a kor nem érett meg az ő zsenijére - ami nyilván rontja a teljesítményét.

Előre meg ki tudná megmondani, hogy egy nyelv népszerű lesz-e, 5 év múlva lesz-e rá kereslet?
2

Bármelyik oo nyelvben

inf3rno · 2014. Feb. 19. (Sze), 23.46
Bármelyik oo nyelvben elmélyülhet az ember. Ha sikerül megfelelő szinten elsajátítania az adott nyelvet, akkor a későbbi esetleges váltás egy másik oo nyelvre nem fog különösebb erőfeszítésbe kerülni. A különbség minimális lesz, kicsit mások a nyelvi elemek, mások az elérhető eszközök, stb... Ezeket át lehet hidalni viszonylag rövid idő alatt...

A go egy jó nyelv. Belenéztem, tetszett. Ami nekem nem jött be, hogy kevés hírt hallok róla, ami meg valószínűleg azt jelenti, hogy kicsi a közössége. Ami meg azt jelenti, hogy kevés az olyan eszköz, amit mások leprogramoztak. Ha ez igaz, akkor nem különösebben van értelme foglalkozni vele, hacsak nem olyan projekted van, amihez tökéletesen megfelel a go jelenlegi eszköztára is. Én a feltételezett kis közösség miatt nem igazán mélyültem el benne. Lehet, hogy én tévedtem...
4

en a helyeben Javascriptben

blacksonic · 2014. Feb. 20. (Cs), 12.06
en a helyeben Javascriptben merulnek el :)
6

Az béna nyelv, mert lassú

bamegakapa · 2014. Feb. 20. (Cs), 13.09
Az béna nyelv, mert lassú benne a "Video Poker Trainer" program, amit írt :).
7

ohh :D

inf3rno · 2014. Feb. 20. (Cs), 18.22
ohh :D
8

Go

Hidvégi Gábor · 2014. Feb. 28. (P), 17.07
Olvasgattam a Go-ról, és megdöbbentett, hogy bár egészen új nyelv (2009-es), de nincs benne öröklődés, sem pedig kivételkezelés.
9

Sem pedig osztály, objektum.

BlaZe · 2014. Feb. 28. (P), 22.00
Sem pedig osztály, objektum.
Paradigm(s) compiled, concurrent, imperative, structured

Érdekes nyelvnek tűnik, kíváncsi leszek merre fog menni. De szvsz én nem gondolom, hogy a go lesz a következő nagy világmegváltó nyelv. Aztán persze majd kiderül.
10

Valószínűleg a következők

Hidvégi Gábor · 2014. Már. 1. (Szo), 07.16
Valószínűleg a következők miatt:
With processors getting more and more cores and memory access speed not improving, the focus seems to be shifted towards procedural/functional processing oriented code. Even before the day of parallel processing, the component-based approach is already used to manage a system's complexity.
12

Arguments against OOP

BlaZe · 2014. Már. 3. (H), 22.20
Azt inkább nem commentálom, hogy ez a hozzászólás egy "Arguments against OOP" google groups topicról való :) De őszintén csodálom a kitartásodat :)

2 dolgot említ a hozzászólás írója: több core, és memory access. A kettőnek kb semmi köze egymáshoz, teljesen más problémát hoznak be.

Memory access: Ez ugye nem újdonság. Talán ismerősen hangzik, hogy "RAM is the new disk", vagy ennek egy másik verziója. A lényeg, hogy a mai processzorok sokkal gyorsabbak, mint amilyen gyorsan elérhető a memória, és egy rosszul szervezett adatszerkezettel kb lábon lehet lőni a legszebb kódot, és a legjobban kitalált algoritmust is. Konkrétan a jelenlegi processzorok kb 200x (!!!) annyi idő alatt érik el a memóriában lévő adatot, mint ami kéznél van (regiszterek, belső bufferek, L1 cache). Ezt nyilván az Intelnél is tudják :), ezért a mérnökök mindenféle spekulatív okosságokkal spékelték meg a procikat. Ami idevág, az a prefetching. Ez azt jelenti, hogy a processzor azt feltételezi, hogy okos adatszerkezetekkel dolgozunk (gyakorlatilag tömb), ezért arra számítva, hogy szépen végigmegyünk rajta (és miért ne tennénk, a programjaink valójában adatszerkezetek köré épült ciklusok és elágazások), betöltögeti nekünk a szomszédos memória területet a cache-be majd jó lesz az valamire alapon. És ha a programozó ezzel tisztában van, akkor jó is lesz :) És itt jön képbe az, amiért az OOP-t szokták bántani, nevezetesen a dinamikusan röptében létrehozogatott objektumok össze-vissza helyezked(het)nek el a memóriában, ezért az ilyen objektumokkal dolgozó kód igen nagy arányú cache miss-re van ítélve, ami azt fogja jelenteni, hogy a proci tökjót malmozik, miközben mi úgy látjuk, hogy vörösen izzik a gép, mert egész kelet-kína a mi kódunkat hajtja. Ezzel nagyon nem lehet vitatkozni, ez tény. De miért kéne ezt mindenképpen így csinálni? OOP kódban bűn a tömb, meg a szekvenciális adatszerkezetek? Én nem így látom, és szerencsére sokan nem így látják, ezért készülnek igen gyors kódok OOP alapokon. Sőt, pl a világ pénzügyi rendszerének igen tekintélyes része nemhogy OOP-ban, de Javaban készül. És gyors. Nagyon gyors :) Pár százalékkal lassabb, mintha C-ben írnák, de bőven elég gyors ahhoz, hogy ésszerű kompromisszum legyen a sebesség vs karbantarthatóság örök kérdésben. Nyilván nem az EJB-s horrorokra kell itt gondolni természetesen. Ráadásul OOP-vel egy belül bonyolultabb, szétoptimalizált kódot is el tudsz fedni szép interface-szel, procedurális kódban ez azért macerásabb. És ott is lehet csúfságokat elkövetni adatszerkezet téren, elég pl egy linked-list és unbounded queue házasságra gondolni. Lényegében azt kell látni, hogy az OOP kód is ugyanarra fordul, mint a procedurális, a processzor csak egyfélét ismer.

Ami a sok core-t illeti, ez nyilván többszálú programoknál kihívás. Szinkronizálni a szálakat, lockok, hogyan és mennyire skálázhatók az egyes algoritmusok stb. Az se véletlen, hogy bizonyos alkalmazási területeken inkább egyszálú programokat írnak, hogy ne kelljen a fentiekből adódó lassulással számolni. De ennek aztán tényleg nem sok köze van ahhoz, hogy OOP, vagy sem.
13

OOP

Hidvégi Gábor · 2014. Már. 4. (K), 15.18
Az OOP számomra az első perctől bűzlik, és bár azt nem mondom, hogy teljesen haszontalan, de szerintem nagyon kevés esetben alkalmazható hatékonyan. Arról ne felejtkezz el, hogy (gondolom, még mindig) Java-ban programozol, ahol nincs igazából választási lehetőséged a programozási paradigmák között.

Úgy gondolom, hogy az elkövetkezendő években teljesítményigényes szoftvereknél az OOP szép lassan vissza fog szorulni, és a funkcionális programozás veszi át a fentiek miatt (párhuzamos programozás) sok esetben a helyét. Mondjuk szerveroldalon valószínűleg tovább fogja tartani magát, mert ott könnyebb a hardvert bővíteni.

Az általad leírt tapasztalatokat hány év alatt és milyen IQ-val lehet összeszedni?
14

Úgy gondolom, hogy az

inf3rno · 2014. Már. 4. (K), 15.26
Úgy gondolom, hogy az elkövetkezendő években teljesítményigényes szoftvereknél az OOP szép lassan vissza fog szorulni, és a funkcionális programozás veszi át a fentiek miatt (párhuzamos programozás) sok esetben a helyét.


Erre én 0.1% esélyt látok, de majd megbeszéljük 5 év múlva... :D
15

Az általad leírt

Greg · 2014. Már. 4. (K), 15.35
Az általad leírt tapasztalatokat hány év alatt és milyen IQ-val lehet összeszedni?

Es az altalad osszehordott badarsagokat?
Mondjuk az IQ-nak nem tudom mi koze van ehhez, de te biztosan tudod azt is.
16

Az általam összehordott

Hidvégi Gábor · 2014. Már. 4. (K), 16.37
Az általam összehordott badarságokat Blaze a 12-ben alátámasztotta. Mi az, ami nem érthető?
17

Az nem ertheto, hogy miert

Greg · 2014. Már. 4. (K), 17.07
Az nem ertheto, hogy miert vagy ennyire raszallva az OOP-re? Ha nem tetszik a paradigma, akkor ne hasznald, fejlessz proceduralisan, funkcionalisan vagy ahogy akarsz, de ne legyen mar tele a weblabor azzal, hogy szerinted mennyire szar az OOP.
18

Mert nincs meg az egyensúly,

Hidvégi Gábor · 2014. Már. 4. (K), 17.31
Mert nincs meg az egyensúly, és mint a Go példája is mutatja, változik a világ.
20

Konkrétan mit támasztottam

BlaZe · 2014. Már. 4. (K), 19.49
Konkrétan mit támasztottam alá? Nagyjából leírtam, hogy mindkét paradigmával lehet piszok gyors, és lomha kódot is írni, és a fejlesztőgárda ilyen irányú felkészültségén múlik, hogy végül melyik jön össze.
19

Arról ne felejtkezz el, hogy

BlaZe · 2014. Már. 4. (K), 19.43
Arról ne felejtkezz el, hogy (gondolom, még mindig) Java-ban programozol, ahol nincs igazából választási lehetőséged a programozási paradigmák között.
Nincs, viszont nem ő választott engem, hanem én választottam őt :) Egyébként erről annyit, hogy láttam elég valójában procedurális programrészt megírva javában, amitől a hajam kihullott. És ha valamit módosítani kellett rajta, akkor rántott magával csomó mindent. De nem akarok ebbe újfent belemenni, én programoztam eleget procedurálisan is, hogy legyen egy kialakult képem.

Úgy gondolom, hogy az elkövetkezendő években teljesítményigényes szoftvereknél az OOP szép lassan vissza fog szorulni, és a funkcionális programozás veszi át a fentiek miatt (párhuzamos programozás) sok esetben a helyét. Mondjuk szerveroldalon valószínűleg tovább fogja tartani magát, mert ott könnyebb a hardvert bővíteni.
Én egészen biztos vagyok abban, hogy ez nem így lesz. A funkcionális programozás a lehető legmesszebb visz a hardwaretől, ami pedig általában ellentétes azzal, amit az ember szeretne, ha igazán hatékony kódot akar írni a vasra. És akkor arról nem is beszéltünk, hogy finoman szólva is magasabb a belépési küszöbje, mint a többi paradigmának. Az igazán teljesítményérzékeny (bár ez alatt valójában mit is értünk?) rendszerek inkább a single threaded irányba mennek, pont azért, mert az ember első várakozásával ellentétben a többszálúsítás az egyedi requestek kiszolgálásának idejét növeli. Kicsit értelmesebben megfogalmazva a latency nő tőle. Ha pedig throughputra gyúrunk, akkor azért van több lehetőség a párhuzamosítást megvalósítani. Akár CPU, akár cluster szinten.

Az általad leírt tapasztalatokat hány év alatt és milyen IQ-val lehet összeszedni?
Ezt inkább nem is értem :)
21

OOP kódban bűn a tömb, meg a

Hidvégi Gábor · 2014. Már. 4. (K), 20.15
OOP kódban bűn a tömb, meg a szekvenciális adatszerkezetek?
Ha tömbökben tárolod az adataidat, akkor a kódodat hogyan szervezed OOP módon? Vagy másképp: ha a kör és az ellipszis adatai egy tömbben vannak, akkor elveszik a polimorfizmus és az öröklődés, hogy lesz így OOP?
22

A helyzet az, hogy ezekről

BlaZe · 2014. Már. 4. (K), 20.50
A helyzet az, hogy ezekről csak kontextusban lehet beszélni, hogy mi hogy gyors. OOP esetén is kerülhet 1 kör, meg egy ellipszis egy cache line-ba, vagy egymás mellettibe. És ha pl structban tárolod, az is lehet össze-vissza. Nem igazán értem ebből mit akarsz kihozni.

Egyébként ha már ezzel a példával jöttél elő :) Liskov substitution principle
23

Arra gondoltál, hogy az

Hidvégi Gábor · 2014. Már. 5. (Sze), 06.45
Arra gondoltál, hogy az objektumokat nem "véletlenszerűen" hozod létre, hanem tömbbe teszed egymás után őket?
24

Akár. De ez így picit

BlaZe · 2014. Már. 5. (Sze), 20.42
Akár. De ez így picit értelmetlen vita szerintem, több szempontból is. Egyrészt ahol ez a probléma előjön, az olyan spéci helyzet, hogy egyedi megoldás kell. Másrészt ha pl egy web alapú programot nézünk, sokkal inkább fog külsö erőforrásra várni, mint belsőre.
25

Nem vagyok egy expert

inf3rno · 2014. Már. 6. (Cs), 01.01
Nem vagyok egy expert skálázás terén, de úgy hallottam, hogy általában a fájlrendszer műveletek, amik lassítják a kódot.

Hogy a témához is hozzászóljak, én ritkának tartom az olyan eseteket, amikor az ügyfél külön fizetni szeretne azért, hogy szénné legyen optimalizálva a kód. Ez mondjuk az én tapasztalatom, de várom a véleményeket ezzel kapcsolatban.
26

Hogy mi a lassú, az relatív.

BlaZe · 2014. Már. 6. (Cs), 22.32
Hogy mi a lassú, az relatív. Van, ahol belefér a filerendszer matatása, van ahol egy concurrent queue sem. Van ahol oké 50-100ms egy egyszerűbb request kiszolgálására, van ahol fél ms sem elfogadható egy viszonylag bonyolultabbéra. De a web tipikusan nem az a terület, ahol a latency ennyire számítana. Ha másodpercekben mérhető, az már nyilván kevésbé elfogadható, de ami igazából számít, az a throughput (erre nem tudom van-e szép magyar szó, ami egyértelműen ezt is jelenti :)). Azt meg sokkal több mindennel lehet befolyásolni, sőt itt kevésbé a kód agyonoptimalizálása a megoldás.

Hogy költenek-e rá? Valóban, nem nagyon. Mert nincs is rá szükségük. Ahol kell, ott nem tudják kikerülni úgyse, hogy költsenek rá. Se szakértőben, se infrastruktúrában.
27

Gondolkodtam azokon, amit

Hidvégi Gábor · 2014. Már. 8. (Szo), 13.30
Gondolkodtam azokon, amit írtál, úgy tűnik, igazad van. Ja, és boldog névnapot kívánok minden kedves Zoltán nevű olvasónak : )
28

:)

BlaZe · 2014. Már. 11. (K), 01.20
Minden kedves Zoltán nevű olvasó nevében utólag is köszönöm :)
11

app engine és böngésző

zzrek · 2014. Már. 1. (Szo), 11.55
Jól láttam, hogy a GO nyelv használható (lesz) a Google app engine-en és natív kliensként a Chrome-ban? Vagy kevertem valamit?