Ask HN: What programming language has you really excited lately, and why? | Hacker News Reader

Ask HN: What programming language has you really excited lately, and why?

61 pointssdegutis103 comments

I realized that almost all I ever do on HN is press Cmd-F, type "lang", see 0 results, and close it. So I figured I'd just ask y'all instead.

View on HN

Rust: it provides extremely strong guarantees about your code at compile time so that usually it feels like a script language with C/C++-levels of performance. And the best part: no data races, and no runtime garbage collector overhead.

Is that all? That's a pretty generic reason IMO.

I think you are underestimating how hard it is to get those guarantees, how much some people want them, and how long we've needed them.

To long time C developers, it's a huge deal. I'm starting my first primarily rust job on Monday and I'm extremely excited about it.

Where, if you don't mind sharing?

ThreatX

If they'd be interested in sharing more about their usage of Rust, we'd love to have them represented on our page of corporate users at https://www.rust-lang.org/friends.html .

Depending on much experience you have with ML-y type systems, Rust will either feel a little boring or like a revelation. The combination of pattern matching and algebraic data types is incredibly powerful and expressive and unlocks a style of coding where what in other languages would be potentially buggy logic that needs to be tested becomes mechanically checked typing information. Often, code can be trusted to just work if the type checker accepts it, which is especially handy if you make major changes to a large programme. Rust also favours immutable data structures, which also means some classes of bugs stop showing up in most cases. I've found these things to be a major productivity enhancement, maybe on par with going from manual memory management to garbage collection.

Which is another reason to be excited about Rust - it is to the best of my knowledge the only new language that allows you to write an entire programme or part of a programme that does no runtime memory allocation. While GC in most languages is not problematic in most cases, this makes it suited for embedded or hard-realtime work where C/C++ may have been the only option up until now. But it still has all these expressive, high-level features and safety mechanisms that makes it so suitable for programming well-structured, trustable software. There's a learning curve moving from GC to the ownership system, and maybe a plug-in garbage collector makes sense in some cases, but then the system does support that.

And then there's the tooling. Setting up a cross-compiler (again, embedded work), bringing in libraries from online repositories, packing up code modules for distribution and reuse, all that, is as easy as you'd expect coming from the web world because of the excellent Cargo system.

In short, while it might not be completely battle-tested yet, I think it has a better shot at being the "one language" that scales from tiny throw-away projects to large, complicated ones, and from watches to super computers than anything else I've seen.

As rvense explains below, there are a number of very desirable consequences to rusts strong static guarantees, and even performance improvements, all while getting less buggy code. It's even more secure in the sense of being less exploitable: the bugs being prevented by the type checkers are largely about resource allocation e.g. memory but also file handles. And those are often easily exploitable when not properly managed. That kind of compile-time bug prevention is something runtime garbage collection (that is, every VM platform out there) has yet to achieve and so is pretty amazing if you ask me.

Another consequence is the sheer range of applications for which this language can be practically used: systems and concurrent programming obviously, but also Web, realtime, embedded and even supercomputer programming. The reason for that is that rust mostly feels like a light weight scripting language like python, but because of its performance characteristics can viably be used as a drop-in replacement for C.

Rust: Which everyone seems to know about and I'm sure lots of people will be able to explain why.

So I'll focus on ... Haxe: Which is known in a few circles, but If I talk to a random person about it they've never heard of it.

Haxe is a garbage collected strictly typed compiled language with type inference. It compiles to a variety of platforms including C++, Javascript, Flash Bytecode, Neko VM bytecode, even PHP. More recently it has been growing support for C#, java, python and lua.

It's just a nice language to use. A combination of the cool features like pattern matching case statements, and the simple tidiness of the basics.

    for (minion in party) {
      minion.jumpToTheLeft();
    }

Just little things like not having 'for (var minion in party)'. It clears the clutter. while still protecting you.

