Which programming language did you choose and why?

[Tramboi]

Interesting, you still have use for inline asm? What I read nowadays is mostly intrinsics.

A few lines a year on average myself, because of such or such compiler limitations (support or scheduling). But I know people who write more (I'd say hundreds of lines a year) in lowlevel gaming middleware.
Edit: but lots of people who never wrote a line of assembly spend lots of time reading the generated code in profilers.

GOAL is different than R[567]RS though. Another good dev company is Factorio. I can tell from their dev posts, even though they haven't shared any code.

Yes my point was that DSLs are good when doing big games with lots of people involved.

And yes, Factorio is impressive. You can feel the very specific engine, well dedicated to the task at hand.

 

[Twiglard]

lots of people who never wrote a line of assembly spend lots of time reading the generated code in profilers.

FWIW I do that too, to see what got vectorized, whether it's known as aligned, and whether the compiler was able to eliminate branching in ALU code.

 

[Tramboi]

FWIW I do that too, to see what got vectorized, whether it's known as aligned, and whether the compiler was able to eliminate branching in ALU code.

And that's what any performance-oriented HLL programmer should do! So props to you.
I intend not to rely on compiler vectorization because it's too brittle when you change the source code, but it could be a huge time-saver (and I mostly target one well-defined platform these days).

 

[Twiglard]

And that's what any performance-oriented HLL programmer should do!

HLL used to mean a different thing. Now it's all multiple levels of indirection, boxing, RTTI, and time- as well as space-unbounded GC timings. The latter doesn't even get half the recognition it deserves. With SBCL I was able to cause a panic by triggering an OOM condition. That happens as long as there's no RSS/working set limit.

On unrelated note, any of you still using swap on workstations?

 

[Catacombs]

When doing day-to-day work, what's your go-to language? For me, it used to be Python, but now I'm always reaching for bash.

 

[daivin]

Bash too. With sed & awk.

When i need to write functions, i use Lua because Bash is a pain for that. (and Lua has popen() so i can call bash from it and parse outputs).

 

[Catacombs]

When i need to write functions, i use Lua

Interesting. How is Lua better than Python? I don't use Lua often and would consider incorporating it into my workflow if the pros outweigh the cons. I always thought Lua was good for gamedev.

 

[daivin]

I wouldn't say that Lua is "better" than Python because they are quite different. To be honest, i don't like Python much, but that's personal taste.

That said, we can honestly confirm:

- Lua is minimalistic, and has a very small set of data type (one, in fact). This can be seen as a con, but a hashed data array is all we need. Plus, table format (the data type of Lua) is almost json format (the conversion is trivial).

- Lua is easy to learn (some caveats of course if you want full mastery). The reference book ("Programming in Lua") is quite slim, compared to the Python litterature.

- Lua is lightweight. If you have to deploy your script, that makes thing easier. Most of time, you just have to ship the script with the interpreter (not even needed if you have lua interpreter in execution path), and that's all.

- Lua is way faster than Python. For scripting, it can be marginal , but sometimes useful. For example, I was happy of its speed for a script which parse large amount of logs to update dynamically a firewall.

Lua has been used a lot in the past in game development, for scripting and controling C modules. Since the last ten years, that's not the case anymore. But for example, Grimrock use Lua (there had been some interesting posts about this on the Grimrocks's blog). Now that most of games are done with Unity or Unreal Engine, that's history.

I think you already know this framework, but just in case : https://love2d.org/ (it uses LuaJit which is even faster than the "official" Lua interpreter).
Some folks i know use löve2D for scripting in their company (they have made a console quite easily with it, for controlling things).

Defold engine is using Lua too.

Now, if you need a lot of things (network support, web scrapping and so on), Python is far easier. Of course, you can do everything with Lua, but sometimes it will be slower to do than just import a lib with Python.

Another problem of Lua is the fragmentation of the community. There has been luajit , which as the name says jit Lua. But it has not evolved with Lua and it's stuck in 5.15 version (it supports some things from Lua 5.2, but not everything). The official Lua is v5.4 . But that's more a problem for the community itself than for scripting. For scripting, i recommend to use the official Lua.

 

