8 ms·

What I find funny is his choice of languages: 'hipe driven' I'd say. If you can use a GCd language like Go why would you go with Rust(which add a lot of comple

by renox 6y ago

What I find funny is his choice of languages: 'hipe driven' I'd say. 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..

banachtarski 6y ago
> 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.. 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.
- jchw 6y ago
  I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
  - WalterBright 6y ago
    D is very good at detecting dangling pointers into the stack at compile time.
  - saagarjha 6y ago
    Usually I think tooling is fairly good at catching these; I feel like misuse of dynamic memory allocation is usually harder to catch these days.
    - pjmlp 6y ago
      Provided developers actually bother to use it. 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.
      - saagarjha 6y ago
        All three of the web browser engines are extremely heavy users of these tools; actually they are often the ones that develop and contribute to them.
        pjmlp 6y ago
        A negligible amount of source code when placed against the amount of C , C++ and Objective-C written daily across the globe. Those browsers are part of the 11% mentioned above.
  - malf 6y ago
    They’re talking specifically of pointers to the stack.
- renox 6y ago
  >I would hazard a guess that your coworkers would struggle in pretty much any language? 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.
  - WalterBright 6y ago
    Doing what D does to detect references to expired stack frames would require some restructuring of C++'s semantics, which seems unlikely. For example, D can detect this error: @safe: int* f(int* p) { return p; } int* g() { int i; return f(&i); } Compile with: dmd test -dip1000 and the result: Error: reference to local variable i assigned to non-scope parameter p calling test.f
    - scatters 6y ago
      At -O2 or above, gcc emits Wreturn-local-addr.
      - mlyle 6y ago
        Within a single compilation unit, and only in this most trivial case.
        WalterBright 6y ago
        Here's an example of a much more complex case that is detected: https://issues.dlang.org/show_bug.cgi?id=21745 https://issues.dlang.org/show_bug.cgi?id=21745
        mlyle 6y ago
        Yes, sorry if my comment isn't clear. D is very capable in this regard. While gcc with C/C++ code will spot a few trivial cases... including the one in the example above.
- viraptor 6y ago
  If you can make some mistake, it's only a matter of time until someone will make it. This scales with the codebase size. And you only need one person to make the mistake and another to miss it in review - it doesn't matter if everyone else is a 40 years of experience coder.
  - alfiedotwtf 6y ago
    "Nobody would write that type of code, and if they did, you should just get better programmers" is such a common theme in these discussions. ... 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).
    - bluejekyll 6y ago
      “If debugging is the process of removing bugs, then programming must be the process of putting them in.” -- Dykstra's Observation
- vitus 6y ago
  I disagree, as there are lots of ways it can manifest in C++. To list a few examples: - 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.
- CyberDildonics 6y ago
  I agree and don't understand why this would be controversial. 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.
  - renox 6y ago
    It doesn’t happen very often but each time there was a new developer on the team they made such mistake, that’s a way to teach them about valgrind (what a wonderful software!) I guess. We work in a ‘low latency’ domain where heap allocation is avoided, this may explain that it happens more often to us.
    - CyberDildonics 6y ago
      Why would avoiding heap allocation explain it? Why is anyone getting the address of a stack allocated variable in the first place since it already in scope? What are people returning pointers from functions at all?
makapuf 6y ago
Had to look it up, DasBetterC is not german, it's "D as a better C"
- ruph123 6y ago
  Lol thank you for that. I thought that was a joke language like Enterprise.
- WalterBright 6y ago
  I originally wrote a slide titled "D as Better C", and since I was in München at the time, it suddenly morphed into "Das Better C" and so the pun was born. In my head it is always said with a German accent.
  - ksec 6y ago
    If I was the marketing manager of D I would turned this "pun" into Super Hype. And yes this got me interested in D. I always knew of its existence but for some reason I never really looked into it.
    - throwaway316943 6y ago
      Try it out, I’m thoroughly enjoying learning it at the moment and it really does feel like “better C”. The only thing I dislike is that the official docs are so thorough that they’re not very approachable to a novice (but much appreciated once you grok D’s features). I’ve found this book to be a better programmer’s introduction with lots of useful examples https://www.packtpub.com/product/d-cookbook/9781783287215 https://www.packtpub.com/product/d-cookbook/9781783287215
