Project's main page

From what I understand they are trying to combine the speed of development of a dynamic language with the performance and security of a compiled language.

So... I wonder how long before Allegro gets ported to Go?

Go is not a dynamic language. It is a statically and strongly typed language. The dynamic part is explicitly programmed by the programmer by using interface casts like in Java.

Personally, I don't understand what's the fuss.

Slashdot says "Parallelism is emphasized in Go's design. The language introduces the concept of 'goroutines' which are executed concurrently", but if you look at the documentation, goroutines are nothing more than threads and channels are nothing more than synchronized data queues...big deal. I can do a synchronized queue in C++ with very little effort. Example:

The interface decoupling from the class is a nice feature, but I can do with with C++ as well, with very little coding, using duck typing. For example:

What else is there? nothing much, really.

Go does not have templates, so writing any compile-time safe reusable code that has minimal performance is not possible.

I didn't say they were actually making a dynamic language ... but rather a language that feels like one.

I still think it will be interesting to see how much momentum this gains...

Go looks like a crippled version of D with bizarre syntax. In fact, it looks like D from like 5 years ago (D started out with no templates too) with bizarre syntax.

It sounds interesting to me. I'd like to see it take off. Hopefully the language improves and the toolchain stabilizes. I'm anxious to try it, but don't have access to a Linux system right now^[1]...

** EDIT

I've already got two problems with the language. Number one, it's using packages, instead of namespaces. I find namespaces, as implemented in C# (and I guess .NET) work a lot better than packages.

namespace identifier
{
    // code.

    namespace identifier
    {
        // code.
    }

    // code.
}

The structuring is obvious in the code. It's hierarchical. Also, the package declaration should have to end in a semi-colon (;).

** EDIT **

Now that I've seen the first two example programs in the tutorial, I don't really care for the syntax of the language. It seems too disorganized and loose. Semi-colons are optional, variable types are declared after the name, etc. Not my dream language. I might use it if it becomes stable enough, but I don't see it becoming my favorite language.

Parentheses around if statements are optional, but curly brackets for the block are required. Personally, I've never had grief with the parentheses, but being forced to use curly brackets bloats the code.

Based on that, I am going to assume the designer is making another Java-like language. By that I mean a language which arbitrarily restricts the code for "best practices". We are supposed to be giving more control to programmers, not less. Java was a step backwards from C++ in my mind, even with all of its modern features. Think of those cars that steer themselves during an accident. Imagine if they didn't have the override feature. Do you really want to trust your life to a computer? In this case, I'm fine with trusting the compiler for most things, but I want an override.

C# is much more the language I prefer. It has the feature describe in the OP; being dynamic yet compiled. It's loaded with features, a nice set of standard libraries, and best of all provides that all essential override in case of accident. It is a shame C# is VM based. It sure does run fast, and pretty much every Windows system has .NET on it by now (and Linux has Mono). Still, I consider that a major flaw.

At first, I was repulsed. But after taking another look at it, there are a lot of things that I like about it.

I like that channels are first-class citizens. I tried out Microsoft's Axum for that very reason.

I also like the dynamic feel. It seems like the dynamism you get from template metaprogramming in C++ but without the brittle megastructure required to get it going.

The thing I am most happy to see is that interfaces are looser than most static languages. Managing that boilerplate stuff has always seemed like a painful waste of time to me, and it's only useful as long as everything plays nice.

It's an interesting language, and definitely Google-esque. You can really see the influence of languages like Newsqueak, Java, and JavaScript.

The involvement of Rob Pike and Ken Thompson alone makes it worth a longer glance than most new languages. I only looked briefly yesterday, but it could be quite nice for a certain niche.

Actually, goroutines are green threads, so you can have a lot more of them before running out of memory, as compared to OS threads. Which is of course not new, but is a feature which works best when its natively supported by the compiler/runtime rather than hacked on. Further, programming languages are not about who came up with what feature first, but how the features combine (or not combine).

You should try Common Lisp. As I know, you can customize nearly everything to your needs. Or Assembler Maximum control.

But if it's best practise, why not use it? No one produces perfect code. Especially when the project is getting bigger. A good amount of rules helps.

Because:

