51–60 of 556 posts
So... essentially "I know and like C". Which is great! But as you say, that's not particularly useful for anybody else.
The guy should try Rust and then explain why he prefers either, that would be interesting.
Earlier quoted context omitted.
SDS is a safe, leak-proof C string implementation. Obviously you can misuse anything, but SDS is easy to use correctly. It's robust enough for Redis. https://github.com/antirez/sds
It's considered horrendous practice to typedef to a pointer of something. Not sure why this can be considered easy.
The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a…
> there are simple ways to avoid shooting yourself in the feet with those A cursory look at the CVE list for any C software in the wild indicates that no, there are not simple ways to avoid shooting yourself in the feet with manual memory management in C. It's _incredibly hard_ even for "elite" programmers who have a lot of incentive to avoid these problems. The counterpoint is that people are probably going to spend…
> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…
Quote: "I want to produce less bugs, so I want strict typing, strong warning messages and static code analysis". Yeah, at strict typing you lost me buddy. Let's just go with somebody else reply, as in you like C and that's why you do your hobbies in. Nothing wrong with that in the end.
Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does pre…
> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…
> All my solo project games I've been making recently have been written in 'vanilla' C.
The author is talking about solo projects, not big projects where dozens of teams may be collaborating. It is good that he makes the point at the beginning.
> Nobody does this.
This is just not true. There are solo projects developed in Python, Go, even Commodore 64 assembly. When you do something for fun, you can have as much fun with it as you want.
> It would be nice to make things for the web, but it feels like a terrifyingly fast moving enviroment.
The author should look into Emscripten. It is widely used in the games industry that aims for the web.
> C++ ... It is also slow to compile compared to C.
Probably an important point. You need very good practices to make C++ compile fast. Most people don't follow them as adds complexity to the project.
> Haxe feels much more promising than most alternatives.
Haxe is kind of Object-Oriented and like C++. So, I do not see the point after bashing C++'s OOP so badly. For me, the problem is that it transpiles to another languages. So, when something fails does it in code that you didn't write but the Haxe did. This makes debugging harder that it already is.
> Some people just say screw it, I'll write my own language, the language I want to use. I admire this, and sometimes I toy with the idea of doing the same.
Yep. Something possible for your own fun. Not a good idea when developing commercially. It makes sense for him to choose one language for commercial projects and another, or even create his own, in his spare time.
> It can be made to run on just about anything. Usually this is relatively easy. It is hard to imagine a time when this won't be the case.
This is the big advantage of C. If doesn't run C, probably it just doesn't run at all.
> I absolutely DO NOT mean to say "hey, you should use C too"
For solo projects is a giver that each developer should use the best-suited tools for the task and their abilities and preferences.
I, personally, like C++. I have developed big and small projects in C++ and for me comes natural to write object oriented code. For big projects I see advantatges in being more rigid than C. The extra rigidity makes more difficult that there is unexpected funky stuff happening. So, it is easier to use for teams that maybe situated in different countries. For a solo project, you do not need that rigidity as you know how your own code works.
The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a…
Excuse my C/C++ ignorance, but why not simply use C?
> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…
Edit: specifics from https://blog.golang.org/ismmkeynote - Go hugely improved GC latency from 300ms before version 1.5, down to 30ms, then again down to well under 1ms but usually 100-200us for the stop the world pause. So I guess it is stop the world but the pauses seem ridiculously small to me. They guarantee less than 500 microseconds "or report a but", which seems more than fast enough for game framerates (16ms for 60Hz frames). Am I missing something?
> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…
Most times it may run in 200 micro-seconds, but the one time it takes 20ms the user suffers from unacceptable stutter.
I can see how people would want to bypass the problem entirely by being a bit more careful up front.