61–70 of 146 posts
Earlier quoted context omitted.
On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.
Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++. For me the big attraction of GC is memory safety not convenience.
Earlier quoted context omitted.
Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…
Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up. Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC. If your language requires a GC, it is a complete failure as a s…
And apparently no one noticed that a part of Bing used Midori for a while.
That is alrigth, according to Midori team, Windows team also did not accept what Midori was capable of, even when proven wrong.
Having a GC is non different than malloc spending all its time doing context switches to reclaim more OS memory, using the actual OS memory management APIs.
It is up to the developers to decided to use a GC based allocation, stack, global memory segment or plain untraced heap allocations.
The tools are there, naturally there is a learning process that many seem unwilling to do.
And by the way, Swift's reference counting implementation gets wiped out by tracing GCs on the ixy paper.
Earlier quoted context omitted.
Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++. For me the big attraction of GC is memory safety not convenience.
Try Rust. Proven memory safety, no GC.
Earlier quoted context omitted.
Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++. For me the big attraction of GC is memory safety not convenience.
Try Rust. Proven memory safety, no GC.
Earlier quoted context omitted.
Rust seems to be the most successful zero-overhead language competitor to C++, though it's far not as mature as C++ yet.
Rust has a high learning curve (borrowing, etc). Rust is a competitor to ADA, not C++. You can certainly ask developers to write things in rust instead, and even progressively rewrite codebase in rust since it's compatible with C++, but a language is about adopters, and ease of learning for beginners and students.
Earlier quoted context omitted.
Sure it is! A reputable CS degree will cover multiple programming languages and compiler implementation. I don’t think you could study just “compilers”, say, at undergrad level. Maybe you mean postgrad or postdoc-level qualifications? It would certainly be a pretty different world if you were only allowed to design a new programming language after getting your PhD in language design.
> Sure it is! A reputable CS degree will cover multiple programming languages and compiler implementation. Which is neither here, nor there. A reputable CS degree is an all rounder, it's not expertise in PL design and research. > I don’t think you could study just “compilers”, say, at undergrad level. Maybe you mean postgrad or postdoc-level qualifications? For starters, yes, but it's not about official qualification…
Pure CS theory tends to be a maths major.
Earlier quoted context omitted.
Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…
Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up. Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC. If your language requires a GC, it is a complete failure as a s…
That's not true. You can pool, you can call GC when needed, you can build incremental GC with bounded times, and so on.
Check stackoverflow - there's plenty of links to papers and real-world examples of fixed-time garbage collectors. Or check google scholar and read papers.
Go has demonstrated a very efficient garbage collector.
Here [1] is one from Oracle for Java.
>If your language requires a GC, it is a complete failure as a systems programming language.
Plenty of OSes are in development and/or researched using managed languages and GC. Singularity [2] is but one example. I suspect in the future that doing memory management by hand will be as obsolete as writing an OS in assembly. The benefits for security, robustness, and productivity will outweigh the costs, just like the benefits for using higher languages to develop in, while slower than hand-tuned assembly, far outweigh the costs.
[1] https://www.oracle.com/a/ocom/docs/oracle-jrockit-real-time-...
[2] https://en.wikipedia.org/wiki/Singularity_(operating_system)
This is why the tools situation in c++ had been so far behind other languages like Java. You have to build a full frontend to even parse the language. They're slowly becoming available via clang now, which is nice.
Visual Studio has had Intellisense since forever, clang-format can enforce style standards, static analyzers these days are amazing, the address sanitizer and valgrind find memory problems easily, etc.
Earlier quoted context omitted.
Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…
Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up. Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC. If your language requires a GC, it is a complete failure as a s…
Realistically, having the option to use a GC is a boon for many applications. Not everything is hard realtime all the time. Some complex applications tend to have a hard realtime part and parts where it doesn't matter. E.g. a CNC machine controller does not need a guaranteed response time for the HMI or G code parser. But it needs to have a tight control loop for the tool movement.
D is a language where the GC is default, but optional. And the compiler can give you a guarantee that code that explicitly opts out does not interact with the GC and -importantly - can't trigger a GC run that way. However, as this was an afterthought, parts of the language need to be disabled when opting out and not a lot of library functionality works with that.
Earlier quoted context omitted.
Plenty did but none took a chunk out the C++ world that thrives on manual memory mgmt.
The C++ world that thrives on manual memory management is usually "C compiled with C++ compilers". The rest of the C++ world has long moved into automatic memory management as best practices.