[negator2vc]

I love Lua and Love2D (no pun intented ;-) ).
So simple and so similar to an old favorite language of mine (QuickBasic) while very modern in it's own way!

I used to program in it (Love2D - Lua) before switching to Godot and GDScript due to Love2D's lack of web export
(I do alot of jam games and web export is pretty mandatory if you want people to play your games)
and the fact the editor is a biiiigggg help in gamedev (especially Godot editor)

For my main job (web dev) I use C# but I prefer the simplicity of both Lua and GDScript.
One of the reasons I stick to GDScript for Godot instead of using C# with it.

I need to try FreeBasic sometimes!

 

[CanadianCorndog]

Yeah, Lua and Love2D is fun for small hobby projects. Using Concord ECS and some other libraries. I've used Unreal, Unity and lots of custom engines for work but for my own stuff which is one man studio sized Love2D is fun. Cuts through the bullshit.

 

[Monk]

"Rust support in Linux may be possible by 5.14 release: Torvalds"

Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling.

"LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.

 

[Rincewind]

Interesting. How is Lua better than Python? I don't use Lua often and would consider incorporating it into my workflow if the pros outweigh the cons. I always thought Lua was good for gamedev.

One of the most important points was not mentioned: Lua started its life as a configuration language meant to be embedded in apps written in other languages. So the most typical use case for Lua is that you start your main loop written in C or something, then you execute Lua scripts from there, which in turn make calls to your C API.

With Python it's usually the other way around. Your main program is written in Python and you can write Python modules in C or some other language that you can call from your Python code. It's a general purpose programming language with "batteries included", which means lots of useful libraries included out of the box. But a Python installation is huge. Python 3.9 on my Windows machine measures 156 megs!

So as a scripting language within your app, or as a "glue" language to orchestrate modules written in your low-level host language, Lua is the one to choose in 99% of the cases. It's not only used for games; the most famous non-game example is probably Adobe Ligthroom. The image processing parts are written in C++, and probably some platform-specific OS level stuff, but the whole UI logic and the orchestration of the low level components is written in Lua.

 

[Catacombs]

Interesting. How is Lua better than Python? I don't use Lua often and would consider incorporating it into my workflow if the pros outweigh the cons. I always thought Lua was good for gamedev.

One of the most important points was not mentioned: Lua started its life as a configuration language meant to be embedded in apps written in other languages. So the most typical use case for Lua is that you start your main loop written in C or something, then you execute Lua scripts from there, which in turn make calls to your C API.

With Python it's usually the other way around. Your main program is written in Python and you can write Python modules in C or some other language that you can call from your Python code. It's a general purpose programming language with "batteries included", which means lots of useful libraries included out of the box. But a Python installation is huge. Python 3.9 on my Windows machine measures 156 megs!

So as a scripting language within your app, or as a "glue" language to orchestrate modules written in your low-level host language, Lua is the one to choose in 99% of the cases. It's not only used for games; the most famous non-game example is probably Adobe Ligthroom. The image processing parts are written in C++, and probably some platform-specific OS level stuff, but the whole UI logic and the orchestration of the low level components is written in Lua.

Thanks for the detailed explaination. I'm still new to low-level programming, but I'm not sure as to what scripting languages offer in a program. For example, does a Lua script, as you mentioned its history, read a complicated configuration file and pump it into a usable format for C/C++? I guess it's hard for me to visualize this through text without seeing a simple example.

 

[Rincewind]

Thanks for the detailed explaination. I'm still new to low-level programming, but I'm not sure as to what scripting languages offer in a program. For example, does a Lua script, as you mentioned its history, read a complicated configuration file and pump it into a usable format for C/C++? I guess it's hard for me to visualize this through text without seeing a simple example.

I think the term "scripting language" is a bit of a misnomer, especially nowadays. It's more useful to talk about low-level and high-level languages.

Here's my ultra-concise summary between high and low level languages (and I'm sure many people will disagree with it...):

