I'd go with C first. Rust would teach you everything C does and more, but C will lay the foundation in cleaner strokes. This will help you later no matter what language you decide to learn next. C is also in a way the language of the FFI, so you are very likely to need it in the future regardless.

Had a feeling a reply like this was coming. Could you help me understand a bit more about why C would be a better place to start and how it’d lead to me growing my skills in core areas vs something like Rust or C++? I hear about C++ and can’t wrap my head around the benefits of going with something like C that has less features. I recognize I’m asking what will help me grow/learn and am saying, “why use this if x has more niceties?” but hopefully you can humor me. One thing I hear a lot is that Rust is the language for the next few decades, and while I’m sure C isn’t going anywhere, I’d be very curious to hear from someone with more experience about why C would be the way to go here. I’ll admit I’m intrigued as I used to have a professor in college who was a wizard and did everything in C — especially since a game I like from 2001 has an active modding community so long as you know C/ASM.

Explicitly: I’d be curious to know what the “cleaner strokes” are.

I also have never even heard of an FFI so thanks for starting my next research binge! I always thought two langs could interact once they’re both compiled to machine code, but I’m guessing i took that for granted and that C does that heavy lifting..

To list something: C teaches memory management, memory addressing, stacks and heaps, some disassembly, binary interfaces. Basically, you see the layer on top of machine language. Python, Go, etc. are a layer on top of that.

Rust and C++ teach these things as well, but C keeps things minimal so you see the ideas more clearly. A lot of languages are written in C, forming a common way to think about implementation and problems, one you see glimpses of working in almost any other language as well. A lot of "why is it like this" questions have answers beginning "because in C..".

The FFI part is due to the extremely stable and simple ABI. Compiling C produces predictable and known binaries, setting a lowest common denominator among languages (for bettet or for worse). Thus knowing the capabilities and limitations of C is useful even when working with other languages.

A lot of this knowledge can be grasped quickly and you will get reminded of them for the rest of your programming life, so it's not necessary to dive deep into C to get the knowledge. C just provides the shortest and cleanest introduction, and you can quickly move forward without missing a beat really, since a lot of the stuff is so universal.

Thanks for the additional info! Very helpful and I appreciate it greatly.

To be fair I would have read it, but there was no link, as another comments have pointed out as well.

It was mostly a troll article not worth reading - maybe there is a copy on wayback machine

This gives a new spin/explains the tagline on their website as well:

"The game engine you waited for."

Find the kind of system you'd be interested in working on and start building one yourself. For me it was a game engine + an editor for it, but it could be anything you find the motivation to build.

Start with a book or a few texts/tutorials on the subject and begin building. Along the way you'll find the questions and choices involved. Find the answers from the internet or books. This is when I'd recommend some open source projects (not earlier) to see how they solved the specific problems. If you just go into an open-source project you won't have an understanding of the problem, just the answers, so it won't help you nearly as much.

That's a totally different domain, where abstractions are most likely for the better. The bad part is the abstractions at places where they're not wanted e.g. graphics and other high performance systems programming. Abstractions are fine if you can opt out, but don't take away the control from those who need it.

The same fundamental equation applies to both domains: Software engineering hours are expensive and hardware is cheap.

I just ordered a video card with 24 gig of ram. Well, calling it a video card is not quite right as it's a K80 Nvidia HPC cards, but as a software engineer working on a team of 5 computer vision/R&D guys and two software engineers, I can tell you that I do not want to live in a world where I have to fix code written by researchers that's juggling around vram and managing 4,992 threads. I'd much rather have that abstracted and have a clean API that hides the complexity.

And in terms of performance, you do not have to spend many man-days trying to debug some horrendous pile of code brought on by the complexity of exposing every tweakable bit of a architecture in order to exceed the cost of X addition $5000 HPC cards running less performant but far less complex code.

Twitch chat is also running on top of IRC. You can connect to their irc servers and use the twitch chat from your irc client. With limited capabilities I might add (no private messages for one). More info: http://help.twitch.tv/customer/portal/articles/1302780-twitc...

It doesn't really have an effect. I showed it to a friend on the same monitor and we got totally different perceptions.

In my mind C/C++ converts to a certain style of C++ coding popular among competitive programmers for example. You write C style simple code but use the C++ libraries etc. when it best fits the case. Some would call it just the C style C++ which is considered bad and ill-formed in general, but I do find it is an excellent style for certain type of problems.

I would be very interested to see this happen. I'd like to get into RE but don't know where one would begin. Having an example from a modern game might give some nice pointers to start working on the games I play and love right now.

I don't think it is implied. I can't come up with a sentence with the same information and zero implications.

This got downvoted, but I believe the comment is correct. Technically, as stated, the headline does not imply causation. It's like saying "cities with declining crime have declining rates of microsoft internet explorer usage".

That's probably true for most cities. The way I phrased it does not imply causation.

What's the difference between the two sentences? The first one presents a situation where causation seems plausible to us, so we infer it automatically. Whereas, causation seems implausible between crime and IE, so we don't read my sentence as implying causation.

Our brains are wired to automatically see causation if it seems plausible and there's a correlation. I teach the LSAT, and this is one of the topics tested.

Normally, the testmakers go to great lengths to disguise what they're doing. But on causation/correlation questions, they just present the correlation. They know we're so bad at it that the question will fool people without any other special tricks.