Google Releases Version 1.5 of Its Go Programming Language, Finally Ditches C

An anonymous reader writes: Google has launched the sixth notable stable release of its Go programming language Go 1.5. VB reports: "This is not a major release, as denoted by the version number and the fact that the only language change is the lifting of a restriction in the map literal syntax to make them more consistent with slice literals. That said, Go 1.5 does include a significant rewrite: The compiler tool chain has been translated from C to Go. This means "the last vestiges of C code" have been finally removed from the Go code base. As for actual changes in Go 1.5, you'll want to read the full release notes. Highlights include improvements to garbage collection, the developer tools, the standard library, and new ports."

Comments

But how many women are using Go?

[Anonymous Coward]

The article completely omits any mention of women using the Go language. How many women are enrolled in Go classes across the US? Are there scholarships available yet so our daughters can do a doctoral thesis on Go? Google's misogyny is really shining through this time, it's pretty obvious they expect all women to become hairdressers and waitresses.

Re:But how many women are using Go?

[Anonymous Coward]

You say all that like it's a bad thing. Oh, sorry, I forgot. Only people who aren't white and who are less than 25 matter in the world these days.

Helpful hint: getting older is a lot easier to deal with if you haven't spent your 20s insulting people who aren't. Because when you're not 20 something anymore, having a brain full of that kind of attitude will just make you feel even more useless than you already are right now.

Oh no....

[Anonymous Coward]

Google is ditching C! Oh my ... Wait.. what... you mean, "ditching C in their Go language platform". Uh... well.. duh, who actually would think they'd use C in their own new shiny language toolchain, that's like anti-advterisement.

Oversensational header, disappointing....

Re:Oh no....

[Z00L00K]

I agree that it's more like a balloon popping news than revolutionary news. And in any case - there's still C and assembly somewhere.

When I look at the code examples my opinion is that it reminds me of a mix of C/C++ and Pascal. Not necessarily bad, just an observation.

What I think lacks when it comes to the Go compiler are the number of platforms supported, some are missing, like ARM and MIPS. Hopefully that will come as well.

How about translation tools - something that can convert Java to Go?

Finally!

[thegarbz]

It's about time. Wait ... is it? What was so bad about C? Was there an active campaign to eliminate it? Were they behind on some schedule or hanging out against the wider desire to ditch C?

Why are we finally ditching something that worked?

Re:Finally!

[complete loony]

Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. For more details, see these slides and associated video.

And replacing it with something slower.

Re:Finally!

[Anonymous Coward]

They removed C code from the runtime so they had one language to reason about in the garbage collector. It makes updating the pointers on the stack easier among other things: Go 1.5 includes a new moving mostly concurrent garbage collection that wouldn't have been practical with random runtime c code on the call stack. It also makes it easier to contribute to the project (less languages involved), and removed the need for maintaining their modified C compiler that worked with their ABI and stack management.

So no, none of the reasons they removed C were because C is bad (Though they would also claim it has its issues). It mainly was problematic to have a second and non memory safe language involved in the runtime. The reasons for removing it from the compiler are less clear cut, but some of the same reasons apply.

Re:Finally!

[Anonymous Coward]

Yeah, you try using a garbage-collected language in large embedded systems with real-time requirements. The unpredictable nature of the garbage collector really screws around with you. People have been claiming to have deterministic garbage collectors forever too, but usually their overhead makes them not worthwhile, too.

C++ is (well, can be) maintainable and quite appropriate for real-time use as long as you use an appropriate subset (exceptions are usually a no-no, for instance), and you get some higher-level abstractions that are very, very useful and that generally compile to fast, efficient machine code.

Re:Finally!

[DarkOx]

I agree the issue here isn't ditching C so much as having a self hosting language. Self hosting has all sorts of advantage the ones you point out are the biggest.

With a youthful language often new features and revision appear in the reference compiler first. If designing something like a new syntax or language construct a good hit you are doing something right is when its strait forward to express within the existing language. When it comes time to implement and you are working in the native language if you find you can't express the new construct easily it might mean the relationships and orthogonality are not as clean as you think.

I disagree that is bad new for maintainability and abstraction. There are plenty of very large very old C projects that are perfectly maintainable. Its a question of discipline mostly and selecting right abstractions. GTK is a mess because its an objected oriented library written in a procedural language. OO isn't the only possible design choice even though that is all many people are taught today. Had a procedural abstraction been chosen I am sure it would be fine.