• Simply put, if you need ultimate performance, you want accurate control over how the memory gets allocated, how your data gets laid out in memory, etc. C/C++ lets you do that, but at a cost (lots of fiddling around with "stuff", lots of complexity, etc.) It's a bit like painting your room with a very fine paintbrush -- gives you ultimate accuracy, sure, but it will take forever so it's overall a waste of time.
• High-level languages, on the other hand, are very close to pseudo-code and more or less abstract the computer hardware away (you have zero control over how the memory gets laid out, how many bits you use for representing a number in memory, etc.). This makes writing programs in high-level languages much more productive, but usually at the cost of performance, executable size, and such. It's akin to using a large brush to paint your living room; much faster than the fine paintbrush approach, but if you want to accurately paint around light switches and window frames, you're a bit screwed.

The combined approach is what most sane people do: write the game engine in C/C++ that does the rendering and calculation intensive tasks, then the game logic and the general logic flow that ties things together in a high-level language like Lua. Basically, it's about taking the more productive approach where you can afford it. Another way to look at it is if high-level languages offered the same optimisation & performance benefits as low-level languages, we wouldn't bother with C/C++ and such... But, because they still make a meaningful difference, we can't just ditch them in favour of more productive languages.

In the case of Lightroom (a photo manipulating/retouching program), all the memory and CPU intensive image manipulation routines are written in C++. But that's only about 30% of the total code base, perhaps. The rest is drawing the UI, handling the various UI elements, the catagorisation of the photo library, printing, image tagging, and so on. None of these remaining 70% of tasks need ultimate efficiency, writing them in C++ would be a colossal waste of time for little to no benefit. Therefore, the team used Lua for non-performance-critical parts of the application. (Sidenote: this also results in less bugs usually, or at least less severe ones (as in instant crashes). As you're not fucking around with memory and pointers and stuff like that directly in high-level languages, there's much less chance to do something catastrophic.)

Lastly, don't let the term "configuration language" fool you thinking Lua is only good for reading configuration. That was its original intention way back in the past, yes; I only mentioned that to emphasize the fact that it was designed to be embedded into a "host" application. Nowadays, Lua is a general purpose high-level programming language, just like Python, C# or Java, with the extra important advantage of being much easier to embed in C and C++ than other high-level languages offering similar range of functionality. The disadvantage is that it doesn't come with an extensive standard library like Python, Java, C#, etc., so for standalone applications it might not be the best choice.

 

[Wysardry]

Now that I have discovered that it's possible to use it with at least three game engines, I'm leaning heavily towards using Pascal.

I've never been a fan of C style curly braces or low level languages.

 

[Rincewind]

Now that I have discovered that it's possible to use it with at least three game engines, I'm leaning heavily towards using Pascal.

I've never been a fan of C style curly braces or low level languages.

In that case, you might enjoy Nim as well:

https://nim-lang.org/

 

[Wysardry]

Interesting and worthy of being bookmarked. I don't immediately see any obvious advantages over using Pascal though.

I did notice that the first version of the Nim compiler was written using Free Pascal.

 

[Rincewind]

I don't immediately see any obvious advantages over using Pascal though.

• Easy C interop
• Compile time macros
• Efficient per thread garbage collector suitable for soft-realtime apps (so no "stop the world" GC cycles)
• Or instead of the GC, automatic memory management using reference counting
  
• No being/end blocks

I've been using it for the last 4-5 years as my hobby language and it's quite nice. If you just look at it feature by feature, it might not seem anything too remarkable, but it's really a "sweet spot" language. All features just fit together nicely in an optimal way that makes it fun and a joy to use WHILE it's capable of C-level performance and low-level control.

 

[Hirato]

If you're using Lua and you're worried about speed, there is an extremely well optimised variant called LuaJIT.

 

[daivin]

LuaJIT (5.1 some pieces of 5.2) is far behind current Lua (5.4). Since Mike Pall has left the boat, no one was able to pick up the torch.

Anyway, do we need 5.4 ? Or even 5.3 … that's another subject.

 

[Savecummer]

