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....
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?
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.
Google UK does give the language as its first hit, but also gives a bunch of darts clubs.
I guess it's not too bad. Programmers tend to be very active online, so the languages tend to get high pagerank. But still, if I were to create a language, I'd going to go for either a really obscure word, or a misspelling. I think searchability should be considered a feature.
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.
Some privacy policy Slashdot.
Someone isn't an embedded systems programmer. Many many embedded systems use C because its fast, flexible and flipping works.
A lot of people on this thread evidently think the jury is still out on that.
Sent from my ASR33 using ASCII
And this is why Google sometimes ends up confusing everybody by splitting their support down the middle. Look at Android and ChromeOS as another example of two projects that should be one and the same.
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.
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.
On when Google will suddenly back out of this language project - or both of them, as the case may be - and just go with Swift?
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 .
Yea, that's almost 2000 persons per letter of the Alphabet.
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.
As an actual embedded systems programmer, I can tell you that most of them use C because they can't grok (or even actively hate) C++. Sure, you don't want to go nuts with dynamic allocation (a bad thing in the small-system embedded systems world), but a subset of C++ * can be quite effecitvely used for embedded systems programming. Just limiting yourself to C99+classes+virtual method functions and static/auto scope objects can really improve the quality of your code over C.
* Yes, EC++ as a specific C++ dialect may be defunct, but IMHO it was created more for the benefit of compiler vendors who were having trouble getting templates and exceptions working properly back in 2002 or so.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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.
I think you've got that backwards. Dynamic linking is fine for stuff you compile at home, but for any code that's distributed, using dynamic linking will often cause your binary to *just not work* on another system.
Missing a shared library? Which package does it come in? Oh crap, that package requires dependencies I don't have, or are the wrong version, etc.. Or you have the shared library, but it is a different version, and the size of a structure or something changed, or a variable doesn't exist anymore, and your binary crashes, won't run with it, or produces corrupt output. Or you go through all of your dependency Hell and update all the libraries you need to install the package with the missing shared library, only to find that the libraries you updated caused other programs to break for similar reasons to why yours wasn't working with your current library version. Newer versions of libraries do not always maintain binary compatibility with older versions.
Some programs should just be statically linked, so that they will always work on any version of any distribution. Otherwise, there may be no avoiding a recompile and its associated dependency Hell. Static linking is a compatibility God-send.