Slashdot Mirror
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."
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.
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....
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.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
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.
Someone isn't an embedded systems programmer. Many many embedded systems use C because its fast, flexible and flipping works.
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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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 .
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.
SJW n. One who posts facts.
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.
SJW n. One who posts facts.