In many respects, when compiling to JavaScript, it serves the niche that Dart and Typescript aim at. I think the fact that it is independent should not be underestimated. Google people tend to use Dart, Microsoft people use TypeScript. Haxe is not on a 'side' people use it because of what it is, not who made it. I'm rather against provenance as a reason to use a language.

The best way to get a good feel for Haxe is to go to http://try.haxe.org and look-at/run some of the examples.

> for (minion in party) {

> Just little things like not having 'for (var minion in party)'. It clears the clutter.

Would be even less cluttered if it allowed

    for minion in party {
      minion.jumpToTheLeft()
    }

Parens around a for clause when there's braces following are unnecessary.

It'd be less cluttered if "in" wasn't in there.

The shortest is Haskell's:

    forM_ party jumpToTheLeft

Assuming there is a 'party :: [ Minion ]' and 'jumpToTheLeft :: Minion -> IO Minion' in scope.

Haskell, seeing I still have so much to learn. Elm, because there seems to be a sane web frontend language. Swift, because I can do daily work in a modern language with so many parts done right.

A few people mentioned Python. Me, too. I left PHP (mostly) and can't stand the ascendency of JavaScript for everything under the sun (it's madness right now). I recently chose Python as my "go to" language for everything after reading a compelling post on Java for everything (not a typo). But I just don't like messy C-based languages like Java.

If someone would pay me big bucks one day for Java, I'd do it and program cool little machines and gadgets with it, but I love the web a lot and I am not about to continue the shoe-horning of Java and the Web (don't start with me).

So, I like Python for everything. Good web stuff. Great scripting and command line. Good for the Internet of Things (if you want to go down that path). Good for writing desktop. And yes, you could do games and mobile (although I admit the shoe-horning begins to show a little here). But I'm not in that space so much, so I accept that. And its pretty and stable (like Ruby) while not being quite as pretentious as Ruby.

Someone wrote WebAssembly. While not a language.... yes, yes, yes... I'm very excited about it. Because do you not SEE the reality that soon we could be writing web code on web pages with pre-compiled speedy fun stuff but written in our language of choice, including Python? Is no one talking about this? It will just take someone writing a Web Assembly Compiler (not sure if that will be the right terminology) in your language of choice. Oh. My. Goodness. Death to JavaScript. Maybe. Or at least an arm lopped off its torso.

D (dlang). It's the C++ I always wanted. It's safe, modern, fast, and familiar. It's got classes with reference semantics, structs with value semantics, safe concurrency by default, support for functional programming, concise syntax yet with the C/Java/C++/C# flavour, speed, a compile-time complete D interpreter (thus allowing metaprogramming in the same language as the runtime language, almost lisp-like), plus all the common syntactic niceties we've come to expect from modern languages.

My only complaint so far is that the reference implementation has a stupid license, but most other D users just ignore the terms of the license. I had also found a performance bug in an stdlib function, but it's since been addressed in dev.

what do you mean stupid license? what are the restrictions?

https://lobste.rs/s/uafwxi/safe_c_subset_is_vapourware/comme...

Thankfully, there are other implementations with perfectly free licenses: gdc and lldc.

That's written tongue in cheek, and it basically means something totally different to what you understood.

The license doesn't forbid anything. At all. It simply states that it doesn't guarantee any use at all either.

Therefore, you can use it to do whatever you want to do, but because there was no guarantee, you can't sue the software creator.

I will paste the text here, for others to read it:

    "The Software is not generally available software. It has not undergone testing and may contain errors. The Software was not designed to operate after December 31, 1999. It may be incomplete and it may not function properly. No support or maintenance is provided with this Software. Do not install or distribute the Software if you are not accustomed to using or distributing experimental software. Do not use this software for life critical applications, or applications that could cause significant harm or property damage."

Now my explanation: Don't use DMD it in a peacemaker. Or use it, if you thing the technology is suitable. But if you do use it in a peacemaker, and it fails, it will be your fault and not the fault of the creator of the DMD compiler. It's pretty much a standard disclaimer and all licenses have one.