- qart 6y ago
  In German, it would have been besser, not better.
  - acka 6y ago
    It wasn't aiming for correct spelling, nor correct grammar for that matter. Rather, I think one can compare it to something like "Das Keyboard"[0]. [0] https://en.wikipedia.org/wiki/Das_Keyboard https://en.wikipedia.org/wiki/Das_Keyboard
jraph 6y ago
> If you can use a GCd language like Go why would you go with Rust 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.)
- a3n 6y ago
  Is there a nice idiom name that represents ensuring that an object gets "released" and eligible for garbage collection?
  - CraigJPerry 6y ago
    Memory leaks in Java are usually not so bad to fix. Maybe some off-heap scenarios could be trickier but IME people are pretty careful if they’re going to the extremes of off-heap. 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.
  - varjag 6y ago
    resource management
- deleted 6y ago
  [deleted]
IshKebab 6y ago
Because you're ignoring a lot of other reasons to use Go or Rust. 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).
drran 6y ago
I have here program in Go and in Rust. They are very similar (Rust program is shorter), but Rust version is 5x faster than Go version.
- simpleguitar 6y ago
  I bet you are allocating/deallocating something in a loop. Give the Go profiler a whirl. I bet it will be pretty easy to remove, too. 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.
  - axaxs 6y ago
    That's what I was thinking. 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.
    - drran 6y ago
      My contributions to Benchmark Game for Rust are accepted. ;-)
    - gher-shyu3i 6y ago
      Can you link to the bitbucket pull requests?
      - axaxs 6y ago
        Which repo? If it has a full history, perhaps I could find it? I have a link, but it's dead now... http://benchmarksgame.alioth.debian.org/u32/program.php?test=binarytrees&lang=go&id=6 http://benchmarksgame.alioth.debian.org/u32/program.php?test... 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.
cb321 6y ago
An attempt in Nim [1]. Something like 7 minutes, but yeah..this is even more crazy dependent upon dev familiarity with the target language/stdlib and their IDE/editor (aka unscientific) than the usual attempted measurements. [1] https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap
bluecalm 6y ago
GCed language style just seem so messy to me. I like manual memory management. It forces you to think about lifetimes and encourages better design. Does an object persist or is it temporary? Maybe it's a good idea to have well defined state. GC languages encourage lousy thinking and design. GC pauses are still a thing as well.
- gameswithgo 6y ago
  There are a lot of sweeping unsubstantiated assertions here, and unclearly defined ideas. What is lousy thinking and design? What are the practical downsides of it in the program? Given how many exploits are caused by memory mistakes in C and C++, maybe using those is actually the lousy thinking?
  - stiray 6y ago
    This is irrelevant, if you give F1 racing car to an enthusiastic casual driver, you will get a wracked car and few dead in matter of hours. And should I remember you how many exploits we had due to simple sql injection? The last buffer overrun, stack overflow, that I did was like 5 years back and wasn't remotely exploitable. But I agree that not making stupid mistakes takes years to master (in my case 20+). 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.
    - varjag 6y ago
      Formula 1 is on the bleeding edge of technology, which C is resolutely not. If you're really into car analogies a better one would be racing a Ford T, which is indeed just as unsafe. (No offense, doing a fair bit of C work myself)
gameswithgo 6y ago
The whole point of his experiment was to learn about the ergonomics of these languages, to investigate the hype. If you did the experiment and say, found that Rust was super easy, then you could avoid GC and get some free efficiency. If you found that Rust was hard, then you know only to use it when you NEED the efficiency.
lhorie 6y ago
I'm not the OP, but could try to venture an answer as someone who's used some of those languages. 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.
dnautics 6y ago
I belive the "no outlasting pointers to stack variables" is a very hard problem but it is in the Zig issues list and it will probably be worked on: https://github.com/ziglang/zig/issues/5725 https://github.com/ziglang/zig/issues/5725
audunw 6y ago
It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer. But it might be a model where you focus on detecting errors in debug/safe-builds during development, but release fast builds using less safe code generation and allocators. 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.
- tialaramex 6y ago
  What would "simple and explicit" even mean if somehow it includes "Oh, sometimes, maybe, I'll incur the expense of garbage collection in the middle of this other algorithm running and it'll take much longer than usual" ? 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.

