Google brengt versie 1.0 van programmeertaal Go uit

Google heeft versie 1.0 van zijn zelfontwikkelde programmeertaal Go uitgebracht. Naast de binaries van het objectgeoriënteerde Go is er ook een verbeterde software development kit voor Google App Engine verschenen.

In november 2009 kondigde Google een experimentele versie van zijn opensource programmeertaal aan, nadat deze door drie Google-medewerkers intern was ontwikkeld. Doel van de nieuwe taal zou zijn om een eenvoudiger alternatief te bieden voor de huidige complexe programmeertalen. Go biedt de mogelijkheid om meerdere processen tegelijk uit te laten voeren door middel van zogenaamde 'goroutines'. De syntaxis van de taal lijkt sterk op C.

Inmiddels acht de zoekgigant Go voldoende rijp en stabiel voor een officiële 1.0-release. Go 1.0 is beschikbaar voor Linux, FreeBSD, Mac OS X en Windows. Google belooft dat toekomstige versies van Go in de 1.x-serie backwards compatible zullen zijn. Dit moet garanderen dat programma's die in de nieuwe programmeertaal zijn geschreven de komende jaren zullen blijven werken.

De 1.0-versie kent enkele relatief kleine veranderingen ten opzichte van eerdere testversies. Zo zijn er extra bibliotheken toegevoegd en zijn de bestaande Go-libraries herschikt. Ook zijn er door de invoering van het 'go'-commando niet langer build scripts nodig om code te compileren. Google heeft bovendien een nieuwe versie van de Google App Engine-sdk uitgebracht. Deze sdk biedt ondersteuning voor Go-applicaties.

Reacties (71)

[Timon87]

Heb een schoolopdracht gedaan met GO, leuke taal om mee te werken. Concurrency is erg gemakkelijk en zeker snel. De taal was oorspronkelijk bedoeld als web gerichte taal, ze wilde de kracht van c++ met het dynamische van iets als PHP, OO principes zijn er niet meer.
Wel kan je met dingen als structs werken om zo iets te maken wat een beetje op een object lijkt. Dingen op de heap en stack kan je echter niet beheren.

Wat ons vooral opviel is het thread management van GO waar we erg veel mee gespeeld hebben. Je kan goroutines aanmaken maar dit betekent nog niet dat je dan ook een thread aanmaakt, dit beheert GO helemaal zelf.

Voor mensen die een leuke tutorial zoeken dit is een echte aanrader http://go-tour.appspot.com/
Hier is nog een leuk filmpje waarin ze alles uitleggen http://www.youtube.com/watch?v=rKnDgT73v8s
en hier nog een filmpje over hoe je webapps kan maken http://www.youtube.com/watch?v=-i0hat7pdpk

GO! een al bestaande taal is een taal speciaal voor Agent technologie iets waar wij mee bezig waren in google GO.

[Reactie gewijzigd door Timon87 op 25 juli 2024 20:47]

[poepkop]

Moet zeggen dat het wel eenvoudig is en een hoop zaken ook minder schrijfwerk vereisen:
http://tour.golang.org

Maar of dit populair wordt betwijfel ik, Adobe Air is ook nooit echt groot geworden.

[ChevyVan79]

Ik denk niet dat er iemand zit te wachten op een nieuwe programmeertaal. Het aanbod is op dit moment al erg groot met veel variatie in complexiteit.

[HerrKauwer]

Er is altijd plek voor een nieuwe programmeertaal. Innoveren in programmeertalen is niet onmogelijk, of wel? Als de nieuwe talen beter zijn dan de oude zullen ze vanzelf opgepakt worden en zullen de oude talen vanzelf niet meer gebruikt worden. Of de ene programmeertaal beter is dan de andere is natuurlijk heel moeilijk te bepalen. Zo zijn er vele factoren

• syntax
• leercurve
• standaard libraries
• compatibiliteit
• imago
• ondersteuning
• etc

[Reactie gewijzigd door HerrKauwer op 25 juli 2024 20:47]

[J.J.J. Bokma]

Datzelfde verhaal kon je 20 jaar terug ophangen, en kijk eens hoeveel nieuwe talen er in die tijd in gebruik genomen zijn...

