[ikhare]

We use C quite heavily at Bump in our mobile apps. With our recent app Flock, we wrote nearly all non UI logic in C to be shared between iOS and Android. This made moving to a new platform much faster and easier than in times past. A lot of this core code is also used on the server to manage incoming connections from the clients as well.

Aside from the ability to share code, it also makes sure that we are not using anymore memory than we really need. Avoiding unnecessary GCs is an important concern in writing performant Android Apps. Having the core C layer only hold on to as little memory as possible is a huge win.

On a less objective note: When I left undergrad I thought I'd never write C again, but it was such a pleasure working with it again. Knowing (almost) exactly what operations your code is doing is quite liberating after working with so many other higher level languages and frameworks.

[jlgreco]

> Knowing (almost) exactly what operations your code is doing is quite liberating after working with so many other higher level languages and frameworks.

This is exactly why I still enjoy programming in C so much. Even compared to other languages that I adore and voluntarily use often, programming in C and programming in anything else feels like the difference between treading water in a swimming pool, and treading water in a murky lake. I just have a just a much greater, rather comforting, sense of situational awareness while using C.

[zanny]

I have this same sentiment, but I use C++ just because templates, classes, smart pointers, lambdas, and namespaces are such huge productivity gains.

[antidoh]

I keep on thinking I want to pick up C again (made a living with it 20 years ago), then I remember all the goodness that C++ adds (made a living with it 10 years ago), then I remember that C++ is huge and cryptic and I get all depressed again.

[primitur]

Learn Lua. I went through the same basic phase as you described, and once I'd gotten my competence with implementing Lua bindings up and running, I never looked back. For me, Lua+C is the most elegant combination of language tools I've used, and as a developer with 30+ years of experience, I've used most of them.

Lua really, really rocks - especially if you look at it as the domain tool it is, and not the prepackaged broad-spectrum scripting language that many people consider it to be ..

[mikec3k]

Agreed. At my last job I did most of my programming in Lua. We used C++ & Cocos2d-x with LuaC bindings for our game engine and wrote all of the game logic in Lua.

I really like a lot of Lua's features, especially closures and the way metatables work. Although Lua doesn't support true classes, it's possible to implement them nicely through metatables.

[qznc]

What do you use for basic data structures in C? Stuff like hash map, priority queue, sorted set, etc.

[primitur]

Fortunately, it is very easy to implement these structures in Lua, if they haven't already. The basic datatype of Lua - the table - can be treated as a hash map, a sorted set, a priority queue, very, very easily .. in fact if you think these things need to be implemented in C, you're missing a big part of the picture with Lua. The power of Lua as a language is really derived from the "morphological" nature of the basic table datatype .. Lua has all of the structures you're asking about, already.

And anything it doesn't have, which one would truly need to derive from the C/C++ side, is a few simple binding calls away .. but anyway, tables will do all you ask, and more, if you learn to use them properly.

[anonymous]

When you're using C as a layer under some other high-level language you get those implemented for you. For instance, if you write Python bindings, you will use Python's data structures from C. If those are too slow for you, you'll want a specialised structure - there are many libraries providing collections for C.

[zem]

glib is not bad. you can even use vala, which is c-like, but has built in glib and gobject support.

[charlieflowers]

What do you mean by "...as the domain tool it is, and not the prepackaged broad-spectrum scripting language..."?

I haven't used Lua yet, but reading about it led me to believe it was a "broad-spectrum scripting language".

I'd like to understand the distinction you're making more deeply.

[_dps]

There are two ways to look at Lua. There's Lua-the-abstract-language which can certainly be used as a broad-spectrum scripting language. I certainly use it in that capacity.

Then there's Lua-the-implementation(s) (PUC + LuaJIT), both of which are designed from the start to be maximally easy to embed in a host C program, or to delegate work to shared libraries written in C. In my opinion, it is an order of magnitude better at this than Python or Ruby; some of this is a matter of taste but I believe most of the advantages are objective.

Not to put words in the GP's mouth, but I take the "domain tool" comment to mean: "You really should try to use this in close cooperation with C, and not just as a stand-alone language. If you don't you'll miss a significant portion of the value." Note that using it in concert with C need not be done in a single person's head (though this case is also common); Lua+C is an extremely productive way for a systems programmer and an applications programmer to work in harmony while enjoying most of the best of both worlds.

[wtracy]

It doesn't have the "batteries included" philosophy of languages like Python, where there's already a ready-to-use library for everything. If you want to do anything non-trivial with Lua, you'll probably have to touch some C code.

[primitur]

Others have contributed good answers to this question in your sub-thread, so I will just clear this up for you:

domain tool - a tool which can be applied to, and adjusted according to the needs of the domain of your application. You can embed the Lua VM in your 'broader application' and use it as an internalized scripting language. If, for example, you've got a C/C++ program which sorts apples, you can export those apples, with bindings, into the Lua VM and reference them from the Lua language as apples, just the same ..

board-spectrum scripting language - python, perl, lua. Each of these can be (usually) found in /usr/bin somewhere, as a single executable that can be used to run the language scripts. Lua has a part in this role too - I frequently write system-admin scripts using #!/usr/bin/lua, but in this particular case I don't have any 'customizations' - I get only whats built-in to the Lua executable as shipped by my distribution.

But, beyond this, I could take the Lua VM and build my own domain tool with it. See the difference now?

[cageface]

Did you consider using MonoTouch/MonoDroid? Going all the way down to C seems pretty extreme just to achieve some code reuse.

[primitur]

I don't know what you mean by C being extreme .. for me, its not extreme at all, and rather I find working in C to be a comfortable, rewarding experience pretty much 100% of the time. But being able to extend beyond the scope of a static C application, and instead using C as the library/foundation for functionality that is exploited in Lua, is what I'm talking about. Bascially, you can have 'vanilla' Lua - /usr/bin/lua - or you can have "branded Lua" where, by branding, I mean - you add your own flair as you desire, to the Lua VM, using C (or C++).

MonoTouch/MonoDroid are not in my area of interest, since I prefer to have full sources available for everything, and I see no reason to buy such a tool when, with Lua+C/C++ I can just as easily build it myself ..