Slashdot Mirror
Go, Google's New Open Source Programming Language
Many readers are sending in the news about Go, the new programming language Google has released as open source under a BSD license. The official Go site characterizes the language as simple, fast, safe, concurrent, and fun. A video illustrates just how fast compilation is: the entire language, 120K lines, compiles in under 10 sec. on a laptop. Ars Technica's writeup lays the stress on how C-like Go is in its roots, though it has plenty of modern ideas mixed in:
"For example, there is a shorthand syntax for variable assignment that supports simple type inference. It also has anonymous function syntax that lets you use real closures. There are some Python-like features too, including array slices and a map type with constructor syntax that looks like Python's dictionary concept. ... One of the distinguishing characteristics of Go is its unusual type system. It eschews some typical object-oriented programming concepts such as inheritance. You can define struct types and then create methods for operating on them. You can also define interfaces, much like you can in Java. In Go, however, you don't manually specify which interface a class implements. ... Parallelism is emphasized in Go's design. The language introduces the concept of 'goroutines' which are executed concurrently. ... The language provides a 'channel' mechanism that can be used to safely pass data in and out of goroutines."
One of the things I immediatly noticed is the lack of build-in libraries. The reason I've always preferred Delphi and C# over C/C++ and PHP over Perl is that they all come with a comprehensive build-in function library for wide area of things.
Programming now a days tend to be mostly high-level, so you would expect that new languages would provide that. I personally hate to find tons of different libraries for C++ projects just to do a basic thing. And lets be honest, theres no sense of everyone of us to code the basic functions again (and probably in worse code than the regularly checked build-in functions)
That is why I love PHP, and because it provides a great manual on its functions. That is also why I love Delphi and why I started using it as 10 year old, without internet too - the reference guide that came with it was comprehensive and the build-in libraries and components for different things allowed me to rapidly try out to code apps and games. Only time I needed to find some libraries/components was when I was looking for a more rapid and better graphics library to do the drawing in my games.
That is what would be "fun" in a programming language. It comes a lot before "fast builds, clean syntax, garbage collection, methods for any type, and run-time reflection."
Go Go Google Language!
Can somebody call hell to see if they can host the next Winter Olympics?
Not having much luck. It can't find /etc/passwd, /etc/group or /etc/hosts. All of which do exist. I'm inserting fmt.Fprintf statements to attempt to figure out why it is having problems.
A novel idea: make people learn Go by requiring them to modify it in order to install it.
It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?
Vowels aren't nearly as expensive as they used to be back in the day.
It'd be a nice touch if they'd add vowel support in package names.
I don't think so. I have an old Thinkpad 701C laptop which ain't compilin' this in under 10 seconds, if at all.
From a brief review of the language and implementation, this doesn't appear to use what we've learned about correctness over the last thirty years. Buffer overflows are just one bug class among dozens, and if you're going to create a language from scratch, why let integers overflow without making people explicitly request that behavior? Why ignore what we've learned about verification and formal languages? Microsoft has actually been far more responsible about this recently, thanks to the Java people they hired (Rustan etc); see Spec# for details.
This bodes well.
Does Go have goto statement ?
I don't like how this language uses "func" instead of "function", therefore this language is terrible and everyone who uses it or thinks about it in any way except for about it sucking is also terrible.
They're billing Go as a "systems language." If by "system" they mean "application server in a Google data center" then I suppose that's correct. Previously the term "systems language" referred to languages suitable for operation system implementation, including device drivers, virtual memory management and other persnickety low-level software. Lack of pointer arithmetic and explicit memory management probably precludes any attempt to use Go as a "systems" language by that definition (although there are exceptions to that thinking.)
There is too much competition from other fresh and well regarded "new" languages for yet another new entrant to gain much headway without something really novel to attract attention. Not that trying is bad; by all means keep at it. Can't afford the mental bandwidth to jump on more new bandwagons, however.
Lurking at the bottom of the gravity well, getting old
The game may well be the most difficult to master of all games in history, but it is simultaneously one of the easiest to learn and to enjoy. Which actually does bode well for the language. If Go (language) is to C as Go (game) is to chess, then they nailed it.
But, as I just posted in another thread here, there are other problems with the naming.
Besides people who work at Microsoft, that is.
I've been around for a long time.
C great language did exactly what it was designed to do. But carries a lot of burden.
C++ come on it didn't even have a string class. Thus pointer math hell.
C#, Ok it learned a lesson and found the joy of a string class. But really it's a windows only lang.
Java. Excuse me web apps that take 8Gig of ram spread across a farm of servers. This slow elephant remade the hardware business.
All of the above never really understood concurrent / multithread / parallel. ( Sorry Java devs still have issues with the concept. GC & log4j come to mind as things that forgot they were in a threaded env. )
So the "Go" lang it just might deserve a look. Clearly web centric. Clearly built for tons of concurrent comms. Recompiles in a blip thus useful for real time compiling alla jsp. I'm very performance centric. If I can replace my J2EE bloat ware with a trunk full of tiny Go apps I will.
I'm definitely watching this space for developments.
One thing that suprises me about this is that there's no reference to this being a Google project on the front page. Is this a deliberate move to seperate it from normal Google activities? To give it more of a chance as something other than the latest Google fad? Any ideas? It doesn't even look like it's geared specifically towards web apps.
and have the pleasure of intellisense adding stuff like String.Format...
I'll take fmt any day of the week.
This is my sig.
Go has garbage collection and lacks pointer arithmetic. So... it won't replace C++, then?
Why was that so easy and quick to say? I really don't understand the repeated banging-head-against-wall that language inventors are doing. There's a good reason why C++ is still in wide and very popular use: precisely because it does have explicit memory management and pointer arithmetic. C++ is a static, explicit language. Go is not. It will not replace C++, and no language will until that is understood.
The problems C++ need fixing are elsewhere. The syntax needs cleaning up. The ABI needs rationalizing between architectures. Multiple inheritance needs some taming (ditch 'virtual' multiple inheritance - it's insane), but not removing. Interface-only classes need promoting to a full type rather than inferred from being 100% pure virtual (and even then there's usually a non-pure-virtual destructor for stupid foot-bullet-avoiding reasons). There needs to be saner syntactic sugar for repeated operations (like python's 'with' keyword). Templates syntax needs to be less verbose and more automatic (already being worked on for C++0x but at this rate will be C++1x, keyword 'auto').
Stop trying to replace C++ with a language that does not fulfill every aspect C++ covers. If you ARE a language inventor and reading my comment, answer this: can you write a cache/MMU interface or an interrupt handler in your language? If the answer is no, go back to the drawing board.
Despite the large amount of enthusiasm for language design, modern mainstream programming languages don't fall far from the C tree.
Perhaps, like Qwerty, our C-based languages have evolved to be "good enough" for programming needs for the foreseeable future. Make objects, make functions, operate between the two.. sure DVORAK might provide 20% faster typing if you work at it for 3 years, but that's not really enough to warrant the switch. We're unlikely to see a jump again of the size from C to C++ before we hit a major structural change. I had thought the web might be that structural change, but that was well absorbed by extending existing ideas.
Personally, I just want to see programming languages that are more programmer fault-tolerant. I can type "pizza" into my phone and have Chuck-E-Cheese offer to bake one while I drive over, but if I accidentally type "plaeyrArray" instead of "playerArray," the whole world is clearly on fire and everyone is going to die. Why can't compilers be more intelligent about the types of errors they encounter in routine usage? For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?
The ______ Agenda
Or maybe we should drop the term "Library". M$ probably has it trade marked. I vote GoNads!
Joy, yet another programming language :-) Programming languages are personal. We all have our favorite way to do things and most of the choices are subjective preferences. At c2.com we played around with the idea of a Build-To-Order form to generate a compiler/interpreter for a language with the combination of features you ask for. Below is a rough re-creation of the form:
-----INSTANT CUSTOM LANGUAGE FORM-----
(Features in each group are mutually-exclusive if they have round brackets, but not if square brackets. )
Compile Level
* (__) Compiled: product of language targeted to direct run by a machine (possibly a virtual machine) or operating system.
* (__) Interpreted: language is processed as data by a process called an interpreter, especially in some sort of ReadEvalPrintLoop. May support a hidden JustInTimeCompilation, but that should be considered an implementation detail rather than a language detail.
* (__) Both but select on Program: language allows programs to be written for scripting or written for compilation, but programs written for compilation might not work for interpretation (e.g. due to late-binding dependencies) and programs written for interpretation might not work for compilation (e.g. due to top-level commands). This provides a lot of flexibility. However, it also partitions the user community because sharing will be difficult.
* (__) Both for any Program: language ensures that every program is suitable for both compilation and interpretation. Supporting interpretation requires abandoning a model of external linking and requires ensuring the syntax is suitable for one-pass reading (i.e. preprocessors are a bad thing). Suitability for compilation implies abandoning (or at least distinguishing) imperative commands at the toplevel: those that are to be executed at compile-time vs. those that are to be executed at runtime.
Model for Linking and Modularity
* (__) No Linking: product is always fully declared from a single page or file. No linking occurs. There is no model for modularity. Many EsotericProgrammingLanguages have this model. Support for CompileTimeResolution may provide an interesting workaround.
* (__) Includes: product may 'include' other pages, which are linked in place. There might be a system to selectively avoid duplicate includes. All pages are effectively parsed with each compile or execution.
* (__) Single Page, Modular: language semantics allow 'importing' or 'loading' of other components. Allows useful optimizations such as compilation of components... or at least preprocessing and pre-parsing, of language components, because the semantics of the 'import' are held independent of the page into which it was imported.
* (__) External Linking: a linker can combine a product by pulling multiple components together, but does so from outside the language. This model is incompatible with interpretation, and offers no real benefits over the 'Single Page, Modular' model except that it can be hacked into a language that doesn't have a concept of modularity (as was done for CeeLanguage).
Modularity and Linkage Features
* [__] Resolution of Circular Dependencies: the language or linker will correctly handle circular dependencies, ideally with minimal reliance on forward declarations.
* [__] Provisionals and Overrides: the language allows you to override global objects, values, or procedure that are declared in other modules in a manner such that those other modules use the overrides, too. Ideal form would be as though they had always used the override, but this ideal form is somewhat difficult to reconcile this feature with interpretation.
* [__] Inverted Constructs: one can automatically bui
Table-ized A.I.
C++ standard library has string class. Somehow most C/C++ coders has this strange fixation to write everything from scratch. Thanks to them it data type conversion hell every time when you use two or more libraries in your project.
I'm not going to suggest you should use C++ but seriously, can you at least use real criticism? What is std::string then?
And no, "that was only added in 1995" doesn't count as a criticism since C++ was not defined as an ISO standard until 1998 and std::string has been there ever since.
$ cat hello.go
package main
import "fmt"
func main() {
fmt.Printf("hello, world\n")
}
Size of resulting binary: 581054 bytes on x86 Linux.
Anybody want a peanut?
It's simple. It's a lot of fun to design and even implement your own programming language. It is not too hard, depending on how big of a problem you choose to bite off with your language. And then there are the oohs and ahhs you get from other developers when you have implemented a language, especially if it compiles to some real or virtual architecture.
Too bad learning to use a programming language effectively is a lot of work, and is usually pretty frustrating. It has been easy for me to find the time and energy to implement my compiler. But I totally don't have the time to learn C++, Haskell, Python, OCaml, Ruby, PHP, Perl, et cetera.
As a developer, and I realize this is a very silly and irrational, I tend to avoid using programs written in languages I don't understand. True, I almost never look at the source for the program. But take Gentoo emerge for example. The fact that it is written in Python instead of C, awk, shell script, Tcl, Lua, or Java is mainly why I don't run Gentoo.
“Common sense is not so common.” — Voltaire
This fellow has been working on his own programming language, also called "Go", for a decade. Even released a book about it. He filed an issue in the tracker for the Google language: http://code.google.com/p/go/issues/detail?id=9
'Every story, if continued long enough, ends in death.' --Ernest Hemingway
I was just about to bemoan the naming, which conflicts with Go (the board game), which is already difficult enough to google. The fact that it's GOOGLE making this mistake is pretty bad. On the other hand, maybe they'll fix the bug in their search engine now, and make it easier to google both :)
If this language becomes as popular as Perl, then 120,000 lines will soon become 1,200,000 lines. That is exactly what happened to the Perl interpreter and compiler.
Also, just like Java, the new Go language (due to the immense respect for Google's scientific prowess) will likely receive accolades: "it is the best, final language that we will ever need". The same was said for Java. It was sold as the ultimate final language built on 50 years of accumulated knowledge of language design and computer architecture. Upon the introduction of Java, company after company blindly adopted it.
Was Java the final language satisfying humankind's computing needs? No. Was adopting it worth the cost? Maybe.
Now, we have Go. Is it a massive improvement over C and Java, thus justifying spending milions of dollars to train programmers? Only the future will tell.
That's probably because the C++ standard library isn't so easy to remember.
But apparently not exceptions? It sounded good in theory. Lack of assertions was going to bug me. Lack of exceptions and try...finally blocks is most likely a deal-breaker. I'll read the thing in detail at some stage and see if they provide a decent alternative though.
Found confirmation of this in Go's "Language Design FAQ":
So in other words, they left every single user of the language to do it, over and over again, because it seemed like a lot of work for the team to do well, once. Sorry, but that just doesn't cut it.
As for exceptions increasing control flow compensation... Java had this right; if a function's interface specifies what it throws, then you by definition save yourself a lot of control flow headaches, as you know exactly what calling a function can result in.
How many amateur developers will have this plan in their mind?
1) Code an application in Go language instead of something more fit to that purpose
2) Host it at Google code
3) Get hired by Google
Let me tell you the thing, just like top end Hollywood directors/producers/cast guys doesn't browse IMDB (Pro!) to hire new people, Google owners doesn't browse Google code to pick developers.
I learned c++ back before the STL was, er, standard.
Do you even lift?
These aren't the 'roids you're looking for.
Altough the FAQ doesn't mention Plan 9 anywhere; the "channels", the C-like syntax and the logo all let me think about this nice OS with his concurrent programming language called Alef, designed by Phil Winterbottom. (Rob Pike and Ken Thompson were very involved in the Plan 9 design). Well, the comparison ends here I guess.
C++ did not have a string class when it first came out. Thus the landscape of C++ code was polluted for ever more with dodgy string classes.
Note I used "didn't" in my statement.
I mean, I get the whole we like to do concurrent staff. But does the world really need another programming language? There has been a literal outbreak of new or revamped programming languages in the last few years. Are we seeing now with programming languages what happened to linux distros a while back? If so, what languages will emerge and what will just merge with others?
Finally, a C++ user giving clues for a better C++, instead of the usual ones from non users.
No, his is simply "Go!" with an exclamation. See: http://portal.acm.org/citation.cfm?id=998367
Google is screwed, they'll need to change their name for this language or buy this guy off. If they ignore this guy they'll look like a bully.
It's amazing no one at Google did a search go "Go Programming Language"
-Malakai
A Dragon Lives in my Garage
I watched the presentation. It was about time for Google to join the programming language space, but I was not impressed as much as I had been with other Google projects.
Go is fast: Sure. But compared to what? C and C++? They were never known to be fast compiling languages. Go is still a very simple language. So compilation speed is not impressive, relevant or novel *yet*. I recall from my Pascal (Delphi) days of how blazingly fast the compilations were when the language did not have a pre-processor or generics and had a more strict type system. Once Go gets generics and exceptions, we can see how well it compares to similar modern languages.
Go is safe: I somehow kept seeing OCaml in a C style syntax in all this despite Go not being functional (perhaps I am just sleepy :-) ). Better type system, garbage collection, optional typing, higher data types. Imperative Ocaml also only takes a minor performance hit compared to C despite providing a much safer language.
Concurrency: This could be something. The languages with built in support for this are somewhat obscure ATM (Erlang). Hopefully, Go will be more palatable to the mainstream.
Programming languages are finally more than grammars and compilers. Many excellent languages never make it to limelight. C and C++ continue to be first choice for system software despite the existence of several excellent "language" alternatives. Google brand may help Go with an early boost, but it will be the tools, libraries and the community that will have to deliver it; or we will just have another Java FXScript story in front of us.
Array slices and mapping types have been around for decades. Not even Perl was the first to provide tham, et alone Python.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
But wait! "Go Go Google Language" is just the right number of syllables to be the Power Rangers Theme song! Oh no! Curse you the 90s and your many memorable children's shows!
With google stealing "chrome" and now "go" from others, and their retarded "closure" library, and other example, I have to wonder if google engineers have zero creativity themselves, or if they are just assholes.
If they are going to use the word "safety" as an adjective for C/C++ then they seriously have no clue about what makes a programming language "safe" with respect to security and have ignored the last 20+ years of programming language development in this area.
I like GOOP
Google Object Oriented Programming language
Perl and Python have a nice distance from C grammar rules.
Java sticks in pretty tight.
Go isnt close enough to guess, or far enough away to be distinct.
Printf instead of printf no. The for loop.. same syntax, but no parens.. with infinite loop behavior in "for{STMT}"
sure I can use parens.. but I can force other peoples code to not use jacked conventions.
And yea, I kinda feel that a language should have a core, and a simple way to go full featured, without sending a beginner to cpan and explain the make process, explain the :: conventions for something as simple as making a window with a few buttons.
The whole object oriented window system.. needs the low tech version, where a whole paradigm doesnt need to be explained, just to do a simple parameter->okbutton-> render function.
Baseline is that I see a language that doesnt make coding fun.. := "hello world" WTF?? like some pascal-C cross breed. it's clumsy.. and conflicts with the pattern in my head of how a var should be declared.
The memory protection seem alright..
perl's @junk=LessThan_GreaterThan; is a thing of beauty (slashdot parses the symbols sorry)
Python and ruby's huge integer types.. no C++ NTL hassles awesome.
var s string
(*) Unfortunately for them, there's only one way to be sure...
Because C# was screwed.
And C++ was screwed...
And JavaScript couldn't be called JavaScript because Java existed.
I have been wondering for years what programming language Skynet uses.. Woohoo!
Unfortunately, in the real world, Google is huge, the "Go..." bit is going to ring immediate bells. Mr. McCabe made a bad choice of language name and he should stop complaining to Google and instead change it to something else and ask them to publicise the change - which I am sure they would do, and would get him more attention.
No, I'm neither pro nor anti Google, but this is a case where realism is in order. To use the essential car analogy, suppose i was a custom builder and for years had made 10 cars a year with the model name "530". Then BMW come along with their long established 5 series and also release a 530. Is it realistic to expect BMW to change their model designation? I'm sure a lawyer would take on the case if his client had deep pockets, but his expectation of winning would be diddley squit.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
The STL (T stands for Template!) has nothing to do with the strings library. You are talking out of your arse.
From Golanf.org : "With Go we take an unusual approach and let the machine take care of most formatting issues. A program, gofmt, reads a Go program and emits the source in a standard style of indentation and vertical alignment, retaining and if necessary reformatting comments. [...] We use tabs for indentation and gofmt emits them by default. Use spaces only if you must."
Of course you realize ... this means war.
If all else fails, immortality can always be assured by spectacular error.
Just imagine, playing Go in GoEngine. Written in Go. Yeah. That's sweet. :D
systemd is not an init system. It's a GNU replacement.
When you say "yes!" you don't go "yes factorial", not even if you are easily excited by math.
Vowels aren't nearly as expensive as they used to be back in the day.
It'd be a nice touch if they'd add vowel support in package names.
I can expand the name "fmt" in my head as I read it. I can't really expand my typing from "fmt" to "format" as I type it without typing it, or without having some auto-replace thing which then goes ahead and does the wrong thing sometimes (which I then have to undo), or I have to explicitly say "yes, expand this" which takes extra key presses (which we're trying to avoid), or...
If you ask me, it'd be a nice touch if they kept the support for brevity in their package names.
Otherwise, we end up with ArrayIndexOutOfBoundsException rather than IndexError.
why wonder when you can look it up? http://golang.org/doc/go_spec.html
I prefer this reference ;-)
http://en.wikipedia.org/wiki/Considered_harmful
These posts express my own personal views, not those of my employer
People will read a piece of code more times than they will write it, so it makes sense to optimize for readability.
If you can make the code 1% more readable (pick your measure) at the cost of making it take twice as long to write, is that worth it?
If you can make the code 1% less readable and simultaneously make it twice as fast to write, is that worth it?
Also, it's a particular name we're talking about. Is python unreadable because it says "len" instead of "length"? Is it bad to say "IndexError" instead of "ArrayIndexOutOfBoundsException"? Is it bad to say "" instead of "System.out."?
Of all things, I think names (with vs. without vowels) have the smallest impact on readability. Descriptive names are important, but I think it's much more important to be able to write code that has an easily comprehensible structure.
The string class example was bogus but he has a point. It does seem like every library wants everything stored as its own special type of whatever. Including strings.
Google is developing a real, 'Not Invented Here' complex. Rather than get behind Firefox, they produce their own browser. Rather than integrate tightly with OpenOffice, they produce Google Apps. Now they've written their own programming language. Go figure. And of course there's always those rumours of the Google OS...
Never trust a man in a blue trench coat, Never drive a car when you're dead
I wonder if the chinese name for the programming language will be Weiqi, just to screw us over.
We've also figured out how to make memory management a non-issue, we don't want no steenkin' garbage collection.
I looked at GO and I'm not sure what it brings to the table that can't be done better with C++.
Maybe
a) Slightly cleaner syntax - no big deal once you're used to C++.
b) No pointer arithmetic - less chance of stray pointers, sure, but you should be using STL anyway. If you're still banging pointers around in C++ you're Doing It Wrong (except for very low-level code).
No sig today...
is the go programming language logo a hamster or a bear?
They're the only two features of Go which stand out, and I'm not sure I want either of them.
PS: While we're fixing C++ can we get rid of arrays? (ie. new[] and delete[] )
No sig today...
Altough the FAQ doesn't mention Plan 9 anywhere; the "channels", the C-like syntax and the logo all let me think about this nice OS with his concurrent programming language called Alef, designed by Phil Winterbottom. (Rob Pike and Ken Thompson were very involved in the Plan 9 design). Well, the comparison ends here I guess.
Parallel processing, channels and array slices made me think of Occam.
The 1990s is calling and wants the C vs. C++ wars back.
No sig today...
So the guys at Google, could not be bothered to, er, google for "go language" or "go programming language" out of politeness, so the other guy has to suck it up for being just him, a one man band.
What a wonderful concept of decency and fairness.
IANAL but write like a drunk one.
Can some expert compare Go with the D programming language?. Looks like D already took what's good in C and C++ and now it's a stable and damn fast language.
Actually JavaScript being called JavaScript was a hideous decision - even now I read comments from people who think it's something to do with Java.
It's official. Most of you are morons.
package main
:= bottlecount; i > 0; i-- { := bots(i);
import (
"os";
"fmt";
)
const bottlecount int = 99
func bots(b int) string {
if b > 1 {
return fmt.Sprintf("%d bottles", b)
}
if b == 1 {
return "1 bottle"
}
return "No more bottles"
}
func main() {
for i
b
os.Stdout.WriteString(b + " of beer on the wall, ");
os.Stdout.WriteString(b + " of beer.\n");
os.Stdout.WriteString("Take one down and pass it around, ");
os.Stdout.WriteString(bots(i - 1) + " of beer on the wall.\n\n");
}
os.Stdout.WriteString("No bottles of beer on the wall, no bottles of beer.\n");
os.Stdout.WriteString("Go to the store and buy some more, ");
os.Stdout.WriteString(bots(bottlecount) + " of beer on the wall.\n");
}
aka Gardener, aka ollej
Do we really need more programming languages? Aren't there enough to do everything yet?
Shouldn't we be trying to reduce the number of languages, rather than add to it? Or even better, create yet another layer of abstraction between us and the machines that gets us away from being slaves to syntax?
I find that if you shorten long words arbitrarily, it actually increases the writing time.
I could write ConnectionManager pretty quickly just due to typing experience in English. The words just flow from my brain onto the keys without even thinking about the individual letters. But if you shortened to CnnctnMgr then you have to think about it every time you type it out, what letters have I taken out again?
It gets more difficult when you're working off someone else's code. If you shorten long words but not short words then later on when you're looking at new code it takes much longer to get used to variable names. If you stick to a convention and don't shorten any words, you sometimes don't even need to see the variable being used to know what it's called, and can use them without thought.
ArrayIndexOutOfBoundsException is clearly a poor joke, however. I always hated that one.
being vague is almost as cool as doing that other thing...
Well, since Go has some native support for concurrency, it shouldn't be that difficult to have it running on a Beowulf cluster...
Are you insane? Have you ever written a parser?
I've written my share. And I've read (and, I think, understood) how python does it.
Really, it's not that bad. Simply look at each line and see if it's indented more than the previous; if so, add an OPEN_BRACE token; if less, a CLOSE_BRACE token (or call them OPEN/CLOSE, BEGIN/END, etc.). Then, once you've transformed the indentation structure into tokens, parse the rest.
You can probably do it faster if you do it on the fly (i.e. at the same time as "parse the rest") rather than in two passes, but the idea is more easily comprehensible this way.
Also, my practical experience with writing loads of python and more than my fair share of Makefiles suggests that it all Just Works (tm).
At least as long as you don't mix tabs and spaces. It's quite easy to write a shell script which tests for this and warns you. Also, any decent editor with an embedded lisp dialect can be made to highlight tab/space mixes (or just run your shell script in the background).
Why the big worry?
You are all missing the important point of this language (or I've not seen anyone mention it yet), and that's it's concurency model. No, it won't replace C++ for some things, but it implements part of CSP, a VASTLY nicer model of concurrency than the traditional threads/locks model. You try write a program using threads and locks with 1000 threads all intermingling and prove there are no race hazards or deadlocks, then try the same thing in a CSP based language (this, occam-pi, Java with JCSP, even Javascript with worker threads). I can guarantee that for any non-trivial program this will be far easier in the CSP language, which is very important in the modern parallel market.
I was instantly happy to see this as I work in an area of concurrency research, involving a lot of CSP which most people have simply never heard of, or don't understand. This may not replace other languages for all things, but it will hopefully be a good start point to bring CSP to the masses.
Templates is one of C++'s advantage over any other language (except D that implements them). Without templates, type safe containers and reusable algorithms cannot be implemented. For example, in Go, a List class would have to use void* types, throwing type safety out of the window.
The syntax is also not that good. That the type goes after the variable name, the missing parentheses in 'if' and 'for' statements are syntactic changes that offer no better readability over C.
Finally, the built-in channel mechanism is something that can be done in C++ in less than 100 lines of code.
You seem to be complaining because Google is working on technologies which are not your technology of choice. But far from an NIH, they seem to be giving serious traction to existing technology which best suits their needs.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
I'll learn it on the go.
Hey! At least they don't use Hungarian Notation!
What kind of an "open" language is it, if it's website is blocked in Syria (and probably the rest of USA's embargoed countries)
I think they just chose the name so they can use their page numbering convention for future versions:
version 2: Goo
version 3: Gooo
etc.
I will probably mature around the time Goooooo comes out - can't wait to use it!
sic transit gloria mundi
A video illustrates just how fast compilation is: the entire language, 120K lines, compiles in under 10 sec. on a laptop
When would dev's ever have time for wheelie-chair sword duels?!
Finally had enough. Come see us over at https://soylentnews.org/
Go seems to suffer from the problem of not being done. Case in point: exceptions.
Google's C++ style guide forbids exceptions. This is because of historical reasons - Google's codebase is not exception-tolerant.
Because Go doesn't have exceptions, programmers won't write exception-safe code. Since Go is garbage-collected, this is less of an issue compared with C++, but there are still cases where things like file handles or external resources need to be cleaned up.
Two, three, or four years down the road, it's going to be hard to use exceptions in Go, because the existing code that's out there won't inter-operate properly with code that throws exceptions.
In my opinion, exceptions are absolutely, positively critical in a modern imparative programming language. Exceptional conditions happen. Parsers get data in the wrong format. Network requests time out. Hardware fails.
There are some exceptional conditions that should never happen, and if they do they should kill the system and print something that lets you track down the problem. Exceptions provide this behavior for free; simply don't catch them and you get at least a stack trace when they occur.
The alternative is to write a bunch of error handling code to print out debugging information and exit. Then you call it from everywhere that one of these critical errors occurs.
Except, what if you want to handle one of these critical errors? What if you're calling code that exits if it fails, but you want to report errors in a different way? What if the exceptional case is supposed to happen, like if you're writing unit tests?
The other type of error isn't critical. Maybe it's a network timeout or a parsing error, neither of which should probably crash the system (in most cases). Here, you want to handle the error and take some action, like re-sending the data or asking for input from the user again.
Error codes work here, except that they're cumbersome. Want to include information on exactly what kind of a parser error occurred? Now you're going to have to return both an error code and an error string. Maybe you'll even return an error object.
What if the error occurs in a private method (lowercase first letter in Go) that's called by the public method (uppercase first letter in Go)? With exceptions, you just throw in the private method. With error codes, you need to check for an error code in the public method when you call the private method, then pass the error along.
heya,. Actually, if you look at the issues, you'll see a number of people make the very valid point (e.g. comment 66, http://code.google.com/p/go/issues/detail?id=9#c66), that the languages are "go", and "Go!". And a lot of languages already differ by one character - C, C++. and C#. Or A+ and A++. Or Alef and ALF. Or GM and GML? Or how about Modula-2, Modula-2+ and Modula3? Look it happens, you don't see anybody flaming each other on those languages, getting them to change. I don't see K&R flaming Microsoft about C#. Cheers, Victor
nobody expecting a NSString cares if you use the mutable version of it.
If your class holds a reference to a string, and it has checked the string to make sure it contains only (for example) alphanumeric characters and dashes, you don't want any other code to modify the string to insert characters you don't expect. That's why languages like Java, Python, and PHP make a new string when a program modifies a string.
C# is not a windows only language at all. Mono is a pretty complete implementation of the .NET Framework on Linux (with some good progress on OS X). A lot of really cool apps, such as Beagle, Banshee, F-Spot, Tomboy, and Gnome-Do, are written for Mono.
But if you shortened to CnnctnMgr then you have to think about it every time you type it out, what letters have I taken out again?
The canonical abbreviation for "Connection" that I've seen in numerous libraries is "Conn", and Mac OS documentation has abbreviated "Manager" as "Mgr" since the days of Inside Macintosh. So people would expect ConnMgr.
Umm... I'm not a friend of java (time and updates have dulled my hatred of late 90's java), but wasn't ArrayIndexOutOfBoundsException just arrayindexo[tab] even way back in the day? I think normal geeks can type Array and Index with 5 hand twitches ar ray ind e x.
I also ran into a problem where a coworker told me to use his function ConnectionManager (changing names to protect the innocent). He had abbreviated it CnntMgr. How do you search for that crap?
The STL (T stands for Template!) has nothing to do with the strings library.
The C++ standard library consists of the C standard library, the iostream library, and the STL. In the STL, std::string is a specialization of the template class std::basic_string.
If you're still banging pointers around in C++ you're Doing It Wrong (except for very low-level code).
And because not all third-party libraries already have C++ bindings, you still need to write "very low-level code" quite often when you make your own.
You have to call it ConMan
but if you're writing e.g. desktop productivity software, does it really matter that you spend 3% of your application time in the GC?
It matters if the 3% of application time happens all at once, making the application appear to be frozen, while the user is waiting to be able to do something. A runtime environment's garbage collector needs to be incremental, invisible, and concurrent, or the same implementation issues that you restrict to Doom 8 will start showing up in Word 15.
C++'s templates offer a lot more than just generics (which is what you're talking about when you say "type safe containers and reusable algorithms"), however Go does, in fact, provide for this with its "interfaces." The Go interface affords for both data abstraction (akin to C++'s inheritance hierarchy), and generic programming. Go provides an "Any" container, which "may be used to implement generic programming similar to templates in C++".
It's worth noting though that this is a dynamically bound language feature, which means it is checked and enforced at runtime rather than compile time -- both a positive and a negative depending on how you look at it. It provides for some more interesting programs to be written that do fun things at runtime, but on the down side it means you lose a lot of the compile time type-checking that C++ provides and can save a lot of debugging time later on. It also means that you can't do any template metaprogramming with Go -- again which can be viewed as a positive or a negative.
I also challenge you to come up with a solution that equates to Go's built in Channel's in less than 100 lines of C++. What you're actually saying is you "can implement Go's Goroutine's AND Channels in less than 100 lines of code in portable, cross platform, C++". But, let's give you the benefit of the doubt and say that you've already go some mechanism for emulating a Goroutine (which by the way allows one to "mutiplex independently executing functions onto a set of threads"). I think _just_ the thread safe code that would implement all the necessary locks and barriers for a _single_ platform would probably be more than 100 lines, and would not be portable (ie, it would be pthreads, or win32 specific).
I am open to being wrong about that, but I really do believe that you haven't spent much time investigating Go, and are therefore spreading FUD. For example your assertion that "in Go, a List class would have to use void* types, throwing type safety out of the window" is just plain wrong.
I should also point out that I am in no way a Google Go fanboy. I see it as a pseudo-interesting low-ish level language that I haven't quite been able to envision the proper use for yet. I don't really buy Google's claim that it's a system level language (I can't see myself wanting to write an OS or device driver in it). To me it seems more like a great way to rapidly build efficient client / server type applications.
After all, manual memory management means code needs to be run every time the last reference to a chunk of allocated memory is lost.
And manual resource-other-than-memory management means code needs to be run every time the last reference to a resource other than memory is lost. C++'s RAII idiom and Boost smart pointers excel at this, as do both the context manager and the reference counting in Python.
And indeed, some studies have found automatic memory management to actually outperform manual memory management.
Do you mean "outperform" in latency, or just throughput? Anything interactive needs a latency guarantee so that the user doesn't spend several seconds at a time staring at a frozen application stuck in its garbage collector.
Watch C#, it'll be adding some more multithreaded things in the 4.0 release
If you can make the code 1% more readable (pick your measure) at the cost of making it take twice as long to write, is that worth it?
If you can make the code 1% less readable and simultaneously make it twice as fast to write, is that worth it?
Agreed.
Now flip those numbers around. If you can make your code twice as readable (and maintainable) with 1% extra effort, is it not worth it? What if python's len() was ln() insread? As it it, the first few times I wanted to get the length of a list in python, I tried length(). The language sometimes uses full length English words and sometimes not. Compare "str"with "unicode".
Yah but mono ain't C# at the end of the day is it.
It will always be that bastard language child that sorta looks like it's dad. Sometimes it wants to do it's own thing and express it's own individuality sometimes it wants to be just like dad. In the end it's not dad.
And cool apps just don't cut it at the Enterprise level. For id skimming iPhone apps sure but not big boy stuff.
And really do we want to have a copy of something that is associated with the most hacked OS on the planet? No! I want something in my data center that is fast cheap to build and requires little attention. Windoz anything requires 24/7 hotline loven. I really don't want something that quacks like a duck walks like a duck but it's a turkey.
Hell I'll take perl, ruby, python and php before a C# or it's bastard children.
But that's just my opinion. :)
Android, Google's OS for small/mobile devices (eg. netbooks and mobile "phones"), runs a virtual machine called "Dalvik". Android is programmed in Java source code, which is compiled into bytecode that is not Java, but specific to Dalvik. Dalvik is not a stack architecture like most virtual (and real) CPUs, but is instead a register architecture, which is more parallel.
I'm surprised that Google is releasing a whole new language that is not targeting Dalvik with generated bytecode. Especially since Go is designed for parallelism. And also since they've got Rob Pike, who helped invent Unix and its programming environment (C) that go hand in hand. Pike also devised the Limbo language, which is a bytecode generator.
Go really seems like a half measure. I wonder why they bothered.
--
make install -not war
I'd write Con and then press ctrl+space for autocomplete :-)
Surely the compressed version would be ConnMgr? I know people say to remove the vowels, but that's not the actual rule!
There are some nice things. How often have you written:
if (v instanceof FooLongNameAnnoyingToTypeInnitFoooooo) { ...}
FooLongNameAnnoyingToTypeInnitFoooooo fv = (FooLongNameAnnoyingToTypeInnitFoooooo) v;
Go has:
fv, ok = v.(FooLongNameAnnoyingToTypeInnitFoooooo)
if ok {...}
But that ok thing is probably because the language doesn't have exceptions. The slices should take care of AOOBEs though.
Heres a novel idea. Use a language as a tool, and use the right tool for the job.
Then platform makers should stop building around single languages when the language isn't the perfect tool for every application. For example, programs for "feature phones" must be written in Java (or a language trivially decompilable to Java), programs for Xbox 360's XNA must be written in C# (or a language trivially decompilable to C#), and programs for iPhone must be written in Objective-C.
... the low-level, external syscall package, which provides a primitive interface to the underlying operating system's calls.
Finally, some sanity in language design. syscall will no doubt be used only occasionally, but it's there if you need it and you know what you're doing.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Back in the day, C++ was pretty much C code written with some nicer syntax features. the lack of a string class really doesn't make much of a muchness.
Hell, even today, C++ is (well, should, you know some people overengineer C++ code so every little thing is a multiply-inherited object) pretty much C code packaged up with a nicer syntax. And some STL and Boost thrown in to make some things simpler.
C# - suffers the same memory issues as Java. Practically *is* Java really.
So Go.. add a common library of useful stuff and it could be a killer language, especially if Google drops their Java-based language they hacked up for Android and starts to use it for everything. Lets hope it doesn't become just another entry in the '99 bottles of beer' list. They're going to have to rename it though ;)
The syntax is nothing special. Let's see if it delivers anything compelling in practice.
Are you talking about C or C++? Those are the two languages Windows mostly consist of...
You don't know what you don't know.
Bad example. "len" was chosen to stop people typing "lenght", not to be shorter.
entropy happens
Could they have chosen a worse name? I mean seriously, Go? That'll be easy to find on a search engine. Well I guess it's Google so they can special-case the word, but still.
If my enemy's enemy is my friend, what happens if my enemy is his own worst enemy?
Innovation? What's that?
Haskell? Never heard of it.
Python? No, we can't just make an existing language faster.
C? Yes we love the horribly crappy syntax of C, and will clone it.
Yay! Yet another pointless reason for yet another pointless language.
Sorry, but Haskell completely and utterly spoiled me for all other programming languages... :)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
I'm curious as to why they went with gcc instead of LLVM for one of their first backends. It's pretty obvious there is a slow move to LLVM for everything. It's a lot easier to work with than gcc (ie. better design. The BSD's and such are already moving to LLVM/clang and such, it's only a matter of time before everyone else does.
I may as well take the opportunity to mention a FOSS programming language I have been working on that is designed to enable the merging of the speed of C++ with the flexibility of a scripting language. It is a scripting language designed for embedding in your C++ application, and it makes it trivial to your C++ classes/objects/functions to the scripting language. It's called ChaiScript, we've been working on it for about 6 months now and have made several releases.
ChaiScript works with your existing C++ code and doesn't require you to rewrite your application, like moving to a whole other language would.
I Do C++
Two "Go"s considered harmful.
first they made the Go language ... .... Go Ogle!
then they sat watching it's beauty for days.(100, 100 or so...)
then they just could not control their love for it so they formed a company called
history.stack.pop(); :-D
Not sure what compiler you are using - I make it 2940 bytes when compiling C after doing a "gcc helloworld.c" and "strip a.out".
If I use "gcc -static hi.c", then it's up with the go version at about 500kB.
Hmm. Must remember to get a life.
Plan 9,
6g,
Rob,
go0gle,
is it only me or does someone else also think these guys use keyboards with numeric pads?
I nearly injured myself with my tea because of your comment. Thank you.
Ever heard of std::string and all the rest of the very well designed standard library? In fact I would risk to say, one of C++ greatest assets was the vision and cleverness of stepanov when we created the concepts that later became the standard library.
Now how many languages have a standard implementation of the swap mechanic? Like std::swap? Something even more basic on conceptual level?
According to the official site, "Go has ... garbage collection". Is it mandatory? Or can its usage be avoided? One of the issues I have with GC is the wider footprint (and subsequent swapping activity) it imposes. There are situations where I want to avoid GC, but want something more than Plain Old C.
now we need to go OSS in diesel cars
So the statement was nearly accurate. ;-)
Ken Thompson, who invented Unix, creates an experimental new language with Rob Pike et. al. and Slashdotters try to overdo each other in pissing all over it.
Nice.
Tell you what kids, try learning something for a change. And show some respect.
god n. : the Supreme Being, indistinguishable from a good random number generator.
Not only that - the most obvious name for actual java scripting technology was taken.
Can't you use it to script java applets? Kind of like a bridge between the applet and the webpage containing it. I've always thought that might be one of the reasons Sun allowed Netscape to rename LiveScript to JavaScript.
Well, there's always FORTRAN... it does have very good multithreading/concurrency support, and is definitely fast.
Oh, wait, you want string manipulation?
I program in Brainfuck, you insensitive clod, Google!
My biggest rant about most of these new languages: garbage collection is useless! I still have to write destructors that clean up all the pointers to an object, and all garbage collection does is force me to call the destructor as a function, rather than a more clear 'delete' statement. Worse, it takes away my most powerful speed optimization tool: careful memory layout for best cache hit rates. I can write simple graph traversal code that is 10X faster in carefully designed C/C++ than in any garbage collected language for large graphs.
If you're writing code that needs to know about low-level details of your hardware, you need to use a low-level language. I wouldn't be surprised if you could eke out another factor of two by spending some quality time with a logic analyzer and assembly code.
When it comes time to make your code run as fast as possible in parallel across many cores, though, it gets harder to optimize without introducing bugs -- especially when, instead of a few hundred lines of carefully crafted graph-traversal logic, you're trying to maintain and extend a few hundred thousand lines of "everything else".
It sounds like you've found a niche where your understanding of your problem, your compiler, and your architecture lets you win significant performance gains. That's great, but that niche is getting squeezed from both the bottom (as compilers, optimizers, and architectures get more sophisticated) and the top (as problems and applications get larger and more complex). For everything that doesn't fit into the niche, automation -- including highly-optimized and reliable garbage collection -- is far from useless.
I'm guessing the exception handling in python is more expensive than finding the length of your ArrayList-like object and responding accordingly.
In Python, exceptions are cheap enough that programmers find it easier to ask forgiveness than permission in many cases. Even iterators end by throwing Python's equivalent of a j.u.NoSuchElementException within next() instead of returning False on some sort of hasNext(). Besides, exceptions reduce time of check to time of use to zero, unlike branching based on length and finding that another thread holding a reference to the same list has removed elements from the list behind your back.
Guido? How do you feel about this?
C++ come on it didn't even have a string class
Um, no string class in C++?
std::string?
#include ?
No?
Good point, but they're actually two separate animals. The ability to script applets came after the fact, and it's really an additional library, not the language itself.
-t.
Not too long ago, we had a consultant from Sun write a PHP website for us, and he called all his Javascript "Java". The rest of his code lived up to similar standards of quality and technical erudition.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
Considering you write it once and read it many, you have to multiply your (less than generous or realistic) 1% improvement in readability by how many times it is read.
And practically speaking, come on, how fucking long does it really take you to physically write code anyway? Typing code in is the LEAST time consuming part of programming. Even a 25% increase in time spent typing amounts to a very small increase over time versus what is lost by people trying to follow compressed and abbreviated code.
Simply put, sacrificing readability because you are lazy is just lame.
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
>Now, we have Go. Is it a massive improvement over C and Java, thus justifying spending milions of dollars to train programmers? Only the future will tell.
There is also Digital Mars D which is designed to fill the gap between C++ and Java. And there is also C#. I don't think the purpose of Go is to be something like that, it looks more like a scripting language with static typing.
Here's a simple one. How about the ABA problem with a concurrent linked list. GC takes care of it.
Mamma Mia! This scenario, that's me down to the last detail... My project, my love, my life, my obsession, whatever you'd call it.... The solution I came up with wasn't elegant at all, it went on and on and on... So long... Time is money, as they say, and this work was money, money, money, slipping through my fingers. And when I thought I had it going the right way... Bang! a boomerang, it came back and hit me in the face (figuratively speaking, of course...) When my co-worker Fernando reviewed my code I felt like I was under attack, my own personal Waterloo. I was really starting to feel that one of us was going to have to leave my office, and it sure wasn't me... But he suggested what you suggested - a fresh approach using GC... Just like that it was as good as new. GC really is the name of the game when it comes to the ABA problem in a concurrent scenario... I could have spent all our last summer at the company trying to make my non-GC approach work, knowing me. Knowing you, you probably would have gone straight to the GC approach in the first place and got it working just as well in a week. :)
When all is said and done I think that GC has a lot to offer. I still think explicit resource management has its place, but people ignore the merits of GC because they're head-over-heels for the traditional approach, or because they believe GC is inherently more cost than it's worth... I have a dream that someday the programming industry will move as a whole beyond that mindset...
Bow-ties are cool.
If you can make the code 1% more readable (pick your measure) at the cost of making it take twice as long to write, is that worth it?
If you can make the code 1% less readable and simultaneously make it twice as fast to write, is that worth it?
What about increases in coding time that result in decreases in debugging/support time? Comments and readable functions may take longer to write, but can offer benefits in the long run.
Google, an enclave of some of the best and brightest in software engineering, and this is what they come up with?
I have been getting paid to program computers for close to 40 years now, and during that time the BIG changes in programming have been losing Hollerith cards and editing that could edit any character in a file without re-opening the file. (TECO {*shudder*}) or throwing away the card!
Pretty sad huh?
The languages have all remained forks of Algol. This is the best we can do? Arguing about white space and libraries and late binding vs early binding, etc. Programs that are written in flat ASCII files, it all makes me sick.
The computing power has gone through the roof with CPUs and GPUs that rival supercomputers and we are still using makefiles; static analyzers and debuggers. And arguing about the color of the font, or spacing used.
Next time you think you are cutting edge, just realize that you are using tools that where designed 50 years ago, with almost no change!
And when we designed those tools, they where so they could run on those old pathetic machines that consisted of rooms of equipment with cooling towers (the first computer I used had 48K of core memory, and export was controlled by the DOD), they where not designed to be human friendly.
The programming paradigm should consists of the programmer expressing the unambiguous goals of the program, and setting a list of requirements, such as target CPUs, inputs and outputs, etc. and then the program is created to satisfy those programmer stats.
Even better have the intended hardware target described in another unambiguous "language" that is passed into this "compile" as well, that way the tool knows if there even is cache available.
I don't care how many cycles it takes to achieve those goals at "compile time", we have volatile and non-volatile memory that is measured in gigabytes, not k. With CPUs of amazing throughput. I want the tools to figure out if this fetch is from L1 or L2 cache, not me!
And if my programming requirements stated that speed was important, then restructure the design of the program to use L1. This will take at most seconds on a computer not days of my life. I don't even want to know what it did to achieve my requirements, unless I specifically go looking for those answers. It is just that simple.
Will we ever get away from these barbaric hardware defined and confined programming tools?
Yes. And additionally, strings are the most common type of object used as a hash table key. Mutable keys can lead to nasty bugs.
Are you adequate?
and he's an incredible dick.
My favorite crappy name has always been the Javascript/DOM function XMLHttpRequest.
A single function name that:
1) Is inaccurate (it doesn't give a crap whether XML/JSON/plain text is received)
2) Doesn't follow camel-case pattern (as is the convention with DOM functions)
3) Writes two acronyms with different cases "XML" vs. "Http"-- both are acronyms, why the different case?
The only slight excuse you can give it is that it was mostly invented to serve as an internal tool for Outlook OWA and IE, and somehow got "into the wild," but that's still not much of an excuse.
Comment of the year
``The same was said for Java. It was sold as the ultimate final language built on 50 years of accumulated knowledge of language design and computer architecture.''
Seriously? If there is anything Java and the culture around it have done wrong, it is _not_ learning from what came before it.
Please correct me if I got my facts wrong.
The second version of this language will be considered harmful.
GOTO mod +5 Funny
I mostly agree with you. I have in fact found a niche that is getting squeezed, but not as fast as it should be. These techniques are simple to automate compared to the optimizations that are already done, but for some reason, innovation in runtime efficiency seems to have evaporated in the last 10 years or so. It's probably because everyone sees the niche getting squeezed and moves on to some other problem.
A native Java compiler should be able to analyze my loops, and break up objects into well chosen chunks, and allocate those chunks together in memory. This alone would make it instantly the fastest computer language in the world for memory intensive applications.
I think language developers are also missing out on innovations that could greatly reduce bugs while simplifying coding. Garbage collection is good for what I call "value" objects like strings, and matrices. However, for normal objects representing things you'd typically see in a relational database, like "employee", you still have to write a destructor manually. The destructor will remove the employee from it's department and any other relationships with other objects before deleting it. GC doesn't help me at all in managing simple databases with objects like employees. If I forget to clean up a relationship, with GC I get a memory leak, while in C++ I get a dangling pointer. I wouldn't say one is better than the other.
Instead, the compiler should generate the destructor automatically for me, by analyzing the relationships and through some user declarations. This capability already exists in relational databases. Unlike GC, compiler-generated destructors save the coder time and nearly eliminates very painful memory leaks/dangling pointers.
I'm not just hypothesizing. DataDraw writes 100% of all my destructors when I'm programming in C. My little company has so few memory leaks and dangling pointers most programmers don't even know how to run valgrind. Mostly we use it to measure cache statistics.
Celebrate failure, and then learn from it - Nolan Bushnell
When you realize that people who do not speak English as a first language find your abbreviations completely unreadable, they become a lot less attractive.
Pretty good point, actually. Like the examples.
I guarantee you some enterprising squatter has already gone out and registered the .com and .org for every alternate name mentioned in that thread too.
Forbidden
Your client does not have permission to get URL / from this server. (Client IP address: ***.***.***.***)
You are accessing this page from a forbidden country.
Persian Project Management Software as a Service
There's a petition now to change the name to "Issue 9": http://www.petitiononline.com/gglgoi9/petition.html
Just nitpicking here, but how often do you explicitly declare or catch an ArrayIndexOutOfBoundException? It is, by definition, a RuntimeException, and only occurred when something *really bad* happened, e.g. indexing into an array using an invalid index. When it does occur, whatever that thread is doing should pretty much be thrown out, bug report filed, and programmers put back to work figuring out what really happened.
Just because a method declares that it might throw a particular exception doesn't mean you have to catch (or declare) exactly that. For example, there is nothing wrong with saying that your method throws an IOException when its dependencies throw a MalformedURLException. As the individual lines of code aggregate and become blocks and bigger blocks, the exception signature should become more generic.
A high-level block of code that deals with high-level IO should throw only IOExceptions. It might have to catch some other exceptions and convert it into IOExceptions, but the calling code doesn't have to know all that. All it need to know is that something went wrong, with the detailed information on the stack trace. Just enough to log the error, clean up the mess, and terminate.
The release of a new programming language and another opportunity squandered to ditch semicolon statement terminators forever.
!Go! (since it's not Go!)
Goobar
Goooooooooooooo
6o
G0
Has anyone implemented Go in Go yet?
According to Wikipedia's edit history, the "Go programming language" page on Wikipedia was only created yesterday. Therefore it might've been hard to find this guy's language.
"I find that if you shorten long words arbitrarily, it actually increases the writing time"
I think the real problem is that the naming of variables and functions and what have you should already be in a list with functional autocomplete already that gives common variable and other names and bind them unique ID's, so that you can use the same name more then once with a different ID.
I think the whole programming nomenaculture needs serious updating
If your database doesn't do that stuff for you already, maybe you should look into one that supports triggers or foreign key constraints.
Do you even lift?
These aren't the 'roids you're looking for.
In terms of speed, they report compiling 120,000 lines under 10 seconds for Go on a laptop. On the Mono project they report compiling 18,000 lines of C# per second on a t40 Thinkpad. So Google's Go compiler written in C/C++ is slower than the Mono C# compiler written in managed code? Impressive.
I just used tcc to compile itself in *100 milliseconds*, some 100X faster than the Go advertisement. Does Go actually do 100X more work than a C compiler? Doutbful. It may be 100X faster than the insanity that has become gcc compiling itself, but it actually sounds pretty slow for what it does.
Doubtful?
I feel fantastic, and I'm still alive.
I was wondering if any programming language has done something like this:
class A { // specify B's type // specify legal values for B // specify that B can be read and written from outside the class // specify default value, used on initialization
property B {
type integer;
constraint B > 0;
constraint B 100;
public read, write;
default 1;
}
}
Would seem to reduce the amount of boilerplate code you would have to write in terms of getter/setter functions, and make everything clearer. You could just say A.B = 5 or C = A.B without having to call A.setB(5) A.getB(). Object initialization would also be much more clear, you would simply create the object and set any values you want.
I will probably mature around the time Goooooo comes out
... that's what she said.
I'm done with any language that requires that one file references another by a *path*. So when I have to do something low level enough for C, I'll probably stick with that, since at least my editors can deal with that shit for me.
Actually, JavaScript was there first. It shipped with Netscape 2.0 beta in December 1995. Sun claims that Java was released in 1995, but in fact it wasn't available until January 1996.
I do that. It's really not that big of a deal; sometimes I'm not even consciously aware that I've switched layouts. For awhile I had trouble with letters like "y" that you type with the same motion but the opposite hand.
My in-memory data-base built in C using DataDraw does this already. The speed rocks. Before writing the first version of DataDraw back in 1991, I read about relation databases, and was somewhat inspired. Why we have these innovations in databases, but not computer languages, I can't guess.
Celebrate failure, and then learn from it - Nolan Bushnell
And for those of us who were writing C++ code before there was an ANSI (let alone ISO) standard, how would this not be a legitimate criticism? I started writing C++ before templates were a standard part of most C++ implementations, and many C++ compilers I used were glorified ports of the AT&T cfront C++-to-C compiler.
That there were no decent standard libraries before circa 1995 is bad enough. Even well after that time, there were still C++ environments I had to write code in which still didn't support templates, or didn't have a decent string class, or were missing the many useful things in STL. I distinctly remember contacting an old professor of mine at RPI to get a working STL I could use for a project at American Express, and this was circa 1996, maybe 1997. I also remember trying to port a Windows application for IGC -- it apparently built fine on Solaris using Mainsoft's MainWin porting libraries, but the HP-UX compiler was a whole other kettle of fish that required the programmer to supply separate files to give it hints on how to instantiate templates.
Even when strings were widely available in all major C++ implementations, a lot of old hat C++ programmers were writing their own implementations or using some third party string implementation instead of using the standard. I suppose some of that is programmer inertia, and some of that is lack of trust in the "official" implementation. I think the lesson here is, "Never ship a new programming language without all the basic data types and collections taken care of."
I think a lot of the rest of what the GP has to say is bunk or suspect, but you can't just dismiss the bad experiences that a lot of developers had with C++. Many of us were forced to use it long before it was fully baked and ready. So yes, it's entirely fair to criticize a programming language if it's in wide use before a standard is finalized.
Shouldn't that be G,ooo,ooo? Or perhaps the first "o" for the zeroth release, so the upcoming first release will be Gone? :)
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
Note the use of the past tense. Didn't. As in, C++ didn't have a string class, but now it does.
It may surprise you to learn that people were programming profitably in C++ long before there was an ANSI or ISO standard, and in those days using a C++ compiler was a crapshoot as to which features you might get.
The ISO may only have defined a C++ standard in 1998, but there were many users a decade earlier. The first C++ compiler I used was cfront, and it compiled C++ to C. I found it more of an improvement over C than I find the current C++ compilers. (Due to work considerations I spent a decade with MSAccess & it's version of VisualBasic...which wasn't even standard MSVisualBasic. Yuck!!!) When I came back to C it was via Ruby & Python. C++ was virtually unintelligible. (Not really, but I *REALLY* despise templates! Give me Ada generics any time as an alternative. If Ada had decent string handling, I'd never have looked at C again.)
To me Google go looks like an interesting language. I'm not clear how one should convert uint64's into a ubyte[], but outside of that I think I'm sold...at least enough to give it a test. It's lacking in libraries at the moment, but if it becomes at all popular that should diminish quickly.
FWIW, I've currently been using D as the best language for performance, etc., but D doesn't handle multiple-processors gracefully. They've got a library, and they're planning to improve it, but it's an "add-on", not a built-in. To me this is an important feature, and I don't currently know any language that handles it well. (Yeah, I've looked at Erlang. I've also timed simple programs. I think I'd do better with Python. In Erlang if you can directly apply the language built-ins, you get good performance. Otherwise not. And the built-in database doesn't appear to do what I want. And other parts of the program chain were just too slow.)
Of course, this is all based on their assertion that Google go really *IS* in the same speed ball-park as C. D is, so it's not impossible. But many languages that make that claim aren't. (I guess it depends on what you're doing.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Verbosity of syntax doesn't help with readability, it works against it.
You can't read what's not on your screen.
"It is better to die on one's feet than to live on one's knees." - Albert Camus
The approach is not to remove all vowels, but to come up with a short name that has very low chances of being confused as something else. using your approach "format" would be frmt; but fmt has been in use for long time and people automatically associate that permutation to the word format. ConnectionManager would be ConnMgr or CtnMgr, I think.
Simple solution: Google should rename theirs to 'Goo'...
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Actually, you're quite wrong. Go is *specifically* designed to act as a new systems-level programming language akin to C++ or D. Of course, it inherits a number of features from various high-level languages (not the least of which is an integrated GC), but in the end, it's meant to be used as a replacement for C/C++/Objective-C/D, rather than, say, Python or Perl.
Yah but mono ain't C# at the end of the day is it.
Huh? Mono's implementation of C# will always be C#, as the language spec is open and standardized.
It will always be that bastard language child that sorta looks like it's dad.
I can only assume you're talking about the class library, here. Of course, C# and it's stack is no different than C + POSIX, here. The basic libraries and functionality are, again, standardized, and Mono implements those. In addition, it provides a stack of APIs to integrate with various OSS technologies (Gtk, Gnome, various databases, etc).
'course, I'm not sure what your point is. Mono implements the standard, just like gcc and glibc implement a standard. Mono then adds a bunch of it's own stuff. I don't see a problem here.
And really do we want to have a copy of something that is associated with the most hacked OS on the planet? No!
Uhh... why? Frankly, you sound like an idiot, here. C# and the related APIs are a decent piece of technology. Ignoring it because it was produced by the same company that produced Windows is completely idiotic.
But that's just my opinion. :)
Clearly an ignorant, uneducated one. But, this is Slashdot... I expect little else.
Unfortunately they blew the System call interface on Mac OS X.
Mac OS X defines the system call API as the top of Libc, not the bottom at the user/kernel boundary.
You can see this in their implementation of the "kill" and the "posix_spawn" system calls, but there are tons of others:
SYS_KILL = 37; // { int kill(int pid, int signum, int posix); }
SYS_POSIX_SPAWN = 244; // { int posix_spawn(pid_t *pid, const char *path, const struct _posix_spawn_args_desc *adesc, char **argv, char **envp); }
Most of the places they say "NO_SYSCALL_STUB" are actually decorated version of system calls for binary backward compatibility. If they ever include Framework support for certain existing frameworks, they are going to find that their use of 32 bit libraries may result in unexpected-by-the-framework cancellation points that need to not be there.
The kill system call changed from older versions of the OS to ensure POSIX compliance for one compilation environment, and historical behaviour; in fact, for the 32 bit version of libc, there are 189 decorated symbols for doing everything from translating error codes to getting variant behaviour to enforcing POSIX semantics in user space in libSystem itself, and there are 74 variants for cancellation points in both 32 and 64 bits.
Changing the contract between libSystem and the kernel under the covers to fix bugs happens often. The posix_spawn() system call is a good example of that. Apple has extended spawn several times by modifying the _posix_spawn_args_desc. The code itself uses accessors and mutators on an allocate descriptor. It can change (and does) size when new extensions are added.
Basically by providing their own direct system call interface, they've guaranteed that they will constantly be chasing a moving target, and they've lost a lot of the default POSIX semantics that are implemented at the libSystem level. For kill and similar calls, they've lost the go code portability between OSs by doing this.
Finally, they need a type mechanism so that the unsupported interfaces can be conditionalized based on the UNIX standard permitting non-implementation of certain interfaces; otherwise they will run into things like unnamed semaphores which will throw a SIGSYS, which will abort their programs.
-- Terry
If this language becomes as popular as Perl, then 120,000 lines will soon become 1,200,000 lines. That is exactly what happened to the Perl interpreter and compiler.
I doubt it. The Perl-community is enamored with features and bloat. The people behind Go are hostile to it.
And, as I recall, never in their history were Perl or Java quick to compile.
Also, just like Java, the new Go language (due to the immense respect for Google's scientific prowess) will likely receive accolades
Who cares? The world is full of idiots. Hey, you just made an idiotic argument yourself, to paraphrase "Because Java is bad and Java received accolades, Go will be bad if it receives accolades too."
It seems like a variant of aleph, a Plan 9 language.
It's not bad, and I think it's a worthy replacement for C.
They really need to work on their installs. Having different compiler names for different target platforms is silly. And having a build process that requires the user to set environment variables is equally silly.
Where C++ provides classes, subclasses and templates, Go provides interfaces. A Go interface is similar to a C++ pure abstract class: a class with no data members, with methods which are all pure virtual. However, in Go, any type which provides the methods named in the interface may be treated as an implementation of the interface. No explicitly declared inheritance is required. The implementation of the interface is entirely separate from the interface itself
Now, this is awesome.
They say that Go was designed to give them a better language for writing server code than the C++ they're using. I think it makes a lot of sense in that context. They don't need to use Go in every project to be a worthwhile effort.
I'm going to elaborate on the Maybe type idea because I think it is important. In Haskell, there's no distinction between a value and a pointer to a value, and these things can't be Null. In C, one often wants to represent, say, an optional value. A pointer can be used for this: it is either assigned a value, or it is NULL. In Haskell, we do the same thing with a Maybe type. Maybe is a container that can either have the value "Nothing", which means it's empty, or "Just a" where "a" is the value you stored.
The important thing about Maybe types is that they let you make a distinction between things that can be empty and things that can't. In C, any pointer can be NULL, so we can't tell from the type signature of a function if it's okay to pass in a NULL value or not. And indeed, a large proportion of all C runtime errors is the dreaded NULL pointer exception.
What I am suggesting, is that Go should have a notion of a pointer that can only point to a valid object, and a pointer that can be set to NULL. They type system should distinguish between these two cases, and the compiler should fail if the user tries to mix the two. NULLable pointers should only be used when absolutely necessary.
From what I've read so far, I have no idea if Go allows standard pointers to be NULL.
Two "Go"s considered harmful.
Thank you, sir.
Java + C + Ada + Erlang = Go lol
How can you speak highly of C and then write off C++ because it has no inherent string type? In C your only option is char arrays or rolling your own string concept. C++ has those options as well as a very nice string class included in the standard library.
0% of 1 user recommends this project
Just be happy it's not battletoads
This Comment deserves to be a Slashot Headline!
I don't speak English as a first language. I find fmt, ConnMgr, recv, sys, btn, etc. to be perfectly readable abbreviations.
Is it a surprise to you that the Danish branches of $SOFTWARE_COMPANY (at which I've worked) requires its employees to be good (or at least decent enough) at English?
Granted, I picked arbitrary figures to argue a point.
Also, I disagree: it's not written once. It's written once, then rewritten several times, in a sequence of small patches.
And I think there's value to be had if you can type less: while typing, you can't really think that well about what you're going to write next (at least not as well as if you weren't typing).
I think in some (some!) cases my position is very defensible: does "len" really take longer to read and understand, compared to "length"? My experience is that it's the same, so why not save the typing time?
That being said, I think you are right in some cases. I don't advocate brevity at all costs. I advocate brevity in the cases where they're a net win.
Then, "in which cases is it a win?" is an empirical question that I don't know the answer to.
C++ come on it didn't even have a string class. Thus pointer math hell.
#include <string>
int main() {
std::string s = "What am I, chopped liver?";
cout << s;
return 0;
}
there is no god but truth, and reality is its prophet
Optimizing frequently used internal functions is a different thing than optimizing every variable name.
Nerd rage is the funniest rage.
Languages that are supposedly fun and easy to use are a dime a dozen, and yet another like this "Go" is the last thing anyone needs. C++, Java, Python. Ruby, Perl, and now "Go" all are basically the same with different syntax and type checking features. Go won't solve their underlying problems. That is why we have Ocaml and Haskell. I really can't understand why anyone even bothers with imperative languages anymore. Aggressive type checking and the everything-is-a-function paradigm is the only way to go.
This just leaves me wondering: why do we need yet another programming language that looks sort of like C? Ugh. We have a glut of different languages somewhat similar.
8 gig for a Java app? WTF are you doing - adding the whole app to session variables or something?
We deploy a large Java app which runs nicely under 512 on 2 gig web servers. Maybe it's time for you to go back to the books.
What's Google implying? That I Go ogle people?
I am not devoid of humor.
But isn't PHP & Python web centric?
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
I think http://golang.org/doc/go_for_cpp_programmers.html#Slices are picked from http://xmlrpc-c.sourceforge.net/
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
XCreatePixmapFromBitmapData