The equivalent disclaimer text of the GPL license (used by gdc and lots of other software) is this (the original text is in caps):

    THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

    IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Anyway, the best part of D is that I think the confusing text will be discussed in their forums by their great community and something will be done about it.

> That's written tongue in cheek

Lawyers don't have tongues or cheeks.

I have been told that Walter regularly tries to change the license but Symantec just doesn't seem to care.

> I have been told that Walter regularly tries to change the license but Symantec just doesn't seem to care.

Now that's sad :/

I was right about the D community, this has been discussed this month.

http://forum.dlang.org/thread/lodjbuvdhimrvrdngldy@forum.dla...

Elm. Because it is super clean and easy to read. The compile time errors are fantastic. I feel, if my app compiles then it is going to do what I want. Not so when developing with other JS frameworks. The whole paradigm feels like it is build for making web applications.

Lately?

C# triggered by: - Open sourcing of .NET - Open Sourcing of Xamarin

I want to live in a world where writing mobile apps for multiple platforms with a single codebase becomes the de-facto way of doing things. C#/Xamarin seems like the only viable way to achieve that.

What about react native?

React Native is "learn once, write everywhere" as opposed to "write once, run everywhere."

JS ES2015. The syntax looks awful at first glance, but after heavily using it, there's much more power to this language now.

The syntax looks awful? It looks extremely clean. It cleaned up the JS syntax enormously...

Talking mostly about things like:

// 1. [a + b] // [a + b] is an array {[a + b]: c} // [a + b] is not an array

// 2. { x, y: x, y} // inconsistent object fields

and there are more examples. After you get to know the syntax, it can be used for good -- but some decisions are making the language more complex.

As written above, I enjoy its new features

Bracket notation isn't anything new to ES2015, using it in that context is though.

var a = [3] // [3] is an array

var b = {3: 4}; b[3] // [3] is not an array

This is the correct answer.

Jokes aside, ES2015 hits the sweet spot for new powerful languages with big-name backers (facebook is compiled in babel).

https://twitter.com/amasad/status/631251607422787584

I'm in this camp as well. I've always enjoyed JS because I feel like I can get stuff done so much quicker. With ES6/2015, now I feel like it's far more powerful, elegant and fun to use.

What about ES7? Async await syntax is a game changer

async/await is not in ES7.

Where is it then?

TC39 is still working on it, it's in stage 3.

https://github.com/tc39/proposals

Picat. A new language that blends different paradigms including logic programming, constraint solving, pattern matching into a cohesive whole. Allows for very compact, elegant solutions to many problems.

How's Picat performance-wise?

F# is pretty sweet. It's concise, no ceremony, type safety, can be used with all .net libs, functional. I'm a beginner but love diving into it.

F# is excellent and the only reason I'd stick with .NET. Unfortunately, Microsoft doesn't think so, and continues to dump massive amounts of resources into C# while only paying lip service to F#. (See, for instance, the full-featured C# Interactive in VS. It arrived like 10 years late, but it's a much slicker experience, apart from the language.)

F# with C#-level tooling would be unstoppable. Though it's pretty fantastic as-is.

Are you developing in Windows or Linux? If Linux, what is your toolset and workflow?

Develop and compile on Windows with MS tools, deploy on Linux. VS+VsVim does a nice job with F# (I tried Emacs with evil but it's not as good for F#). Deployment is as easy as copying an exe.

Thank you. I've been fooling around with VS Code and Mono, but I have been considering doing exactly as you described.

Crystal, Elixir, Haskell, and PHP7.1

Crystal because it brings me the elegance of Ruby with better Type safety. The type inference in Crystal has been improving a lot since I started looking into it as well.

Elixir mostly because it fits the sweet spot where I'd have used node.js for network/event heavy apps.

Haskell because I'm still trying to learn it _properly_.

PHP7.1 because I work in PHP every day, and I am excited about lots of upcoming changes in the next release. There have been lots of interesting RFCs (for the language) as well as PSRs (for the interop packages) raised recently and PHP isn't the same old thing any more.

I guess you were hoping for new cutting edge stuff, but I've been really enjoying Common Lisp.

