If you can use a GCd language like Go why would you go with Rust(which add a lot of complexity) or Zig(which is unsafe(1)) instead of the numerous existing GCd languages D,Nim, Crystal, Java,... which provides memory safety without complexity
If you can't why evaluate Go instead of Ada or DasBetterC?
1: At work a frequent issue in C++ is UAF a pointer to a stack variable which outlives the function, Zig don't help you here..
In my head it is always said with a German accent.
And yes this got me interested in D. I always knew of its existence but for some reason I never really looked into it.
D is nice. I could see myself picking it instead of go. It's much more expressive than go and it's mature enough. Cross compilation story isn't as great though. Haven't tried asBetterC. I was under the impression this corner of D isn't as mature as D proper.
Java, IMHO, has limited uses, in the sense that making distributable binaries for client side usage (e.g. CLIs) is quite a hassle, and the need for a JRE makes it quite a bit bulkier than a C or go thing.
I'm partial to Nim and Crystal (and V). They aren't as appealing to me personally because they feel complex compared to C and go (and zig). If the appeal of these languages is "a better golang", I think D has beat them to the punch. Also, again, cross compilation tends to be a bit of a deal breaker for me.
Another language that seem interesting in this space is Odin, but I could not for the life of me find stdlib docs for it.
Another seemingly interesting language is Beef, which has a sort of C# feel (a good thing in my books), but unfortunately I haven't had a chance to play around with it yet.
Cosmopolitan is cool, but is just C, and younger than even zig.
Memory leaks are possible in GCd languages and when they happens, sometimes you cannot fix them easily / properly because of architectural problems. Thinking about the lifetime of an object can help with this.
We also still miss something in many languages that specifies whether we can modify or access an object after passing it as a argument to a call, which can can problems not related to memory safety.
(I've played with Rust but I don't practice it daily. I've also played with D but don't practice anymore. I don't know Go.)
Memory leaks in enterprise java in my experience are usually things like forgetting to close a resource of some sort or maybe doing something silly like continually growing a set or map with duplicate objects because of faulty equals() or hashCode(). Both of these cases are well covered by static analysis.
Maybe the trickiest but still relatively common scenario is a design issue where a weak reference is required - i guess that fits parent description pretty well.
Sorry but if this sort of UAF is actually frequent, I would hazard a guess that your coworkers would struggle in pretty much any language? RAII-based lifetime management really isn't that difficult, and the type of bug you are referring to isn't even subtle.
Most surveys place the use of such tooling around 11%, which is why all major OS vendors are pushing for hardware memory tagging, as by then is no way to avoid using them.
Those browsers are part of the 11% mentioned above.
Uh? This issue wouldn't happen in Java because everything is heap(GC) allocated. Which is probably why developers new to C++ have this issue.
Walter Bright said below that the D compiler find most of these issue at compile time, well that's nice for D but unfortunately that isn't the case for C++ at least not for gcc9.
@safe:
int* f(int* p) { return p; }
int* g() { int i; return f(&i); }
dmd test -dip1000
Error: reference to local variable i assigned to non-scope parameter p calling test.f... yet every time time I've been told "you don't need Rust, just use C++", I can point to at least one UAF in their own code, and have even pointed to CVEs on Mitre for their own projects!
People make mistakes. Use tools that stop these mistakes, rather than helping you to "write code faster" like in the article (aka writing bugs faster).
- Implicit lambda capture where you use & (admittedly often out of laziness).
- A string_view constructed from an accidental string copy (e.g. if your function parameter is a const std::string instead of a const std::string&, or if you write for (auto foo : v) { ... }).
- A callback that references some member variables of some object on the stack, which usually completes before the function returns (but maybe you forget to synchronize in an edge case).
Tooling can help identify a number of these issues, but it's not perfect. And a number of these issues are very much C++-specific.
There are plenty of aspects of programming that need systematic solutions instead of just telling people to get better, but returning pointers to the stack should not be high on that list.
If people are doing that, it means they don't understand what they are doing or aren't thinking about what they are writing, probably both. It is much easier to return regular data structures.
In modern C++ it is rare that a raw pointer should be returned in the first place. I wouldn't be sure what to think if I had a team full of people consistently and frequently returning pointers to the stack frame of the function they came from.
I have not run into a case where go can't be within 2x speed of C.
And I love how zig is even closer to C, but has the ergonomics of go.
What an amazing time to be alive.
When I was learning Go years ago, I decided to go through and speed up some of the Benchmark Game's Go code. Some were on the order of 20x speedup if I remember right.
Of course, the maintainer of the site rejected it because of what I perceive as a clear bias against the language, but the point is...it's easy to fix hotspots in Go.
This was in 2013. My first submission was using memory pools for binary trees. It was rejected for using memory pools, even though the C version quite literally used mempool. I even redid it to use a 'third party' mempool library, rejected for the same reason.
I didn't even bother submitting any others.
I hope my assessment is 'fair.' I used to feel more strongly than I do now, I guess.
It's a weird situation. The rules say 'dont write your own memory pools', but new languages wouldn't have a popular library available. Seems it should be 'dont use them at all', or allow them for all. This puts any new language at an immediate disadvantage.
Anyhow, thanks for keeping it going so long. Fun little site.
"Go was born out of frustration with existing languages … To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection …"
https://golang.org/doc/faq#creating_a_new_language
https://golang.org/doc/faq#garbage_collection
Seems like you wished not to show one of Go's big features?
It's pretty clear that Go designers wanted a GC, but also wanted control over memory. In go, it is trivial to create a slice of structs that's contiguous in memory, and built-ins like 'copy' means the language designers wanted users to use this feature.
When I write go, GC is used almost always. Except when it becomes a bottleneck, at which point I trivially switch to memory pools. I just add a comment like "preallocate to avoid allocating in a loop", and move on. The next person that comes by my code would have no trouble understanding what happened there--unlike Java where using memory pools stops looking like Java.
I think when the Go FAQ mentions existing pain points, it means both GC'ed and Non-GC'ed languages.
Zig is cool because it went the manual layout route, but with a pluggable allocator. I think it's a brilliant choice, especially for embedded.
Go is simple, has very fast compile times, produces a single static binary, easy trivial to cross-compile, has very short GC pauses, has a fantastic standard library. The same cannot be said for those other languages.
Rust has a very strong type system that makes lots of runtime errors into compile time errors, it's basically as fast a language as you can get, except for GUIs it has a really good library ecosystem (way better than all the languages you mentioned except maybe Java), it produces a static binary, cross-compilation is relatively easy (as long as you aren't trying to cross compile to Mac).
Zig will probably never be as safe as a GCed language or Rust in this regard. But that's because it would go against other core design goals.
I feel like the future of non-GC languages is Zig as better C (dead simple and explicit language), and Rust as better C++ (complex language with more memory management facilities, etc).
The choice of languages was a bit odd. But I think Go is still in C's territory when it comes to being simple and explicit. Memory management (GC/not-GC) isn't necessarily the most important distinction in programming languages.
I don't care about that in a Python program, but I can't see why I would accept it from something that's supposed to replace C.
I also think you're imagining a lot of hard work during execution in Rust that just isn't there, most of the tricky stuff happens at compile time. If you can prove you really don't need the safety that does have runtime implications, you can choose not to have it, but of course you probably don't have proof, just the same gut instinct that usually gets us into trouble in other languages.
The problem is not in exploits, the problem is in price of people having enough knowledge to not do stupid mistakes and every company wants developer that pays him nothing (or as little as possible) and gets everything or close to it (open source(tm); I want to build a house. I am still searching for an idiot that would make it for "recognition").
And as such they search for most fool proof technology where they could replace expensive and knowledgeable developers with, ideally, street bums that would work for food. And most of the software we are using today is like that: made from street bums.
The difference between 1990s software and today is too obvious to not notice the difference, even the "great breakthroughs" and new hypes are just xeroxing what we already had.
(No offense, doing a fair bit of C work myself)
C, CAN be a bleading edge. Depends on who is using it., based on a simple fact that there is nothing you cant do.
Except for the amount of money the companies need to pay for skilled c/c++ developer against the <name your poison> developer.
I think that in contrast of common belief, the difference in languages has nothing to do with benchmarks. But it has everything to do with price/performance. And performance is not important today (`I'll just start another "cloud" instance whatever the cost`).
So we are getting to the price. 10 monkeys for the price of one "real" developer. Why? I was reluctant to use java/c# software due to a fact that it was mostly a crap (and still is). Now I am forced to use it as there are no alternatives. The software is just another thing where the quality is non relevant to the earning. So we eat shit.
<dont_take_this_too_serious>
I think that most C programmers are just programming monkeys. People who enjoy solving sudokus^H^H^H^H^H^H^H pointer arithmetics and format string riddles and think that incrementing a variable in the middle of a statement is the best thing since sliced bread. Programmers, who do not have the necessary skills to become engineers - the latters needed to build modern systems. I think it's good that languages like C exist, so we can keep those people busy and let the more capable people work on what makes the real difference when it comes to robustness, performance, and integrity: algorithms, data structures, and software architecture. Things that require abstract thinking beyond "Where do I store my pointer so I don't forget to free that struct later?".
</dont_take_this_too_serious>
Sure and I agree. The companies have tried to use the monkeys for C development, but it didn't work. There is just too much to be aware of. All the next goals were to find a technology that would still keep "low" paid monkeys but prevent them doing stupid mistakes and train them as fast as possible to produce some results, whatever the results were.
And we got the winners that we today call java, js, c#, ruby, php, python,... and the devices that are using extremely capable cpus with vast amounts of memory and "diskspace" to produce inferior results.
It is not the point that any of those languages is faster (I love those benchmarks comparing speed of language that is written in c/c++ with c/c++), that any of those is better.
The point is that they allow companies to pay less to the developers for the same effect with a loss on speed, memory and all the other handy dandy things that can be bought on (and dumped to) consumer side.
It was never about speed, memory footprint, syntax. It was always about paying software developer the least amount possible.
And we actually helped, open source(tm) anyone? Or in other words, working for free for no benefit but dubious recognition that no one but ourselves care about?
I wonder what is any other branch of industry that relies so heavily on recognition instead of payment.
As I have mentioned, I want to build a house, please recommend to me anyone prepared to build it for free for "recognition" instead of payment...
... No?... So we are the only ones THAT stupid?
Go brings faster results due to the really great and easy to integrate 3rd party libraries. There is literally no way that I would go for such a large number of third party dependencies with any C++ software - it is just too much work to prepare the libraries for use.
The amount of thinking to make Go programs run fast and with low memory fingerprint is about the same as C++ with a huge minus that you dont have a delete/free keyword that designates "now the memory is de-allocated". With go, you need to think hard, I would prefer GC language that has a deallocation keyword, so I can forget about everything I dont care about but still deallocate what I want in specific moment.
For me personally, the hugest difference of Go against C/C++ is the ecosystem and how simple is to use 3rd party libraries/modules/whatever.