Google Go

[bascule]

Go is a new language created by Google:

 

http://golang.org

 

It's a comparatively low level language in a similar vein to C with a clear emphasis on speed. And not just execution speed, but also compile speed:

 

wwoWei-GAPo

 

As someone who would love to see scientists abandon horrid old monstrosities of programming languages like Fortran, here's another contender to add to the list. Oh, and did I mention it's garbage collected?

 

Personally I can't see myself using it, but hey scientists, go nuts.

[RyanJ]

I could see some uses for it. One more language to add to the "to learn" list I think.

 

Compile time is a big thing, especially on larger projects.

[JillSwift]

Wow. Is there nothing Google isn't getting into?

[Phi for All]

I love Google. They are so completely changing the way business is done, and it's refreshing to see a company that sees the appeal of appeal, rather than being blinded by obscene profits from a select market.

 

I want to see them start Google Democracy, and lend their transparency and collaborative practices to politics in the US. Then Google Military....

[doG]

I was just playing with it yesterday. It looks promising....

[ydoaPs]

i was just playing with it yesterday.

 

tmi

[bascule]

Compile time is a big thing, especially on larger projects.

 

Which is why I prefer scripting languages...

[RyanJ]

Which is why I prefer scripting languages...

 

That's true. But then you normally suffer from parse time which can be a real downer. But for the most part I agree. You can get lots done in Ruby, Python and others.

[doG]

Which is why I prefer scripting languages...

 

Is that so your code can be parsed and compiled every time it runs instead of just once?

[bascule]

Is that so your code can be parsed and compiled every time it runs instead of just once?

 

Yes, unless, say, the virtual machine executing my code happens to automagically cache the compiled versions... which it does!

[RyanJ]

Languages with JIT execute almost as fast as native code these days. The advantage being that scripted languages are normally easier to work with than compiled languages.

 

These days the boundaries are quite grayed out. Some languages can be both or either depending on how they are used.

[bascule]

Languages with JIT execute almost as fast as native code these days.

 

JITs generate native code. Languages with them should be considered compiled, not interpreted.

[RyanJ]

I don't really agree since JIT is classed as "compile-at-runtime" not compile then run. They may have the same underlying concept but the philosophy is totally different.

[bascule]

I don't really agree since JIT is classed as "compile-at-runtime" not compile then run. They may have the same underlying concept but the philosophy is totally different.

 

The important distinction between compiled and interpreted execution is code output through a JIT is native code and is executed directly by the CPU. This is much faster than an interpreter, which is effectively a machine-with-in-the-machine.

 

.NET, for example, has no interpreter. All .NET apps execute as native code.

 

The real difference here is that there is a runtime present handling the translation to native code (not to mention providing garbage collection, etc)

 

What you consider to be a "compiled" app can have a runtime too. Py2EXE will happily package your Python programs into a Windows .EXE file. This is indistinguishable to the end user from a program compiled from C/C++.

 

The same could be said of any Objective C program running on OS X or the iPhone. These all depend on the Objective C runtime.

[RyanJ]

I understand the differences but you often find that the philosophy of a JIT language is different from that of a compiled one.

 

Say, for example, in a scripted JIT language you could have a file to be processed and output native code that when executed would also be just as fast as usual compiled code (it's how my eBook organiser works). This is far more difficult with a compiled language.

[bascule]

I understand the differences but you often find that the philosophy of a JIT language is different from that of a compiled one.

 

I guess the distinction I'm trying to make that you're missing is that "JIT" is not the opposite of "compiled". JIT means just-in-time compiled.

 

The opposite of "just in time" is "ahead of time"

[RyanJ]

I know what it means I'm just saying that the philosophy of the two language designs is different. You don't often see super-large scripted programs while you often see very large compiled programs.

[bascule]

I know what it means I'm just saying that the philosophy of the two language designs is different. You don't often see super-large scripted programs while you often see very large compiled programs.

 

I'd argue this has far more to do with static versus dynamic type systems than it does with JIT vs AOT compilation.

 

.NET is JIT compiled, however there are rather large C# programs. C#, however, has a static type system.

 

That said, the core telco application application Erlang was originally created to write is millions of lines long. Erlang is a dynamic language.

[RyanJ]

You make a good point. I didn't consider .NET languages. Well pointed out. I'd give you a rep point for it but looks like I've got to give others first

 

I guess you win. You got me there.