I've used it for a bunch of small projects the last year or so, and just have a ton of fun. In particular, it has surprisingly good bindings to graphics libraries like Qt, SDL, and OpenGL, and it's super easy to get animations and graphical apps up and running quickly.

The compilers are great for such a high level language, and it's significantly faster than Python, which was my preferred language before CL. It doesn't beat the raw speed of C, but I rarely need that anyway. As an example, I just wrote a cheesy, animated FFT visualization and full screen at 2560x1440 it gets 90+ fps with no attempt to optimize on my part, except turning up the default optimization level. https://github.com/jl2/qt-fft-viz

The REPL and code reloading makes iterating on ideas really fast, and I find I experiment more in CL because it's just easier.

What CL implementation are you using, on what OS?

SBCL, mostly on Linux, but also a bit on OSX. Both platforms work really well, but the experience is a bit smoother on Linux.

On both platforms I have a script that pulls from Git, rebuilds, and installs over the previous SBCL binary image, so I'm using the absolute bleeding edge of the compiler. One day this will bite me somehow and then I'll start using the most recent stable tag, but it's worked okay up to now.

I use Emacs and Slime for development. I had used Emacs for a long time before using CL, so using Slime wasn't an issue for me at all. I know the commercial implementations have some neat IDEs, but I haven't tried them. I'm not sure there's many (or any) OSS alternatives to Slime.

On both platforms I use QuickLisp to install all of the Lisp packages I use. Pure Lisp libraries always work great on both platforms.

Libraries that wrap C/C++ libraries (like Qt or SDL) tend to work better on Linux, but in every case I can think of I've got them working on OSX also, with varying degrees of effort.

On Debian I "apt-get install ..." the required lib* and sometimes lib*-dev packages, and then (ql:quickload ...) has always just worked.

External libraries on OSX are where I've encountered the most problems. Qt was particularly tricky, and I'm not even 100% sure what I did that finally got it working. SDL has some hoops to jump through with a "cocoa helper library" that I had to build by hand, but it's pretty simple and a few minutes Googling turned up enough info to get it working. For the majority of the stuff I've needed (libpng, cairo2, mpg123, and a few others), I was able to install them with HomeBrew, and they just worked once I had my PATH and LD_LIBRARY_PATH setup correctly. OSX ships ancient versions of several libraries (like libpng), but installing the version in HomeBrew usually fixes the problem.

Thanks for the detailed answer, interesting. Hadn't known that Common Lisp had Qt bindings.