Re:Finally!

[serviscope_minor]

All major operating systems are written in C, including Linux, the BSD/MacOS kernel and the Windows kernel.

And the common thing about those is all of them are OLD. Sure there are new parts, but they were all started a very, very long time ago when C did have major advantages over C++ (no standard C++, slower code, buggy compilers significantly lagging the standard when it finally arrived). Of course in the mean time, there have been 3 major language versions (98, 11, 4), one minor one (03), and a bunch of TS (<3 concepts! finally!), not to mention truly vast improvements in compiler performance, and the final arrival of two production quality open source compilers which are generally in advance of the standards, not behind.

Back in '94 when they tried compiling Linux in C++ and it went slower, well, then C had advantages over C++. That was over two decades ago. The world has moved on since then.

As we've seen with GCC who have been undergoing a heroic effort, it's a lot of work to move an old project from C to C++, and you have to have the devs on board (given Linus's major blind spots he'll never do that for Linux). There's also very little advantage initially because most of the code is idiomatic C, and getting good paramaterised containers, type safety, leak safety etc etc is a lot of very slow work. It's not merely enough to switch your compiler, to get the full advantages you more or less have to rewrite the entire project from the inside out.

And as for OSX, well, parts of the kernel are written in C++, and in fact the device driver layer supports it. It's a subset, which doesn't allow any of the bits requiring significant support from the runtime (exceptions, RTTI/multiple inheritance) and bizarrely, templates which are basically invisible at that level.

C++ is a terrible language for most purposes. No good for system programming, and not great for application development. Later languages vastly improve upon it.

Many of the big "applications" on my machine that I regularly use are written in C++. There's firefox, Eagle CAD, Libreoffice, IAR embedded workbench, inkscape, okular not to mention GCC 5. Oh and the JVM of course. And unity (the game engine) is itself written in C++ even if most of the game code is C#. Oh and llvm. I almost forgot about that!

In the case of Firefox, C++ is apparently so far superior to everything else that the only way to move off C++ was to develop a completely new language, because nothing out there was worth moving to.

Fortunately, Rust is written by people who seem to know, understand and like C++, which means it has a much greater chance of actually being better, unlike all the supposed C++ replacements which are mostly much worse except for some small domain.

No good for system programming

It's excellent for systems programming. It's better than C in pretty much every single regard[*].

Later languages vastly improve upon it.

Such as? One of the nice things about watching a talk by Stroustrup is he has a bunch of pretty pictures about where C++ is used. C++ is on mars. And there's a reason you haven't heard about the Emma Maersk drifting around unpowered in the Pacific ocean (the ECU for the Flex96-C engine is written in C++). And there's also a reason you're almost certainly reading this post in a browser written in C++.

And not one of those other vastly improved languages.

So finally a challenge for you and everyone who modded you as insightful:

I like C++, but I could bend your ears for days about what's wrong with it, and why it's a pain in the ass in a variety if interesting and distressingly subtle ways. If there are vastly superior languages out there for what I do, then let me know, because I'd love to use them.

[*] The only regard in which it's not is that a few obscure platforms don't have a C++ compiler.

No generics

[renzhi]

I was playing with it when it just came out, and wow, the compiler was fast. It was great and all. So to find out how much I can do or to figure out my own skill level in Go, I started to port one of my C++ libraries to Go. That library has made heavy use of tree and trie data structures, which were implemented as template in C++. Then, bang, I hit a wall with Go. How to do generics? There was no way to do it. Looking on the web, I even saw someone create a kind of "compiler" to generate different code set for different types, say, you want a b-tree for class A? Fine, one set of code for that. Want a B-tree for class B? Fine, another set. Using his tool, I ended with five or six different sets of duplicated code, and I had a few more to go. That's when I stopped using that language.

Re:No generics

[ustolemyname]

Underscore is ignore. for loops operate in a key/value fashion, so:

for key, value := range values
gives you:
0, 1
1, 2
2, 3
etc.

In practice this turns out to be very convenient. You can switch storage between slices and maps without altering your code (both use the same key, value := range x form), and I know that your example above doesn't modify anything stored in values without having to look past the loop declaration.

Re:No generics

[goose-incarnated]

