Slashdot Mirror
Go Version 1 Released
New submitter smwny writes "Google's system programming language, Go, has just reached the 1.0 milestone. From the announcement: 'Go 1 is the first release of Go that is available in supported binary distributions. They are available for Linux, FreeBSD, Mac OS X and, we are thrilled to announce, Windows. ... Go 1 introduces changes to the language (such as new types for Unicode characters and errors) and the standard library (such as the new time package and renamings in the strconv package). Also, the package hierarchy has been rearranged to group related items together, such as moving the networking facilities, for instance the rpc package, into subdirectories of net. A complete list of changes is documented in the Go 1 release notes. That document is an essential reference for programmers migrating code from earlier versions of Go. ... A similar process of revision and stabilization has been applied to the App Engine libraries, providing a base for developers to build programs for App Engine that will run for years.'"
The style, or your preference for a particular style, is not important in the least. What's important is the consistency. Really... *nobody* cares what style *you* prefer.
my other sig is written in brainfuck
So do good ones.
--
The GP referred to Fortran and C as well as python.
Increasingly we're seeing lots of legacy code (C / C++ / Fortran) wrapped in Python. People using Python for simplicity and expressiveness, dropping to C , etc. for the heavy lifting. This is especially true in the sciences (in HPC, for example).
Trying to avoid the language flamewar, there are distinct advantages in a small number of interoperable languages like this.
If I'm to try a new language, I want to avoid having to rewrite the world in it. I might convince my colleagues to use my code if they can interop. from the language they are already using, like C/C++ or Python.
Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist
I would stay away from Go and pick up Python. It has lots of good libraries and frameworks. Its used in some games and lots of open source projects as their scripting language. Python is a very expressive and general purpose language. It does not appear to be going away within the next decade and in fact I expect Python to become much more prevelent once PyPy becomes more robust. Added to all that, extending Python with commonly available libraries is not a difficult task and there are numerous approaches (each with varying pros and cons) for doing so.
I see language designers are still making the mistake of trying to represent characters as fixed size entities. Go 1 adds a new data type 'rune' intended to represent a UTF-32 codepoint, which is fine as long as it's only used for code points, but then the example code they show is:
:= '' // delta has type rune.
delta
var DELTA rune
DELTA = unicode.ToUpper(delta)
When you design an API that accepts or returns individual characters (as opposed to code units or code points), do not use rune, char, wchar_t, char16_t, char32_t, int, or any other fixed length type to represent a character. Characters are fundamentally variable length.
You should use a string data type because fixed size types can only represent a subset of characters. For example, a single UTF-32 code point cannot represent the Lithuanian characte LATIN SMALL LETTER A WITH OGONEK AND ACUTE. In Unicode this character can only be represented as a sequence of multiple code points (<U+0105> <U+0301> or <U+00E1> <U+0328> or <U+0061> <U+0328> <U+301>). So using strings works whereas using a fixed size type will inevitably fail.
Using strings to represent a character has another advantage beyond the fact that it's the only way that works. It eliminates the client's need to convert between the string type and the type used to hold a code point. Clients can just directly use text in whatever the native encoding is.
It is supposed to be a systems language like C, but better.
IMHO, if it isn't standardized, opened up and backed up by an international standard then it will never be better than C. For all problems that may or may not affect C and for all problems involved in the development and update of a standard for each version of the C programming language, these multiple versions of the C programming language are effectively set in stone. This means that the language is future-proof, as multiple implementations may be developed and, by targetting the standard, they can interoperate without any major consequence.
If Go isn't standardized and if Google intends to control the language then it would be a terrible decision to adopt Go instead of a time-tested, well established tool which is future-proof and resistent to bit-rot. We all have Oracle and Java as a good warning.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Go may be a fine language. I'm not sure, I've not really looked at, but it does have some neat things in it. However, that does dound a little fuddy to me.
Computers are enormously quicker but software development is not faster.
I program mostly in C++. In the last 10 years, even ignoring C++11, the C++ landscape has changed enormously, with compliant compilers and advanced libraries. C++ today is nothing like C++ in 2002 and even the same language has turned into a much more effective platform.
There is a growing rebellion against cumbersome type systems like those of Java and C++, pushing people towards dynamically typed languages such as Python and JavaScript.
There was a growing rebellion. Maybe I'm misjudging the general feel, but there seems to have been a bit of a backlash, especially as programmable typesystems have become more mainstream, people have found them to be an exceptionally powerful mechanism for catching bugs before they happen and for expressivity. 5 years ago I would have agreed with that statement (though I personally have always preferred static typing). These days, not so much.
Some fundamental concepts such as garbage collection and parallel computation are not well supported by popular systems languages.
Some popular languages don't generate garbage in the first place (and can automatically clean up any resources). It's obvious they're taking a dig at C++ there. As for parallelism, there are several (nonstandard) mechanisms in which C++ supports threads, depending on the tasks at hand. Some of them (such as OpenMP) are quite task specific, but within the domain are easier to use than just about any other threading system I've ever seen.
The emergence of multicore computers has generated worry and confusion.
That's really not in favour of Go or anything else.
Go's type system has no hierarchy, so no time is spent defining the relationships between types. Also, although Go has static types the language attempts to make types feel lighter weight than in typical OO languages.
That doesn't sound like an advantage. If types are related, it's kind of handy to be able to specify relations. That poor programmers have abused massive type heirachies in other languages doesn't make them inherently a bad idea. Bad programmers will find a way to abuse any language feature.
SJW n. One who posts facts.