HOW ELSE WOULD YOU PARSE EEEMMOOOOJJJJIIIIIISSSSS without utf8!!!!1

 

[Wysardry]

Does anyone know of any other languages similar to Nim and Haxe that can create source code in multiple programming languages?

Nim can compile to C, C++ and JavaScript. Haxe can compile to JavaScript, C++, C#, Java, JVM, Python, Lua, PHP and Flash.

 

[Twiglard]

OCaml and Reason ML compile to JS. F# has some commercial JS/wasm backend.

Nim and Haxe are badly designed languages.

 

[Galdred]

I chose to go with moai, because at the time I started learning to program games, it felt like a good compromise between portability, flexibility, and customisation (it is open source and free, so you can alter the code any way you want, instead of waiting for [insert engine name] support to solve issues you have no access to). I had been working in low level software engineering before, and used mostly C, assembly, or some weird proprietary interpreted pseudo assembly (that managed to combine the inconvenience of writing assembly codes without the lightning fast execution, but I digress...), and Python for my personal projects.
I decided not to pick Unity because I didn't want to be tied to an engine I would have no control over. I first wanted to go with Pygame because I really love Python, but shipping your game with an onboard Python interpreted is not super convenient, and I had close to zero exemple of released Python commercial game at this time.
Also, the Python <-> C interface is really cumbersome to use.
In order to use moai, I had to learn lua, but I fell in love with it very quickly (except for enumeration starting at 1 instead of zero. It does make sense indeed, but it is a pain to use conventions that go against every standard in programming, including the C conventions, which lua is supposed to interface with).
Writing C routines for speed/memory critical parts was much simpler than in Python.

Interesting. How is Lua better than Python? I don't use Lua often and would consider incorporating it into my workflow if the pros outweigh the cons. I always thought Lua was good for gamedev.

One of the most important points was not mentioned: Lua started its life as a configuration language meant to be embedded in apps written in other languages. So the most typical use case for Lua is that you start your main loop written in C or something, then you execute Lua scripts from there, which in turn make calls to your C API.

With Python it's usually the other way around. Your main program is written in Python and you can write Python modules in C or some other language that you can call from your Python code. It's a general purpose programming language with "batteries included", which means lots of useful libraries included out of the box. But a Python installation is huge. Python 3.9 on my Windows machine measures 156 megs!

So as a scripting language within your app, or as a "glue" language to orchestrate modules written in your low-level host language, Lua is the one to choose in 99% of the cases. It's not only used for games; the most famous non-game example is probably Adobe Ligthroom. The image processing parts are written in C++, and probably some platform-specific OS level stuff, but the whole UI logic and the orchestration of the low level components is written in Lua.

Thanks for the detailed explaination. I'm still new to low-level programming, but I'm not sure as to what scripting languages offer in a program. For example, does a Lua script, as you mentioned its history, read a complicated configuration file and pump it into a usable format for C/C++? I guess it's hard for me to visualize this through text without seeing a simple example.

Scripting languages are usually much simpler to use, faster to debug, and don't require recompiling your program. They typically require much less lines to achieve a similar result, when speed and memory are not an issue. You can even reload the script files after modifications in game, if the engine is built for that.

 

[Rincewind]

Scripting languages are usually much simpler to use, faster to debug, and don't require recompiling your program. They typically require much less lines to achieve a similar result, when speed and memory are not an issue. You can even reload the script files after modifications in game, if the engine is built for that.

While I don't disagree with this in general, I think it's more useful to think of scripting as a "mode of usage", rather than a property of a given language. Languages may use static or dynamic typing, or even a mixture of both; dynamic languages just happen to be used more frequently for scripting (e.g. as in "glue code" in a game) because of the above properties. The Wikipedia article on scripting languages gives a good overview and a more detailed treatment on this.

Having said that, some dynamic languages have been really designed for embedding (e.g. Lua), while others started their lives as general-purpose languages (e.g. Lisp, Scheme, Python). But there's nothing stopping you from writing standalone complex applications in these languages, and that's where things get a bit blurry.