Google's Go - A new open source language

Lua also aims for speed and flexibility by having some of it written in C or C++ and some in their scripting language.

Quoting:Lua is embeddable Lua is a fast language engine with small footprint that you can embed easily into your application. Lua has a simple and well documented API that allows strong integration with code written in other languages. It is easy to extend Lua with libraries written in other languages. It is also easy to extend programs written in other languages with Lua. Lua has been used to extend programs written not only in C and C++, but also in Java, C#, Smalltalk, Fortran, Ada, and even in other scripting languages, such as Perl and Ruby.

http://www.lua.org/about.html

Lua lua, oh no. Me gotta go.

Come, Mister tally man, tally me banana Daylight come and me wan' go home Come, Mister tally man, tally me banana Daylight come and me wan' go home

That's what you reminded me of, tc.

Oh great, yet another earworm. DAY o. DAAAAAAAY o.

@moopst: I disagree. Go is not made for speed. It's made for *compilation* speed. Lua isn't compiled at all but interpreted. That's why it's used in combination with so many other languages. The first version of my gnome-hearts game used Lua for the computer opponents. It meant that I could rewrite the opponents without recompiling all of gnome-hearts.

GO sounds quite redundant with Walter Bright's D language to me. I've got to say, though, that all this emphasis on "garbage collection" (in both D and GO)is a ridiculous and wasteful consumer of CPU power. Memory leaks can be detected and resolved at development time (leak detectors such as Purify have been around for almost 20 years).

Lua lets you compile your own functions in C for the parts that need speed and write the rest in the scripting language. That gives you speed and flexibility.

@moopst: But then you're back writing C, which is exactly what Google *doesn't* want to do. And writing C isn't that flexible.

Also, Lua itself isn't fast. It's fast for an interpreted language, sure. But compared to compiled code it's just nowhere.

@TheDuke: It's really hard if not impossible to test every possible code path for memory leaks. There are just too many. Also, testing all those paths takes time. Garbage collection simply exchanges CPU time for developer time. Usually not too bad in a world where there is CPU power in abundance and developer time is scarce.

I'd rather waste some CPU-time than see my memory filling until the OS stalls.

Quoting:I'd rather waste some CPU-time than see my memory filling until the OS stalls.

Most definitely. In fact I have a strange recurring problem that does exactly that that I haven't tracked down exactly yet. If I try to play a video that is incomplete/corrupted, but apparently only in certain ways, VLC will go into an immediate memory overload (I'm talking full RAM usage and SWAP starting to thrash within about 2 seconds). The odd thing is....in my previous install mplayer did it but vlc didn't...but in this install vlc does it but mplayer doesn't...so I'm really not sure exactly WHAT is causing the problem. :P

So yes, I would much prefer a little extra cpu time usage to catch things like this than to have to hard reboot because the system is totally unresponsive.

@Sander

Quoting: It's really hard if not impossible to test every possible code path for memory leaks. There are just too many. Also, testing all those paths takes time. Garbage collection simply exchanges CPU time for developer time. Usually not too bad in a world where there is CPU power in abundance and developer time is scarce.

I will only partially agree here in that GC is useful but its kind of overblown. There are multiple techniques to ensure little or no memory leaks during development for C/C++ (e.g. smart pointers, using value semantics with RAII where possible, or GC implementations like Boehm's). Most C++ projects will have their set of conventions and guidelines to avoid this.

But, the problem is that memory is just one of the resources. Simply too many programmers using languages with GC think that it is the end of all and pay scarce attention to other resources (e.g. sockets, connection abstractions, timers etc). Proper handling of such can require much code (with many languages multiple try...finally blocks which is error-prone and ugly compared to RAII in C++ for example).

@Sander_Marechal: If you can't detect a memory leak then it probably doesn't matter much. And, what use is a systems programming language that doesn't lend itself to real-time applications.

What's the difference between a memory leak in C, and a "forgot to null-that object reference" in Java?

Hint: none.

But in Java, when the object reference passes out of scope, the object becomes a candidate for collection, and will be finalized and reclaimed during the next GC run.

C has no such guarantee, and C++ can guarantee it only for automatic object variables, not for objects created with "new". If the reference passes out of scope without a corresponding "delete", it's a leak.

@theduke459 I will disagree on this:

Quoting: If you can't detect a memory leak then it probably doesn't matter much.

Sander is right that there is no way in which developer can detect all possible memory leaks using testing with tools like Purify because barring trivial programs, there are far too many scenarios, code-paths and no medium to large sized project can safely rely on its test suite to detect such. IMO the correct approach is to have a set of guidelines (e.g. in my current project a mix of smart pointers and value semantics is used as appropriate) and proper code reviews.

@phsolide

Quoting: What's the difference between a memory leak in C, and a "forgot to null-that object reference" in Java?

Hint: none.

No there is hardly any similarity. The latter in Java is intended to act like a hint to GC in the hope of getting the object GCed though in practice there are very very few situations where it will be required or desired. In other words "forgot to null-that object reference" has got to do nothing with a memory leak.