Neither do you, apparently. C++ (the language, not the library) is the largest programming language in existence. Nothing is larger.

[citation needed]

A clue: there is no citation because you're making it up.

So let's consider languages where actual formal specifications exist because they have to be written in excricuiating detail because the asusmption there is no reference implementation that people can refer to if in doubt.

[snipped...]

So there you go, there are 4 standardised languages I've given you which have longer specifications than C++.

Well Done. Now, where exactly did I claim that the english-language specification for C++ is larger than the english-language specification for other languages? I claimed that the language "C++" is larger, but only a moron would use number of pages of english text as a measurement.

The C++ language, as defined by its grammar rules in BNF, is larger than any other programming language, as defined by their respective grammar rules in BNF. This is well-known and is taught in almost every introductory compiler class I've reviewed.

Go ahead - look it up. Here's the BNF rules for java, 48 general rules for the programmer to remember, very few depending on context. Here's the one for C++, 80+ rules for the programmer to remember, many of them depending on context.

I'm not going to do your homework and search for the grammar rules for the other languages which you claim are bigger than C++; just refuting the one you listed is enough for you to ask yourself "Whats a BNF and why does it determine the size of a language?" If you do not get the relationship between "this is how much language a programmer needs to keep in their head to program" and "this is how large the BNF for the language is" then I'm afraid you are beyond my (and most professional) help.

(Hint: maybe register for some CS course in programming languages and compiler design? Or write a compiler or two yourself? You would do yourself a favour and learn enough to not use "number of pages in spec" as a measurement of a languages size (and/or complexity, but I didn't even start on that))

Given your propensity to simply make shit up about C++ [citation: see above], your statements lack credibility.

Your nerdrage whenever you perceive an attack on "your" language is laudable, however I suggest you stop being so unreasonably attached to what is only a programming language (albeit a very large one). C++ is what it is. Your insults won't change that.

Re:Sucks they're dividing efforts between Dart &am

[bledri]

Dart is an awesome language, and we have nearly a million lines of it running both client-side web and server-side. It is a spectacular language. Go is probably better on the server side, but you can't ignore the web. Imagine how much nicer Dart could be if they weren't distracted by Go.

Google has over 50,000 employees. They can do more than one thing at a time.

Re:And 400 Linus Clones Cried Aloud

[Anonymous Coward]

Someone isn't an embedded systems programmer. Many many embedded systems use C because its fast, flexible and flipping works.

IOW: Go is now self-hosted

[T.E.D.]

Having the compiler for a language written in itself is what pretty much every serious compiler is expected to do. Its called being self-hosted, and a compiler is generally not considered very mature until it does this.

So basically what this is saying is that Go has started to grow up.

Re:Can Go still not load shared libraries?

[KiloByte]

Static linking might be semi-adequate for stuff that you compile at home, but for any code that's distributed using static is a sabotage. For example, when there's a bug (security or not) in a library, you can't avoid recompiling the world. That's why distributions go for 100% dynamic linking, and why they dislike current Go.

Re:Can Go still not load shared libraries?

[Ian Lance Taylor]

The Go 1.5 release includes preliminary support for shared libraries. You can now build your Go programs to use shared libraries, on x86_64 GNU/Linux. You can also build shared libraries that can be linked into a C/C++ program, on several platforms.

Go has had an FFI for calling into C from the beginning: https://golang.org/cmd/cgo .

Re:iostream is a pig

[serviscope_minor]

But what are the advantages of this subset over C?

Better encapsulation, better type safety. better expressivity, much, much cleaner and more typesafe generic code. Oh and finally, C++ does things like virtual functions in a more memory efficient way that the idiomatic C way on modern processors.

And of course there's constructors which maintain your class invariants for you. Every time you declare a struct variable in C and then initialise it, you're writing boiler plate that C++ does for you. And every line of code is a potential bug. Having fewer lines means generally fewer bugs.

That and machines without enough memory to hold "significant support from the runtime".

The arduino environment is C++ and runs on an 8 bit Atmel with almost no RAM. I'm using IAR C++ workbench on some diddy little 8051 radio core with as few k.

All you've managed to do is to prove that part of the C++ standard library doesn't work well on tiny devices. You also proved that C++ is just fine, by running a C++ program with a different library to do the same kinds of tasks.

But yes, iostreams is not the highest point of the C++ standard.