Slashdot

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 compilers support two operating systems (Linux, Mac OS X) and three instruction sets.

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.

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 [microsoft.com] 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.

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.

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.

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

Array slices and mapping types have been around for decades. Not even Perl was the first to provide tham, et alone Python.

From Golanf.org [golang.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.

Go seems to suffer from the problem of not being done. Case in point: exceptions.

Google's C++ style guide [googlecode.com] 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.

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.