[Ventieldopje]

Net even doorgelopen, best leuk maar sommige dingen kan ik me voorstellen dat die de code zó erg ondoorzichtig gaan maken zoals het gedeeltelijk weglaten van type's van argumenten en het retouneren van meerdere resultaten (ipv. netjes een object of array terug te geven).

Niks voor mij

[Anoniem: 201824]

Als je de punten van HerrKauwer erbij pakt hierboven (ik vermeng syntax ook even met 'gemak'), dan zie je punten die tegenstrijdig gaan zijn als je probeert 'de perfecte taal' te creëeren. En volgens mij is dat ook niet de bedoeling van Google. Met andere woorden, het is weer een taal erbij waar je voor kunt kiezen om zijn voordelen, of links laten liggen vanwege zijn nadelen. Ik geloof in ieder geval niet in de perfecte taal.

[Reactie gewijzigd door Anoniem: 201824 op 25 juli 2024 20:47]

[Anoniem: 349677]

Het is gewoon weer een lekkere programmeertaal. Voor een ex-C/C++/Java-ontwikkelaar als ik toegankelijker dan Ruby of Python, maar vernieuwend genoeg om interessant te zijn.
Ik heb weer net hetzelfde gevoel als ik in 1996 had met Java.

Hier iemands ervaring na 4 maanden Go gebruiken:
http://www.darkcoding.net...o-lang-after-four-months/

Zijn conclusie:
"Go’s sweet spot is building servers. It makes concurrency safer and easier than the current options. I’m going to keep using it for that. And because it’s fun."

De Tutorial is trouwens briljant, je kan de code in je browser aanpassen, die wordt uitgevoerd op de server en je ziet het resultaat weer in je browser: http://tour.golang.org/

[Reactie gewijzigd door Anoniem: 349677 op 25 juli 2024 20:47]

[Jack Flushell]