Do you trust the car makers to have a perfect piloting system? Even if they did, why not have the override option?

I guess what it all comes down to is freedom; the freedom to choose my own best practices rather than follow blindly the ideas of another.

I totally agree, but the people writing the code should choose the rules, not some skanky compiler. I will reference C# again as a fair example. The compiler generally does not enforce best practices with errors. The C# language specification, however, comes with a list of best practices, including how to space code. Visual Studio will automatically do the specified code spacing, but I can override it any time I wish.

Perhaps it would be nice if compilers could be loaded with sets of custom rules, instead of having a fixed set.

The ada gnat compiler has such a tool.

It does impact performance, but there are HUGE advantages to such a model; to name a few:
- Proper reliable reflection
- Constructing classes, instances, etc. on-the-fly
- Access control that goes beyond what the OS has to offer
- Self-contained assemblies (just dump a DLL into your project, and the types it contains, including documentation, are available to the compiler and the IDE)

This is all fine and dandy if it's a solo project, or if you are the lead and the rest of your team follows your guidelines. In other situations however, I'm thankful for any sane rule that the language, the compiler, or the IDE, forces on me and my team.

Which is exactly why nobody uses it these days.

Seems like another waste of space Google project to me. Aren't there enough programming languages in the world at the minute that do the job well.

No.

No. (once more for added effect)

I watched the talk.. rather half of the talk. The big names got my interest since everyone including google is involved. Then the introduction really got my attention: a simple grammar, orthogonal features, systems level language with GC, etc. It really seems like simplicity at its best! .. And then I saw the code itself.

And??? The suspense is killing me!

No. I think it's time for the next big language beyond C and C++.
One that:
executes just as fast or very close to C++.
makes programming easier and safer than C++.
still lets you mess things up if you want to.
lets the programmer use the full power of multiple cores easily and safely.

Anything more?

Why all these things cannot be done in a native programming language, i.e. a programming language with a virtual machine? I think that they are entirely possible.

-Reflection is a matter of storing type information in the binary.
-Constructing instances on the fly is already a capability.
-Constructing classes on the fly can be done, if reflection exists.
-Access control is a matter of type system: if it's strong enough and it can not be circumvented, as in C++, then any type of access control can be offered.
-self-contained assemblies is a matter of what meta-information you put in a DLL. Right now, C++ dlls are dumb raw binary blobs with the only information being the entry point table.

Why do all things things need a VM? they don't.

NO!!!!! (more effect!)

One big disadvantage of decoupling interfaces and classes is the inability to send messages to self.

I didn't read the project page, so I'm just going to ask here. Is Go's standard library named Ogle?

I think Go! is better (because of the exclamation mark).

Apparently that's the proposed name of the debugger.

dynamic language would be sweet we could have a program program itself at run time.

this is posible now but not with out memory hacks.

and a module design where you have module prgraming module.

Why would Google name it "Go"? Sure, it's catchy and has a similarity to their name but I can't even search for the board game Go. C was bad enough. However, not nearly as many people just start using the letter C when talking but Go is everywhere. I'd prefer to search for something in another language rather than try to find it done in Go.

