this post was submitted on 01 Aug 2024
12 points (100.0% liked)
Chat
7499 readers
116 users here now
Relaxed section for discussion and debate that doesn't fit anywhere else. Whether it's advice, how your week is going, a link that's at the back of your mind, or something like that, it can likely go here.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I've considered C. I do have over a decade of experience with C++. But quite frankly I just need to be productive, so I work in C# these days. The issue is just that C# takes away a lot of control that I need for this project. Especially because I want it to be resource efficient so that it's sustainable and doesn't hog people's private server resources.
Personally I'm just a hobbiest, I'm not really fluent in anything. I want to hack together a (extremely simple) OS. I'd imagine C++ is close to the effiency of Rust, no?
C++ is a superset of c, and isn't inherently slower. It just has a ton of bells and whistles that were trendy in the 90s such as OOP abstractions.
You could say that a c++ amateur programmer will tend to write more resource intensive code than an amateur c programmer due to wanting to use the abstractions.
Take for instance a level with 10k animals in it such as ducks and dogs. Ducks and dogs have their own Update implementation. A world Update function has to update all the animals.
In c++ you will naturally be inclined to use polymorphism by creating an animal class and letting the duck and the dog classes inherit from it. You have a single list with 10k animals. The duck and dog classes override the animal's Update method with their own implementation. The world Update function uses a loop to call the Update method on all 10k animals.
What you might not realize is that under the hood the computer has to do a lookup in a function table for each animal. Both the duck and the dog classes have their own virtual tables that the CPU has to go through to find the actual implementation of their respective Update function.
Now in C, you'd be inclined to simply create two separate sets, one for dogs and one for ducks. You'd loop over each one individually.
There are no lookups for the CPU to do here. It just applies the same Update function to a large set of structured dog or duck data.
Now, the performance impact won't matter in most cases. You could even write it in python and it'll be way slower but at least your code will be readable. But now imagine 10mln or 10bln animals. It's going to make a difference.
Rust on the other hand is in the same class of performance as C.
Hence, as you want to write a back-end that's scalable and readable, you've chosen rust over C++.
Such an in-depth response!
What's your opinion of Dave Plummer's speed test? I was surprized that assembly wasn't the fastest of his tests. It really says how amazing compiling has become.
This is the Github project: https://github.com/PlummersSoftwareLLC/Primes
This is the video playlist he made based on that project: https://piped.video/playlist?list=PLF2KJ6Gy3cZ5Er-1eF9fN1Hgw_xkoD9V1
That's pretty cool. Feel sorry for the guy since he mentioned his history with DOS (Dirty Operating System).
What makes you interested in performance rn?
Also, I'd never have considered c++ for my project, but rather c. I find OOP abstractions to waste my mental space to no benefit.
And sure, I'd say rust is more readable than c. The author was clearly thoughtful across the board. It's simply more modern in its thinking.
Regarding scalability I'd say that rust makes concurrency simpler than c. Back in the day computers were single core and making huge strides there. It wasn't until the 2000s that we hit a ceiling and had to go wide with multiple cores and smart with prediction and larger caches and so on.
Feel free to ask anything.
I don't have any good reason to be interested in performance. That being said, I tend to view inefficient languages- Python and Javascript especially- as "less good." Granted, python's ability to be built on top of C libraries is a huge saving grace. Javascript should be replaced by WebASM in IMO. Like you said, the inefficiencies add up as the scale gets larger.
As a disclaimer, I could be swayed to like Javascript. I haven't been challanged on my view yet.
I'd like to go into embedded programming which is why I'm interested in C and OS dev. Most of the tooling we have (as an internet) is still built for C. I know they're starting to write parts of the Linux kernel in Rust. How is Rust for that kind of development?
Well it sounds like you're serious about it. I'd always recommend focusing on where your passion lies. If that's embedded then c and rust are solid choices.
Just always be aware of what motivates you. Adjust your plan as you go. Find the balance between boring and frustrating. Did you know that the guy behind Google earth is a gardener now? That's totally fine.
I'm just saying don't torture yourself with your own fantasies, but always remain skeptical and cut cut cut. Choose consciously and then commit your full energy.
The only failure is to go against your own nature. Managing your motivation is way more important than optimizing performance. You can always refractor anyway.
That being said if you want to be thorough I'd recommend you start at c with a side of assembly. Stick to that until you feel comfortable and then move on into rust.
When switching you'll probably want to start from scratch because you've improved your design so much. You can always port it too or link it as a library. Don't worry about that right now, that's a future you problem.
I actually really appreciate your comments about motivation, it's one of the things programmers don't tend to mention on the web. I definitely see my motivation wax and wain. I have my fantastic dream's that get the better of me too. I guess we can't all be a Torvalds. 🤷♂️
Well, sure, you can only be yourself! You have qualities that torvalds doesn't have.