Van de link van Bishamon10 (http://www.darkcoding.net...o-lang-after-four-months/) van een programmeur die Go al een tijdje gebruikt:

- - - - - - - - - - - - - - - - - - - - - - -
Interlude: Cooking up Go

This is what I think the recipe for Go looked like:

1. Go back to the 70s / 80s and find a bunch of great programmers. Say, Ken Thompson, Rob Pike, people like that. Marinate them in Bell Labs for 30 years, during which time they code in C, keep developing Unix, invent Plan 9, Unicode, and other wonderful things.

2. Take them out, seduce them with Python, wow them with Google-scale computing. Add more amazing programmers (Brad Fitzpatrick for example), stir in Google’s near-unlimited resources.

3. Ask them how they would do C now, if they could start from scratch.

- - - - - - - - - - - - - - - - - - - - - - -

Mooi verwoord, magistraal zelfs.

[Reactie gewijzigd door Jack Flushell op 25 juli 2024 20:47]

[Anoniem: 282252]

Ik denk niet dat deze programmeurs Python erg zouden kunnen waarderen.

[Gutanoth]

Lijkt me leuk om er mee aan de gang te gaan!

[marino_centrino]

Ja, best leuk een nieuwe taal, maar waar moeten we deze taal nu positioneren?
Op wat voor applicaties is het gericht. Wat voor libraries zijn er standaard beschikbaar? Oftewel, wat zijn de voordelen tov van bestaande talen? Ik kan dit niet vinden, behalve het streven om nieuwe versies van de taal 'backwards compatible' te houden. Dat lijkt me het streven van elke established taal.
Deze basic informatie kan ik zo snel niet vinden, wat mij doet vermoeden dat het voorlopig niet veel voordelen heeft tov bestaande talen.

[YopY]

Ja, best leuk een nieuwe taal, maar waar moeten we deze taal nu positioneren?

Een C/C++ alternatief, voornamelijk, voor low-level, high-performante toepassingen; 'statisch gecompiled', dwz naar native machinecode, maar zonder al teveel memory management en met een eenvoudig / goed te begrijpen concurrencymodel.

tl;dr: wikipedia.

[vandeGerrit]

Dat ben ik niet helemaal met je eens. Ja ze gaan naar een native machine code toe.

De taal volgens wiki is Memory-safe, wat inhoud dat zei veel memory management doen. Er draait een garbage colletor mee, die hiervoor zorgt draagt. Ik verwacht wel dat het prima zal performen, aangezien het native code is, maar dat staat verder niet echt op de wiki. Wel dat het snel compileerd.

Ik denk wel dat de taal is bedoelt om simpel te zijn, veel van de OO princiepes zoals: inheritance en method overloading e.d. worden niet ondersteund. Aan de andere kant schijnen ze dit op basis van Interfaces te hebben opgelost. Misschien toch maar is mee spelen.

[LuitvD]

Go heeft het type-system compleet anders aangepakt dan de meeste andere programmeertalen. Het belangrijkste onderdeel wat dit type-system anders maakt is het interface type.

De interface werkt in Go anders dan de meeste mensen verwachten bij die naam. Het is meer een type-safe manier om aan duck-typing te doen.

Over het algemeen geeft een interface aan welke methodes een bepaald type implementeert. Een interface in bijvoorbeeld Java wordt expliciet aan een class geplakt, waarmee wordt aangegeven dat de class moet voldoen aan de interface, en als zodanig gebruikt kan worden. In Go geeft de interface op dezelfde manier aan welke methodes moeten bestaan, maar types die deze methodes implementeren zijn automatisch te gebruiken op plekken waar om dit interface type wordt gevraagd.


Snel compileren komt trouwens door het feit dat de taal en zijn compiler hier speciaal voor ontworpen zijn, en er onder andere voor zorgen dat de dependency-graph echt ongelooflijk simpel blijft, zelfs bij de meest complexe en massieve code-base. Complexe interdependency zorgt er bij grote (onder andere) C en C++ programma's vaak voor dat bepaalde stukken code bij compilatie enkele tientallen, of zelfs honderden keren opnieuw worden aangeraakt. Go vermijdt dit actief, en interfaces maken dit ook deels mogelijk.

[cyberstalker]

De manier waarop jij het beschrijft klinkt het alsof interfaces zich gedragen als traits. Op zich zijn traits erg prettig om mee te werken.

[LuitvD]

Ik heb geen ervaring met Traits, maar voor zover ik ze begrijp (wat ik zie aan de Scala implementatie in ieder geval) zijn Traits nogsteeds op dezelfde manier gebruikt als interfaces in Java: een class "bepaalt" welke traits hij implementeert/overneemt.

Interfaces in Go werken impliciet; voldoe aan de interface en je bent klaar. Dit maakt het gebruiken van types van anderen in je eigen code een stuk makkelijker, aangezien je de andere code niet hoeft aan te passen als je een interface schrijft om een aantal types als gelijke te behandelen.

Go's interfaces zijn trouwens volwaardige types, dus kunnen ze op dezelfde manier als aliased types en struct types methodes toegeschreven krijgen. Zo kan het ook nieuwe functionaliteit introduceren bij bestaande types, op een vergelijkbare manier als Traits dat doen (voor zover ik die begrijp). Het enige is dat je je type dus als je nieuwe interface-type gecast moet hebben voor je deze kan gebruiken.

Anyway, ik kan hier echt uren over lullen, ik moet toch echt maar eens een Nederlandse (bij voorkeur Groningse) Go community opbouwen...

[marino_centrino]

Kljnkt dus het meest als een Java-alternatief. Wel compilen naar native machinetaal, niet te veel memorymanagment voor de programmeur. Maar wat is dan het voordeel tov Java?

Ze zullen toch met aantrekkelijke (standaard) libraries moeten komen om een voordeel te bieden lijkt me. De taal an sich lijkt me geen unieke features te bieden.

[Earry]

Sorry? Java compiled niet naar native machinetaal en doet juist veel aan memory management.. Hoe komt dit ook maar in de buurt?

[Anoniem: 368883]

Mja, zo low-level noem ik het toch niet.

Inline assembly is bijvoorbeeld niet mogelijk (wat de meeste C compilers toch wel ondersteunen), en lijkt me toch wel noodzakelijk om een low-level taal genoemd te worden.

[RedPixel]

Maar je kunt wel linken naar C-programma's waarin je dat vervolgens wel gedaan hebt. Maar inderdaad, het niet kunnen van directe assembly maakt het minder een low-level programmeertaal... Aan de andere kant zit het wel 1 stap verwijderd van machinetaal, en is het in die zin wel low-level...

[LuitvD]

Bepaalde delen van de standard library zijn toch echt aan assembly code verbonden... Het sync/atomic package bijvoorbeeld. Is eigenlijk alleen maar assembler... en een beetje Go voor tests. http://golang.org/src/pkg/sync/atomic/

[Anoniem: 368883]

Ja, en deze code wordt gecompileerd door een assembler, niet de compiler van Go zelf. Waarom is dat, denk je?

[koelpasta]

"Maar je kunt wel linken naar C-programma's waarin je dat vervolgens wel gedaan hebt."

Dat kan je ook in elke scripttaal.. dat maakt die scripttalen nog niet low level
En alle talen die gecompileerd worden naar machinecode zijn 'maar 1 stap verwijderd van machinetaal' . Maar dat maakt ze niet persee low level.

[Anoniem: 368883]

sorry, maar dan is elke programmeertaal die rechstreeks veraalt naar machinecode low-level, en dat is niet correct. Pascal bvb, is een high-level programmeertaal maar compileert ook naar machinecode. C wordt als een mix van low- en high-level beschouwt omdat het enkele mogelijkheden biedt die high-level talen niet bieden, zoals het werken met inline assembly en het werken met pointers.

[koelpasta]

"Een C/C++ alternatief, voornamelijk, voor low-level, high-performante toepassingen; 'statisch gecompiled', dwz naar native machinecode, maar zonder al teveel memory management en met een eenvoudig / goed te begrijpen concurrencymodel."

Sorry hoor maar de helft van de dingen die je noemt lijken helemaal geen features van de taal.
Low level taal met garbage collection??? Riiiight.
En wat betekent "statisch gecompiled"? Is een DLL dan geen native machinetaal omdat het niet statisch gecompileerd is? Of bedoel je soms statisch gelinkt?
Je lijkt echt een aantal dingen door elkaar te halen..

[rjhe]

Low level taal met garbage collection??? Riiiight.

Dus C met Boehm is ook niet low level?

Handmatig memory management is achterhaald; helemaal als je een groot high performance systeem ontwikkelt. Dat Go geen pointer arithmetic aan de programmeur overlaat wil wel zeggen dat Go minder low level is dan C, maar niet low level lijkt me wat overdreven.

Probeer eens een taal die echt wat voor je doet, zoals een van de functionele talen. Dan is Go wel degelijk low-level.

[badboyqxy]

marktaandeel hierin, zal googles positie ten opzichte van microsoft aanzienlijk verbeteren op het gebied van software ontwikkeling

[Wolfos]

C syntax = nice. Is het ook OOP?
Geen makefiles, weet niet zozeer of ik daar het nut van in zie. Vaak is porten van low level code een kwestie van de makefile aanpassen, en dan is het wel nice dat het los van je project staat.

[Reactie gewijzigd door Wolfos op 25 juli 2024 20:47]

[Anoniem: 282252]

Als je een makefile moet aanpassen dat doe je wat verkeert.

Ik gebruik zelf Qt veel, en die genereert een Makefile voor mij. Andere Makefile generators zijn natuurlijk automake en het veelbelovende cmake.

[Wolfos]

Ik maak mijn makefiles helemaal zelf. Zoveel moeite is dat niet en dan kan ik ook gekke scriptjes erin proppen.

[RedPixel]

Yes and no. http://golang.org/doc/go_..._object-oriented_language

[Loller1]

Je begint zo stil aan door de bomen het bos niet te zien, maw, er komen teveel programmeertalen bij voor steeds hetzelfde doel. Ze proberen een standaard te maken, maar je krijgt alleen meer alternativen...

[mekkieboek]

Da's om te voorkomen dat alle programmeurs ongehinderd kunnen samenwerken om een hele hoge toren te bouwen waardoor ongelovige eindgebruikers toch in de ICT hemel kunnen komen. Of iets van die strekking...

[Sisko]

Volgens mij babel je maar wat uit je nek

[Roconda]

Er verdwijnen natuurlijk ook wel talen, denk maar aan LISP.

[Futureal]

Dan zou ALGOL of Basic een beter voorbeeld zijn van een gelijksoortige programmeertaal die al (grotendeels) verdwenen is

LISP is immers een declaratieve (functionele) programmeertaal.
en geen imperatieve pogrammeertaal (C, C++, Java)

[_Erikje_]

(varianten van) Basic wordt nog erg veel gebruikt om robots te programmeren. 't is heel triest maar het is zo

[RedPixel]

Dat dreigt toch al vaak vervangen te worden van LUA... Ook al een taal voor mensen die niet hebben leren programmeren, maar het toch moeten kunnen

[bonus]

Waarom is dat triest dan, het doet toch wat het moet doen ? Waarom altijd zo laagdunkend over Basic. Het moet een basic iets doen en dat doet het dus ook. Programma's worden vaak opgeblazen tot een te groot iets terwijl het iets heel simpels moet doen. Daar was basic altijd prima voor, kleine interpeter en snel en eenvoudig te doen.

[J.J.J. Bokma]

Ja, Lisp is helemaal verdwenen. Kan ik Emacs opruimen, dan?

Kijk ook eens naar Clojure, zou ik zeggen.

[A Noniem]

Ik vrees echter dat er nog meer mensen LISP gebruiken dan GO

[bonus]

Geen wonder als je kijkt hoe oud LISP al is GO is er nog maar net...

[crazylemon]

Broem broem, Turbo Pascal

[nhimf]

Hoezo komen er steeds meer talen?
Zolang we programmeertalen hebben, zijn er al veel te veel :-)