I agree, they could have named it "G" to stick with the tradition of single-character names (there's "D" obviously and there's "F", not sure if there's "E", but "G" would be the next one up).
Or Gortran.

It's Google. They can add support into their engine for searching for their programming language. C++ works and that's probably because of custom rules.

So, what other thing does the term "C++" refer to thats as popular as the language? I would really like to know, as I see no reason why custom rules are needed.

The '+' character is generally not something search engines support searching for. In fact, Google uses it to indicate that an exact match should be found for a word (i.e., +word). I seem to remember a time when searching for C++ didn't work well and you got millions of results with the letter C in them^[1]. Searching for the Go programming language will probably require the word programming in the criteria, but should otherwise match (especially if they build in custom support for it).

Well... everything aside, VM's are a way of the future because they will be the best performers. Pretty soon we'll have a mess heterogenous cores and systems and we will no longer be able to optimize binaries for a specific core configuration like we do now. Hell, they might even have different ISA's all together.

Wait.. is this sarcasm? I've never heard someone say they liked VMs for their performance...

I imagine they would get worse as the cores start to multiply.

edit
Does Go have a VM?

Given massively multi-core machines on every desk, the need for heterogeneous clusters would seem to decrease.

Go does not have a VM.

Well, consider that some of these cores in your desktop are for number crunching and others are for general processing. These number crunchers may or may not be on a GPU. Also, some cores will be optimized for power and others for performance. Point is, JIT'ing gives a lot of advantages. Apple is already leading the way and use something like this for its graphics routines and they are switching away from GCC to LLVM for a reason.

So, when does Allegro get a Go port/binding?

I'm happy to help out on one.

Doesn't this just make you want to invent a language called Stop?

I will do hello world on the weekend, and you can do the rest
http://code.google.com/p/go/source/browse/misc/cgo/gmp/gmp.go?r=release

Let me be the first to say: I don't care.

From what I've seen this language isn't going to do anything for me that any existing language doesn't do already. I can only imagine that in spite of any useful features they MIGHT have that they'll make some other part deficient that works perfectly fine in another language.

Or maybe I just hate how everyone is always so fanatic about the latest greatest language for what seems to me to always end up unjustified.

lol

That's only valid for situations where vector processing is required. Most algorithms cannot be parallelized, so the need for a VM is minimal, if non existent. Parallelization of vector data can already be achieved optimally by using CUDA or OpenCL or whatever language exists that is complementary to C for this purpose.

The real problem is dependency management. I'd rather have my application not have any external dependencies, i.e. be a single executable, rather than not being optimized 100% for the target platform. If operating systems come with VMs preloaded or manage automatically VMs, then I am ok with it. This happens as we speak with operating systems that run in a virtual environment; you may also consider x86 assembly as the bytecode for x86 code (since each CPU decodes x86 differently to its internal real assembly language).

If we come to a situation you describe, then operating systems will have a VM installed by default, so the problem of managing the VM dependencies will go away.

Another solution would be an automated dependency manager (that does not interact with the user i.e. it discovers new versions and dependencies automatically, and installs updates automatically).

And then, there are real time applications. No VM could possibly exist for them, because their execution times should be predictable.

Sounds good, I'll get an SVN set up.

There's a couple of hurdles right now. First, the C binding program doesn't understand opaque types, e.g. typedef struct ALLEGRO_BITMAP ALLEGRO_BITMAP;, which we use a lot of. There's a patch in the bug tracker (#126).

More importantly, Allegro uses thread-local storage heavily and Go may multiplex goroutines onto its thread pool as it likes. Allegro will be unusable until there is a way to pin goroutines to specific threads, or something like that.

Looks like some bastardized Java/C++/whatever-else hybrid.

Turns out we can pin goroutines to OS threads. Attached the start of a binding (place in go/misc/cgo). I probably won't work on it more but feel free to pick it up if you like.

Did you mean to attach it to your post? Cuz it definitely isn't in the A5 repo.

I just made a repo for this at http://svn.lessthanthree.vg/allegro_go. You have commit access, PMing you your pass.

Attached for real now.

Haven't looked too deeply into it, but it appears the goal is to make a language that is as comfortable for the programmer as C# or Java (or even more comfortable), while still being a fully compiled language suitable for writing system-level code.

Perhaps what needs to happen is language designers need to realize that languages are just languages and should be officially implemented in virtual machines and native compilers, so the user is free to use whatever is most appropriate. Maybe it'll take designing a language with abstraction from the implementation in mind. Maybe that's Go, but maybe not.

Virtual machines and native compilers are orthogonal to each other. You probably know that Java and .NET have JIT (just-in-time) compilation but that compilation could just as easily take place before the process is invoked.

Yeah, but it should only need to happen once. What's the point in going through the JIT process every time you run the program? If the program isn't changing then it should remain the same no matter how many times you JIT it so it might as well just stay compiled and just run natively.

.NET caches JIT'd binaries.

There'd still be overhead in checking and loading the cache. Unnecessary overhead. It's a nice distribution model for average users, assuming the JIT is optimized for the platform, but that's no reason not to support straight to native compilation from the beginning.

LLVM is more fun. It will actually re/further-optimize the program as it runs, every time it runs. So as you use it, llvm learns how a given program is used, and optimizes for its environment. Its rather quite genius. And it does it with plain C/C++ code. It could also do the same for higher level languages if they supported LLVM (when ever I get around to mine, it will almost certainly support LLVM).

Profiling doesn't come for free, though, and I don't think runtime optimisation is that useful for the majority of programs, which seem to be IO/user bound anyway.

Of course thats just one mode. LLVM also supports regular compile/run scenarios.

JIT compilers/VMs supporting compilation straight to binary sort of ruin the whole idea in the first place. Compiling to CIL or bytecode allows to you run it anywhere with one binary.

Mono, though, does support taking a CIL binary and compiling it to native code (AoTC compilation), though, as expected, the output is very platform specific.

Yes, but if I want the high-level abstraction of C# and .NET with the performance of C or C++, I can't get it because C# and Java are implemented through virtual machines. There's no need for it. If I know I'm only running the program on my machine there's no harm in compiling it right down to machine level. In fact, there's hopefully a performance gain.

What I'm saying is that languages themselves shouldn't be limited to one runtime methodology. All languages should be able to be interpreted, compiled down to byte-code and JIT compiled, or compiled straight to machine level. There's no reason they can't. Eventually, they're executing code on the CPU one way or another. The only question is, how many layers are between the program and the CPU and what's the most optimal solution for a particular use case?

Languages are just a way to communicate the instructions to the computer. The implementation determines how the computer interprets those instructions and there's no reason a language should only be used with one type of implementation.

What are you talking about? C# and Java are converted to native code eventually. A virtual machine is just a run-time. You normally use a run-time for C/C++, its called libc.

Anyway just look at the shootout numbers: http://shootout.alioth.debian.org/u64/summary.php

Java is only 14% slower than g++ which isn't a heckovalot. Java's performance has been increasing over the past 10 years due to better compiler technology. This has nothing to do with using a VM.

I don't understand what you are trying to say. Language implementors know this. It's just that some languages/features are easier to map to "native" code (itself a bit of a lie) than others.

You act as if it's an unnecessary abstraction of the CPU/runtime. Do you also statically link your stuff, to prevent the dynamic-linking taking up precious time?

Right now, you can take any .NET (or java program) and run it mostly anyplace, no matter what system libraries, processor, etc. If you start allowing the compiler to produce machine-code output, you break this process. You also then have to do something about .NET itself (or, at least I assume, Java's standard library), seeing as how .NET is compiled to CIL and not native code (as far as I know, anyway).

I could be wrong, but I think you're confusing ambiguous terminology. The C run-time is, AFAIK, just a regular library that contains the C language implementation. Contrarily, Java's VM is a program that itself processes the Java program (originally, interpreting the byte-code, though now probably JIT compiling it; which it would seem still involves interpretation). One way or another, turning byte-codes into machine instructions.

I'm not suggesting that it's some ground breaking idea. Google's Go seemed to be partially justified as a "dynamic"-like language that compiles down to native code, but they could have instead just developed a native compiler for Java or C# or Lua^[1] (albeit, a new language might well have been a simpler undertaking). The language itself can be thought of independently of implementations (though they usually aren't).

Dynamic linking is beneficial. It means I shouldn't have to rebuild my entire system when an integral library gets a minor update. The performance hit should be relatively minor (and more than likely, the virtual machines that .NET and Java run on probably have their own dynamic linking to do, so that's not exactly getting swapped out for something different).