by renox 6y ago

banachtarski 6y ago

> 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.. 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.

jchw 6y ago
I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
- WalterBright 6y ago
  D is very good at detecting dangling pointers into the stack at compile time.
- saagarjha 6y ago
  Usually I think tooling is fairly good at catching these; I feel like misuse of dynamic memory allocation is usually harder to catch these days.
  - pjmlp 6y ago
    Provided developers actually bother to use it. 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.
    - saagarjha 6y ago
      All three of the web browser engines are extremely heavy users of these tools; actually they are often the ones that develop and contribute to them.
      - pjmlp 6y ago
        A negligible amount of source code when placed against the amount of C , C++ and Objective-C written daily across the globe. Those browsers are part of the 11% mentioned above.
- malf 6y ago
  They’re talking specifically of pointers to the stack.
renox 6y ago
>I would hazard a guess that your coworkers would struggle in pretty much any language? 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.
- WalterBright 6y ago
  Doing what D does to detect references to expired stack frames would require some restructuring of C++'s semantics, which seems unlikely. For example, D can detect this error: @safe: int* f(int* p) { return p; } int* g() { int i; return f(&i); } Compile with: dmd test -dip1000 and the result: Error: reference to local variable i assigned to non-scope parameter p calling test.f
  - scatters 6y ago
    At -O2 or above, gcc emits Wreturn-local-addr.
    - mlyle 6y ago
      Within a single compilation unit, and only in this most trivial case.
      - WalterBright 6y ago
        Here's an example of a much more complex case that is detected: https://issues.dlang.org/show_bug.cgi?id=21745 https://issues.dlang.org/show_bug.cgi?id=21745
        mlyle 6y ago
        Yes, sorry if my comment isn't clear. D is very capable in this regard. While gcc with C/C++ code will spot a few trivial cases... including the one in the example above.
viraptor 6y ago
If you can make some mistake, it's only a matter of time until someone will make it. This scales with the codebase size. And you only need one person to make the mistake and another to miss it in review - it doesn't matter if everyone else is a 40 years of experience coder.
- alfiedotwtf 6y ago
  "Nobody would write that type of code, and if they did, you should just get better programmers" is such a common theme in these discussions. ... 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).
  - bluejekyll 6y ago
    “If debugging is the process of removing bugs, then programming must be the process of putting them in.” -- Dykstra's Observation
vitus 6y ago
I disagree, as there are lots of ways it can manifest in C++. To list a few examples: - 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.
CyberDildonics 6y ago
I agree and don't understand why this would be controversial. 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.
- renox 6y ago
  It doesn’t happen very often but each time there was a new developer on the team they made such mistake, that’s a way to teach them about valgrind (what a wonderful software!) I guess. We work in a ‘low latency’ domain where heap allocation is avoided, this may explain that it happens more often to us.
  - CyberDildonics 6y ago
    Why would avoiding heap allocation explain it? Why is anyone getting the address of a stack allocated variable in the first place since it already in scope? What are people returning pointers from functions at all?

makapuf 6y ago

Had to look it up, DasBetterC is not german, it's "D as a better C"

ruph123 6y ago
Lol thank you for that. I thought that was a joke language like Enterprise.
WalterBright 6y ago
I originally wrote a slide titled "D as Better C", and since I was in München at the time, it suddenly morphed into "Das Better C" and so the pun was born. In my head it is always said with a German accent.
- ksec 6y ago
  If I was the marketing manager of D I would turned this "pun" into Super Hype. And yes this got me interested in D. I always knew of its existence but for some reason I never really looked into it.
  - throwaway316943 6y ago
    Try it out, I’m thoroughly enjoying learning it at the moment and it really does feel like “better C”. The only thing I dislike is that the official docs are so thorough that they’re not very approachable to a novice (but much appreciated once you grok D’s features). I’ve found this book to be a better programmer’s introduction with lots of useful examples https://www.packtpub.com/product/d-cookbook/9781783287215 https://www.packtpub.com/product/d-cookbook/9781783287215