[Anoniem: 445717]

Ik zie niet veel verschil met C. Sterker nog, ik zou het op eerste gezicht een C-dialect noemen. Zo te zien is er ook op een aantal syntaxregels en de goroutines niet veel wat Go biedt ten opzichte van het (veel bekendere en meer gebruikte) C als imperatieve taal.

[J.J.J. Bokma]

Geen idee wanneer je voor het laatst C hebt gezien, maar kijk hier eens naar:

package main

import "fmt"

func swap(x, y string) (string, string) {
------return y, x
}

func main() {
------a, b := swap("hello", "world")
------fmt.Println(a, b)
}

----- = tab

[Reactie gewijzigd door J.J.J. Bokma op 25 juli 2024 20:47]

[blorf]

Vreemde functie-declaratie en als ik het zo zie doen ze niet aan typing en is het standaard al OOP-gericht dus aardig verwijderd van C. Println klinkt een beetje Pascal-achtig.
Trouwens, geeft dat ding nou "world hello" omdat die vars geswapt worden?

[Montaner]

Niet alleen het Println, ook het :=

[PuzzleSolver]

Ook type na variabele, meerdere vars van hetzelfde type declareren, var statement en struct initializer lijken op pascal. En dan natuurlijk ook nog de . om pointers naar structs te benaderen alsof het structs zijn is iets wat ook met pascal pointers naar records en objects kan.