My point is, there's no technical reason C# has to be compiled to CIL. It could be compiled straight to machine code (as could the .NET CIL it uses) if that was desirable. I'm not suggesting .NET starts building platform specifics into its builds. I'm just saying that on top of the CIL route, Microsoft could implement a compiler that goes straight to native code (for when that's desirable). Considering .NET is mostly Windows only (Mono being the only notable exception I'm aware of), the abstraction is almost questionable. It would make sense if the executables were actually normally used on other platforms, but that doesn't seem to be the case (though it is a worthwhile goal to work towards, Microsoft seems like the last organization that would want to)...

The java vm is two things: a virtual machine and an interpreter/JIT compiler. You could in theory compile all your code directly to machine code but you would still need the VM to run it because things like memory allocation are handled by the VM, much like how malloc is inside libc.

Whether or not there is a tool to compile java directly to native code, I don't know. But the source is open so you could write it yourself.

That's an implementation feature, not a language feature^[1]. The whole thing could be compiled directly to machine code, though it would probably be non-trivial to do (you'd need to generate appropriate memory allocation and management code). libc isn't a separate program like the Java VM is. It's part of your program when you link to it. The only reason it's separate is because there are advantages to dynamically linking.

You can compile Java to native code, with gcj. (and other compilers, I'm pretty sure)

Stackless Python outperforms Google's Go.

So do most other languages. Just as I said earlier, Go is like D from who knows how many years ago. And it doesn't matter that Go is in alpha state, so is D2. D2 is heck of a lot better now than Go is, imho. I for one, think that the interest in this language is 90% based on the fact that it is made by Google, for if it was anything else, people would be all over D/D2 preferentially over Go, as those 2 (especially D2) are far better than Go.

Well I don't really care where the language comes from.

If D2 had been presented with a tech talk video like Go was I'd have the same thoughts about it.

Google may be second only to Apple in the "we can release a box of poo and people will still ogle over it" department.

Do you have your period, Matt ? ;-)

