Hacker News new | past | comments | ask | show | jobs | submit login

This talk is way too long and not very information dense. I jumped through it a little and liked what I saw, but I was wondering if anyone had a link to a white paper or an overview that could summarize the language features.

The story behind this is that Jon Blow is tired of making games in C and C++. He wants something better, but not necessarily something that is higher level. This demo goes over an initial prototype of the language. Shown are that he was able to relatively quickly get something up and working. The language operates well, but still has a lot of unknown things about it.

In the demo he shows the basic running of the language. Then he shows it's realistic to write games in the language by running a space invaders like game. He then also shows the power of using the language as the pre-processor (very lisp like) in that he is able to run arbitrary code during the compilation process, such as checking that your printf statements have the proper number of arguments, or having it so you need kill so many space invaders or your compile fails. He also showed that it runs on linux as well as windows.

Sounds like C++ with better syntax sugar. Is it really compiling already? That's impressive.

Yep! It compiles to C, and then the Windows C compiler takes over.

Why not use LLVM ?

Maybe because Windows reigns as development platform for game developers and LLVM still doesn't support it properly.

The language simultaneously compiles to bytecode and C. LLVM is potentially planned for the future.

OK, so not a real compilation. Still great though.

This is dealt with in the talk about 40 minutes in - it is described as a proper compiler, targeting either C or its own bytecode (which it uses for the compile-time execution).

The talk is just over an hour. The second hour is Q&A.

Just some thoughts:

#run can run anything, if you don't trust the codebase you have to check everything for malicious calls. ( #run format c: as a joke :-/ when you compile )

check functions seem to have limited use. They can't check for input that isn't hardcoded( or can they? ). A runtime check might be more valuable.

I don't remember if it was mentioned; I think having C like implicit conversions is a bad idea. If types don't match exactly, cast or give an error.

defer is interesting, do you get an error if you try to return an object which is also defered getting deleted?

Maybe the word check is a bit confusing, but the purpose of the feature is compile-time checking. Runtime checks would be implemented differently.

To clarify the probable mindset of the language designer: For games, runtime checks are pretty much useless - at runtime, the game is released and it's too late to do anything (ideally, discounting patches). So you want to catch everything you can at compile time. At the same time, performance is crucial. You need to be able to do everything the game needs to do within a 16ms time window. This means hardcoding / compiling in as many calculations as possible. Hence the focus on being able to do a lot at compile time.

> #run can run anything, if you don't trust the codebase you have to check everything for malicious calls.

That weakness already exists today in any project that relies on a build system (GNU Make, Autoconf, Ant/Maven, whatever), which is pretty much most of them.

About the trust thing - you probably don't often compile code without running it afterwards even now. A format call might be hidden in any library you use.

You are right. I usually wouldn't check the code if it is from a credible source anyway.

That was just the first reaction I got, wow this can run anything.

At 1:45:00:

> Do you really want a white paper?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact