541–550 of 556 posts
Earlier quoted context omitted.
> use exceptions instead of return code for errors I happen to have the exact opposite opinion. Exception handling tends to feel too "magical" (read: non-deterministic, hard to behaviorally predict, etc.) relative to just returning an error code.
> Exception handling tends to feel do you program a lot with your feelings ?
Earlier quoted context omitted.
you would probably like zig, if you haven't given it a look yet.
I feel zig is now experiencing feature creep now too sadly. Async and await and coroutines are being added to it, because it's the new-ish hotness I guess? Stopped paying attention to the language after that. I was hoping for a more streamlined language.
I was strongly resistant to it when it first came out in C# something like 10 years ago. I thought it was language cruft that was better handled with a library solution, and nothing more.
I was convinced to give it a real try about 4 years ago, and had a serious change of heart after only a week or so. It was just syntactic sugar, but it was syntactic sugar that made concurrent code much easier to write. Not just in terms of making the code more verbose, but in terms of making it easier to do correctly. Because, at least in the way the C# team designed it, it subtly steers you towards doing things in smarter and safer ways, and away from the usual hot mess that is multithreading.
I've heard similarly positive things about goroutines, which seem at first blush to be about the same thing.
Given that Zig is ostensibly about helping people to write performant code more safely, that leaves me thinking that there's an argument to be made that async/await are a good fit for Zig's mission, and not just kitchen sink features.
Earlier quoted context omitted.
If they don't already know C though, how well will they cope with manual memory management?
It will be a learning curve, but a much, much smaller one than learning C.
Writing C code is also writing C++ code, but badly.
Earlier quoted context omitted.
> It just seems to mean "this language catches more errors at compile time than the previous language I used." That is a fair interpretation. I've programmed mostly in C# and Java because that's what was required at the time. I also know enough C and C++ to aim at my toes instead of the entire foot. So the comparison is between strongly typed imperative programming languages which are syntactically close to Rust. Als…
"Out of pocket"?
Earlier quoted context omitted.
If you don't know what functions you are passing to third-party libraries, you have a much bigger problem than any language can help you with. Google's proscription on exceptions is purely historical. Once they had a lot of exception-unsafe code, it was too late to change. Now they spend 15-20% of their CPU cycles working around not being able to use RAII.
When you write modern software, most of your executable ends up being third party code for commonly done things, it's both wonderful since you can move fast, and a curse, because you inherit others' bugs. My example with libcurl was very simple, but in real systems, things are less clean. You may be using a network tool that hides libcurl from you, and your code is being passed into a callback without you even knowin…
Instead you call a constructor that sets a dumb default state, and then another, "init()" function, that sets the state to something else, and returns a status result. But first it has to check if it is already init'd, and maybe deinit() first, if so, or maybe fail. Then you check the result of init(), and handle whatever that is, and return some failure. Otherwise, you do some work, and then call deinit(), which has to check if it is init'd, and then clean up.
I knew someone else who worked at Google. 15-20% was his estimate. Bjarne ran experiments and found overheads approaching that.
Earlier quoted context omitted.
I don't. Maybe we're thinking about different kind of caches, but if these are transparent, no-performance-impact caches, then why wouldn't you prove the system works well with caches off (guarantee deadlines are met), then enable caches for opportunistic power gains?
You'd have to very solidly prove that in the wors-case a cache only ever make execution time equal to or faster than a processor not using cache and never causes anything to be slower.
Earlier quoted context omitted.
But things like this would happen, even from acclaimed developers, giving the engine a bad reputation among players: > The frame-rate difficulties found in version 1.01 are further compounded by an issue common with many Unity titles - stuttering and hitching . In Firewatch, this is often caused by the auto-save feature, which can be disabled, but there are plenty of other instances where it pops up on its own while…
If you continue reading that article, they go on to say Unity is not to blame... There's a lot of reasons shipping Unity games is hard but the GC and C# are not among them or at least much lower than, say, dealing with how many aspects of the engine will start to run terribly as soon as an artist checks a random checkbox.
> This refers to the engine's ability to exploit multiple streams of instructions simultaneously. Given the relative lack of power in each of the PS4's CPU cores, this is crucial to obtaining smooth performance. We understand that there are also issues with garbage collection, which is responsible for moving data into and out of memory - something that can also lead to stuttering. When your game concept starts to increase in complexity the things Unity handles automatically may not be sufficient when resources are limited.
Earlier quoted context omitted.
Go has many advantages over C that are not related to GC.
In a context where you don't allocate memory, you lose a lot of those (for instance, you almost cannot use interfaces, because indirect calls cause parameters to those calls to be judged escaping and unconditionally allocated on the heap). Go is a good language for web backend and other network services, but it's not a C replacement.
Earlier quoted context omitted.
Only operator overloading is really important and would cut down the size of code written substantially. Thats the only real advantage of using C++ vs C. Everything else oop, function overloading,RAII,etc can be replaced with macros and structs.
Pretty sure you can't make destructors with macros?