What?

I agree with you, and as mentioned Java has a compiler that does so. The point I would make, and I think others are trying to make, is that it isn't necessary. A native binary would provide no significant speed improvement over a CIL binary. With .NET's cache, you don't even have the JIT overhead. You mentioned verification being a bottleneck, but that only requires a few, small comparison checks.

I can't speak for others, but I am interested in this because it covers language topics I am very interested in, namely channels and non-conventional type systems. However, I probably wouldn't have found out about it if it wasn't made by Google.

For sure. But programming languages "succeed" for mainly non-technical reasons.

Erlang-style concurrency primitives (and implementation!) in a lightweight, imperative language is interesting to me. I don't think D provides that.

The executables can run on 32 or 64-bit Windows, Windows CE/Windows Mobile (generally on ARM cpus), XBox 360 (through XNA, IIRC it's still x86, but the system libraries are likely different). I think Microsoft has done it well, and so has Mono for the most part. It's nice being able to run VS-produced binaries on Linux, and vice versa. Oh, and being able to target stuff at .NET CF for Windows Mobile, and being able to run that binary directly on Windows (assuming no WM specific libraries are used).

I am sure the posterity will appreciate us being blinded by marketing and then writing tons of software in a fundamentally flawed and inelegant language.

The niceness of writing the small percentage of the program that can be parallelized using 'goroutines' is outweighed by difficulty of writing the rest of it using the features (or lack thereof) that Go provides, in my opinion. While it is valid for one person in particular to strongly weigh the 'goroutines' feature such that any language with it will be considered better any other language without it, I question how valid this is for the programming community at large.

and Zune!

Witness: ... any number of examples which I will not bring up, as it will just end up a flame war.

Don't get me wrong. Go definitely has the feel of "worse is better" about it, and I hope some of the warts will be fixed in time. It just seems to me that, for non-technical reasons, Go has a (still small) chance of gaining some sort of traction in the space that C and C++ usually play in. I don't think it's the worst thing that could happen.

I love coding in new languages, when time permits. I do not know about other coders, but I have no problem coding in any particular language, even multiple ones at the same time (fun). They are all mostly C-lineage anyway, and the ones that are not have fun little features that make them a joy to use in moderation.

The more languages you use, the better you can decide which does a particular job effectively. So, Go might have unnatural backing, but does anyone really care?

Besides, no programming language these days is going to succeed on its own unless it contains a fundamental improvement on current practices. Beyond that it will need the backing of a major corporation to make any headway. It's like starting a new airline. You succeed only if your services are a major improvement on the current condition or you're a major corporation.

I enjoy this too. At first you do weird things like

vector<string> s;

for(var itr = s.begin(); itr != s.end(); ++itr)

But eventually you learn to avoid the got'ch'yas.

I also find myself implementing cool features from one language in another. Like split and combine from PHP in C++.

vector<string> explode(char seperator, const string &s);
string implode(char seperator, const vector<string> &ary);

That alone makes parsing directory stuff a breeze.

v = explode('.', dir);

if(v.size() > 1 && v.back() == "txt")
  // the file ends in .txt!