I love writing Lisp, it feels not so much like coding but like writing poetry... Unfortunately, it has lots of problems with interpreter interoperability, lack of threading, etc. (unless I simply haven't found the solution to my problems yet). Therefore I often find myself forsaking it for Python, which has the added advantage that my friends will be able to read the code.

All of the modern Common Lisp implementations support threading. I'd almost even say the situation is better than most other languages, because there is very good threading support at several levels of abstraction.

First, all of the modern implementations include some kind of implementation specific, low level OS thread wrapper. It's unfortunate that these are all incompatible, but few people need to use them directly, so it's really not too bad.

Next, the bordeaux-threads library provides a wrapper around all of the implementation specific libraries. Thanks to macros, the wrapper doesn't add much (if any) overhead.

Finally, there are higher level libraries like lparallel and cl-cuda. I've used lparallel a few times, and much prefer it to writing my own low level threading.

I'm not really sure what you mean by "interpreter interoperability". Common Lisp is standardized, and sticking to the standard and libraries in QuickLisp, I haven't run into many problems running my code across multiple platforms and multiple implementations of Common Lisp. All of the problems I've encountered have been related to foreign libraries, which, IME, are problematic in most languages.

I wasn't aware of lparallel and cl-cuda, thank you for pointing those out! The only threading I knew of was the implementation-specific kind, which makes for some portability headaches. (Especially as I personally use CLISP instead of the more common SBCL.)

Yes, the standardized definition is a Good Thing. What I meant by "interpreter interoperability" (I probably should have said implementation compatibility) are things like processing commandline arguments, which are not defined in the standard and vary wildly between operations. (Is there a library for that too? I haven't come across any yet, but that might just be me.)

Rust: low level performance, high level safety, functional, AMAZING community

Elm: beautiful front-end development in a tough to navigate JS world

Elixir: functional back-end programming on top of the BEAM VM

ES 2015 & node.js: I really enjoy and appreciate a language growing in the ways JS has and I love seeing the frameworks influence and borrow from one another (ember, react, angular). While the ecosystem is sometimes annoying, it's been a joy to see the evolution and natural selection of tools and libraries (e.g. flux, alt, flummox, and eventually redux coming out on top...for now)

Lately it's been Scheme because I've been using it to teach my 14 y/o daughter how to program. I had considered teaching her JS but she already knows that a little bit and I thought the concepts she'd learn while learning Scheme would really help her in the long run regardless of what language she used.

Scheme is probably the most beautiful language I know, but, alas, of limited practical value :-(

Crystal: Syntax inspired by Ruby, static types and compiled by LLVM. The standard library is mostly similar to Ruby (I'd say it's better. For example it rack-like functionality and websockets built-in). It's getting a lot of traction in the community.

Crystal looks interesting, but is it usable in production? Any examples of people using it?

Sidekiq was recently ported over to crystal and the speedups and memory usage improvements are amazing. There's also an officially supported heroku-buildpack so it can be deployed easily.

But there's a lot of breaking changes in the language (0.18 was released a few days ago with a few breaking changes). I would not use it for a long term project (yet). But for some personal project or prototypes, for example which you'd quickly set using Ruby/Sinatra, I'd choose Crystal/Kemal.

Go. I may have to teach a mathematician with limited programming experience how to write parallel* algorithms, and Go seems far easier than alternatives (like C++) for a beginner.

* (or concurrent)

None.

That's why I've been developing my own language (http://web.onetel.com/~hibou/fmj/tutorials/TOC.html). It isn't ready yet: there are still bugs in the IDE, and without a compiler it's slow. After fixing these problems, I also want to look at new ways to do graph processing. Then, I'll think about releasing it, if there's enough interest. Let me know what you think.

Features: visual, dataflow, HM type inference while editing, homoiconic, can call Lisp and callable from Lisp.

Elixir makes me warm and fuzzy.

I second Elixir. Concurrency and HA are the future!

Same here, it makes me go like woo!

As primarily a C# and JavaScript developer, I'd say TypeScript. Best of both worlds and I feel pretty productive in it (once past the pain of setup).

Not a c# dev, but definitely typescript makes me feel more motivated to write code these days.

Nim because of the syntax, performance, and base library.

...and powerful templating, low memory usage, portability.

...and user type-classes, compile-time AST macros, and GC-as-an-API

Happy to see Python getting first party support for concurrency.

Racket - I love everything about it. It has Functional Programming that makes sense to me, I went through Haskell books 3 times over the years and took a few weeks to be flying with Racket.

As a scheme guy in general, I myself am very excited by typed/racket. I have always been torn between ML-like languages and lisp-style, with the latter winning most of the time. I have gotten so used to the syntax that I prefer it to most other languages.

But I miss the niceness of typing, which typed racket provides. There are some warts, like having to explicitly typecast when using two polymorphic functions, and that the curry procedure doesn't work as in racket, but other than that it is not far from what I would perceive as the perfect language.

I could of course wish for some other things, like making a curried and strictly typed scheme-like language, but i'm not going to push my luck :)

Clojure. Particularly with Paredit mode in Emacs. The experience of manipulating semantic units of code vs. editing text is a joy and I really, really miss it when I return to e.g. Python.

I really like parinfer for this, too. After switching to it, I've had a great time using it.

Ponylang. Just seems to fit my mental model well. Wish it was more ready for prime time.

PHP: With the new 7 release, it gets a surprising speed boost, a collection of elegant new syntax, and maintains backwards compatibility with an incredible ecosystem of packages. Modern projects like Laravel and Slim continue to push best practices, and the community is one of the largest. It's an incredibly versatile language with a robust feature set.

None, because the existing languages were close to good enough for the problems that I try to solve. There's nothing that's opening up new frontiers in a mind-blowing kind of way, at least not from where I stand.

But some languages are kind of interesting:

C++11/14, because it opened up some new ways of writing efficient code safely.

Haskell, because of HM types.

Lisp, because of homoiconicity and macros.

Elm, because it helps to unload part of the cognitive burden of frontend development.

Elixir, to taste functional programming on the backend.

https://github.com/monte-language/monte is reviving E, the distributed capability language.

Elm because I'm new to functional programming and it hurts my head.

Also like newLISP. Powerful, small, practical and thought provoking.

Laravel (PHP Framework)

Great Documentation https://laravel.com/docs/5.2

Local Development Tools/Box https://laravel.com/docs/5.2/valet https://laravel.com/docs/5.2/homestead

Easy to Spin Up servers and deploy https://forge.laravel.com/servers

Zero downtime deployment https://envoyer.io/

Micro/Slim version https://lumen.laravel.com/

SaaS in a box https://spark.laravel.com/

Great Learning Videos and Community https://laracasts.com/

Myrddin (https://myrlang.org). Mostly because it's my pet project, and it's fun to work on it.

Dart: For me it's still _the_ successor of JavaScript. However, the market didn't adopt it as well as Typescript. Thus, in work life I play safe with Typescript.

Eve (Dev Blog: http://incidentalcomplexity.com): the guys are "working on bringing programming to everyone". A lot of innovative stuff here. Not yet ready but _really_ exciting!

Scala: I love the mix of FP with OO all on the JVM with access to battle-tested Java libraries. I can also use it on the frontend with https://www.scala-js.org/ and potentially as a lower level system language with http://www.scala-native.org/

It's a pity Apache Groovy's ongoing governance problems stopped it achieving a similar goal. Groovy's still great, though, for writing quick'n'dirty scripts for testing Java classes and defining builds, and Grails still offers Groovy exclusively for scripting (though I wouldn't be surprised if Grails soon follows Gradle down the path of enabling Kotlin as a scripting language).

Modern Perl with Mojolicious makes me happy. Perl has enjoyed yearly releases and with Moose has fantastic OO; also the community is vibrant.

Ditto.

C# and ASP.NET Core. No more IIS server. Instead, built in web server that can be configured via pure C# code. Visual Studio is the most powerful GUI on the planet. C# & ASP.NET is now open source. CNTK is a multi-core GPU optimized deep neural network run via C#.

http://lbstanza.org/ because it reuses all the good stuff from Dylan.

jq is a command line tool and also a language for expressing transformations on JSON with concise one-liners. It is useful for processing the output of mongoexport or an elasticsearch query.

The basic constructs are "filter expressions". Pipes (|) can be used to direct the output of one filter expression to another, and commas (,) can be used to concatenate the output of two filter expressions.

Ceylon, because after you've seen union types you wonder why they aren't implemented in every statically typed language.

C++: Because it (and C) runs the world. Including other languages (Java/Python/Ruby/Clojure/...)

Swift. I've been doing more and more iPhone development lately, so much nicer than ObjectiveC and half the files (I refuse to miss header files).

But I was also doing a lot of Java, which has made me more excited about getting back into C#. As far as language features go, Java is C# poor cousin.

Picolisp. And of course OCaml.

C++ because of it's power and because it is evolving in intelligent way

Clojurescript. Because it's better Javascript than Javascript.

DLang. Golang. FreePascal. All 3 for speed of both compiling and running. And some good language and library features too.

Also Python, because VHLL, batteries included, and community.

Kinda chocked that nobody mentioned JuliaLang yet

clojure due to the release of clojure.spec a few days ago.

WebAssembly. A real game changer!

jai, a language for game developers without gc from Jonathan Blow

mIRCSCRIPT

Reply on news.ycombinator.com