Voor de rest zitten er leuke thread sync opties in. Maar C# bevat ook al een hoop leuke extra's in die hoek. Misschien dat ik er ooit nog wel eens wat mee ga doen, maar voor nu vind ik Pascal, C#, C++ en Java wel genoeg als dagelijkse programmeertalen.

[Reactie gewijzigd door PuzzleSolver op 25 juli 2024 20:47]

[RedPixel]

Ik hoop dat ie "world hello" geeft, want anders snap ik het niet meer

[Struikrover]

Hij geeft iid "world" "hello" want de invoer van de swap functie wordt direct omgedraaid geretourneerd . Je kunt ook zelf compilen op de pagina van de tour:

http://tour.golang.org/#8

[Reactie gewijzigd door Struikrover op 25 juli 2024 20:47]

[Fawn]

Ze kunnen dit relatief eenvoudig pushen als dé programmeertaal voor Android lijkt me?
Dan zou het nog wel eens succes kunnen hebben.

[Anoniem: 445717]

Ik denk dat dit juist averechts werkt. Programmeurs zullen geen zin hebben om een nieuwe taal te leren om een app volledig te herschrijven voor Android. Zeker gezien de versplintering van Android wat programmeren nog verder bemoeilijkt.

Nee, dan zou ik het als bedrijf eerder bij iOS en WP7 zoeken. In plaats van een hoop te investeren om je programmeurs een nieuwe taal te laten leren (en dat kost tijd!), en een app vrijwel volledig opnieuw te moeten ontwikkelen met alles dat daarbij komt kijken. Grote kans dat zo'n bedrijf dan ook Android maar laat varen en hun winst elders zoekt.

Denk dan ook niet dat Google die stap zou zetten, anderzijds heb ik ook geen idee wat Google dan wel met Go wilt.

[Gropah]

Ja, want Objective-C lijkt ook zo verschrikkelijk op C#...

Ik denk er net zoveel verschil tussen zit, als tussen die talen en Go

[Anoniem: 445717]

Nee, maar beide talen bestaan al geruime tijd en het is dan ook makkelijker als bedrijf om hier ervaren mensen voor in te huren. Met Go zou je je hele Android-tak opnieuw op moeten leiden, met alle gevolgen van dien.

[Gamebuster]

Objective-C + Apple's tools zijn echt een hel om te leren. De leercurve is nou niet bepaald laag.

Java en C# zijn dan toch wel een stukje simpeler.

[Anoniem: 282252]

Objective-C programmeert best lekker weg, en er zitten zaken in Objective-C die heel erg cool zijn!

Ook de tools die Apple meeleverde zijn heel goed te noemen, debuggers, profileren het werkt allemaal prima.

Als je kijkt hoe zevenvoudig het is in Objective-C om een tread op te starten, gewoon via een clausure, wat erg handig is!

Ikzelf ben niet bekend met C#, maar in Java zijn de tools zeker niet beter en zeker in Java heel erg versnippert.

[Gamebuster]

Het zal allemaal prima werken en het is best mooi allemaal.
Het is alleen lastig om alles te leren kennen.

Om een simpele iOS app te maken moet je een nieuwe taal leren & nieuwe tools leren. Er zijn best veel hulpmiddelen en al die apple-tutorials gebruiken die tools allemaal tegelijk.

Het is alweer een tijdje terug dat ik me het laatst ermee bezig hield, misschien dat ik het nu beter oppak, maar een tijdje terug vond ik het allemaal erg pittig.

[Kajel]

Objective-C is inderdaad lastig te leren. Althans, dat vond ik toen ik eraan begon, in vergelijking met bijvoorbeeld C#, dat ook nieuw voor me was. De tools die Apple echter levert voor iOS ontwikkeling zijn een breeze om te leren!
Als ik het vergelijk met Android ontwikkelen, is het andersom: Java is als taal makkelijk te leren, en vaak ook al bekend bij programmeurs die van Inf opleidingen afkomen, maar de tools om Android apps te bouwen, zijn nog steeds redelijk abominabel te noemen. Android emulator is aanzienlijk sloppier dan de iOS sim, interface builder van Android is nog steeds praktisch non-existent, in tegenstelling tot de prachtige storyboard builden van iOS en ga zo maar door

Ontopic: Ik zie het nut nog totaal niet van Go. Ik mis namelijk een beetje het vernieuwende/unieke aspect, en dus de niche die Google met Go denkt te gaan veroveren.

[Reactie gewijzigd door Kajel op 25 juli 2024 20:47]

[Erwin1967]

Leuke taal en misschien wel een idee ter vervanging van java in Android. Je zult dan wel runtime moeten kunnen compileren of er een vm voor schrijven gezien de verschillende soorten hardware.

[Anoniem: 282252]

De compiler is snel genoeg om dat JIT te kunnen doen. Dus in principe de soure verspreiden en elke device compileert dat zelf.
Of misschien dat een slimme volgel Go -> ByteCode -> Compiler maakt ?