qart 6y ago
In German, it would have been besser, not better.
- acka 6y ago
  It wasn't aiming for correct spelling, nor correct grammar for that matter. Rather, I think one can compare it to something like "Das Keyboard"[0]. [0] https://en.wikipedia.org/wiki/Das_Keyboard https://en.wikipedia.org/wiki/Das_Keyboard

jraph 6y ago

> If you can use a GCd language like Go why would you go with Rust 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.)

a3n 6y ago
Is there a nice idiom name that represents ensuring that an object gets "released" and eligible for garbage collection?
- CraigJPerry 6y ago
  Memory leaks in Java are usually not so bad to fix. Maybe some off-heap scenarios could be trickier but IME people are pretty careful if they’re going to the extremes of off-heap. 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.
- varjag 6y ago
  resource management
deleted 6y ago
[deleted]

IshKebab 6y ago

Because you're ignoring a lot of other reasons to use Go or Rust. 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).

drran 6y ago

I have here program in Go and in Rust. They are very similar (Rust program is shorter), but Rust version is 5x faster than Go version.

simpleguitar 6y ago
I bet you are allocating/deallocating something in a loop. Give the Go profiler a whirl. I bet it will be pretty easy to remove, too. 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.
- axaxs 6y ago
  That's what I was thinking. 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.
  - drran 6y ago
    My contributions to Benchmark Game for Rust are accepted. ;-)
  - gher-shyu3i 6y ago
    Can you link to the bitbucket pull requests?
    - axaxs 6y ago
      Which repo? If it has a full history, perhaps I could find it? I have a link, but it's dead now... http://benchmarksgame.alioth.debian.org/u32/program.php?test=binarytrees&lang=go&id=6 http://benchmarksgame.alioth.debian.org/u32/program.php?test... 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.

cb321 6y ago

An attempt in Nim [1]. Something like 7 minutes, but yeah..this is even more crazy dependent upon dev familiarity with the target language/stdlib and their IDE/editor (aka unscientific) than the usual attempted measurements. [1] https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap

bluecalm 6y ago

GCed language style just seem so messy to me. I like manual memory management. It forces you to think about lifetimes and encourages better design. Does an object persist or is it temporary? Maybe it's a good idea to have well defined state. GC languages encourage lousy thinking and design. GC pauses are still a thing as well.

gameswithgo 6y ago
There are a lot of sweeping unsubstantiated assertions here, and unclearly defined ideas. What is lousy thinking and design? What are the practical downsides of it in the program? Given how many exploits are caused by memory mistakes in C and C++, maybe using those is actually the lousy thinking?
- stiray 6y ago
  This is irrelevant, if you give F1 racing car to an enthusiastic casual driver, you will get a wracked car and few dead in matter of hours. And should I remember you how many exploits we had due to simple sql injection? The last buffer overrun, stack overflow, that I did was like 5 years back and wasn't remotely exploitable. But I agree that not making stupid mistakes takes years to master (in my case 20+). 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.
  - varjag 6y ago
    Formula 1 is on the bleeding edge of technology, which C is resolutely not. If you're really into car analogies a better one would be racing a Ford T, which is indeed just as unsafe. (No offense, doing a fair bit of C work myself)

gameswithgo 6y ago

The whole point of his experiment was to learn about the ergonomics of these languages, to investigate the hype. If you did the experiment and say, found that Rust was super easy, then you could avoid GC and get some free efficiency. If you found that Rust was hard, then you know only to use it when you NEED the efficiency.

lhorie 6y ago

I'm not the OP, but could try to venture an answer as someone who's used some of those languages. 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.

dnautics 6y ago

I belive the "no outlasting pointers to stack variables" is a very hard problem but it is in the Zig issues list and it will probably be worked on: https://github.com/ziglang/zig/issues/5725 https://github.com/ziglang/zig/issues/5725

audunw 6y ago

It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer. But it might be a model where you focus on detecting errors in debug/safe-builds during development, but release fast builds using less safe code generation and allocators. 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.

tialaramex 6y ago
What would "simple and explicit" even mean if somehow it includes "Oh, sometimes, maybe, I'll incur the expense of garbage collection in the middle of this other algorithm running and it'll take much longer than usual" ? 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.