12 ms·

Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area. May

Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area. Maybe I'm the rain man of bit-twiddling? What has caused me tremendous grief are all of the inconsistencies in the compilers, the gotchas of the precompiler, and the ambiguities in the language itself. C++ is even worse. Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop). I think an iterative tightening of the language would be of greater utility to everyday computing than a rush to re-do everything in something "better."

faragon 10y ago
Also, there is the risk of re-doing everything and getting worse results: e.g. executable/library bloat, code harder to read/understand, interoperability/binding issues, etc.
- k__ 10y ago
  At least Rust allows to write drop-in replacements.
  - faragon 10y ago
    Theoretically, yes. In practice, you'll get "Frankensteins" with multi-platform compatibility issues.
psyc 10y ago
I agree with you. I've been a C and C++ programmer for decades, and nothing to do with memory safety or leaks has ever risen to the level of prohibitive or even annoying. Ironically, I've had infinitely more grief from fighting hostile garbage collectors, but that's because I'm a game programmer. I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have. I'm always met with strawman arguments about how I can't possibly write "correct" code. It's a strawman because I don't claim to write correct code. I don't care if Herb Sutter can find 1000 "bugs" in my C++. I care that my users and myself are happy.
- jstewartmobile 10y ago
  Sometimes you have to wonder if these admonitions from industry trendsetters are really just sneaky tricks to slow the rest of us down... "Hey, that C++ code that's been working for years? All wrong! Go rewrite it in Node.js. No, no, no, in Go this time. Now Rust!" ...
  - pdimitar 10y ago
    I absolutely don't disagree with both of you. That being said, I've been knowing game developers for years and while I don't know their exact complaints, they kept saying they wished they were working with something else than C++. I think it's mostly solving the same problems many times over and over, during their entire career.
    - deleted 10y ago
      [deleted]
    - psyc 10y ago
      I do wish I was working with something else. Something I'm still surprised doesn't exist yet. I understand the reason it doesn't exist is that a cherry-picked subset of C++ is good enough. This hypothetical language would be a greatly simplified C++ with a couple dozen small annoyances smoothed over.
      - pdimitar 10y ago
        Absolutely. I'd be delighted to code in a simplified C++.
      - buserror 10y ago
        Well, you CAN do simplified C++. Apple even had their own version of it called 'Embedded C++' (the drivers in OSX are like that) -- basically, remove RTTI, exceptions, templating and a few other bits and you get a C with namespacing, objects, nice context-based stack based objects and a few other nice things, without the bloat. So, yes technically you CAN write nice lightweight C++; but you won't be able to enforce it in a team, as everyone will need 'their' pet feature of doom to bring back the bloat. How do I know? Well, I tried for years to do it like that; and eventually I had to give up. Now I do plain C, because it can't be corrupted in the same way. "But, but, I just #included <vector>!!" "... What, for a 5 byte constant array?" "Yeah I know, but the compiler will just inline it!"
pdimitar 10y ago
IMO it's yes and no. YES: Because you're right. Small more iterative changes in terms of tightening up the language to allow for more predictable software (and environment like the kernel) can get us a long way ahead. NO: Because even though you're very correct, there comes a point in any software stack where the expenses of rewriting the whole thing are vastly smaller than the expenses of iteratively reworking it. I have drifted away from C/C++ a long time ago -- around 10 years. I personally got sick and tired of per-compiler quirks, different precompiler policies, and writing sed scripts to fix messed up preprocessed files, to name only 3 generic problems. IMO I believe if something between Golang and Rust comes along and brings only their positives to the table, it'll be very worth to rewrite (or make richer version of) a huge amount of legacy tools in them -- especially if they bring extremely easy cross-compiling and strong runtime guarantees. I don't know enough to claim either way but in my eyes C has been around for a very long time and a good chunk of the complaints are still in place. I'm tempted to think the community had its chance and that it's time something [somewhat] better must replace it.
- jstewartmobile 10y ago
  In the commercial space, devs already have to rework their apps frequently to handle the curve-balls MS/Apple/Google etc. throw at them. If we had a C compiler with webkit-level dominance, and we made just one fix to it every cycle, that would be a big thing, and it would be manageable! It's like, "Oh, to be C-2016 compliant I've got to get rid of all my calls to unsafe string functions." Search, replace, and some elbow-grease later, and I've improved my program with a much lower likelihood of breaking functionality.
  - pdimitar 10y ago
    Since I am no longer heavily invested in the C/C++ stack I have no choice but to agree with you. My general point is that IMO the tech giants' patience towards C's persistent problems is long over and that's why we have Golang, Swift, Rust etc. Don't crucify me for the "persistent problems" thing please. ;) I fully understand the need for a language as close to the bare metal hardware as possible but many people -- me included -- prefer a more stable and predictable environment with the price of less speed. I believe there's no right or wrong side in this particular preference.
Keyframe 10y ago
Whenever C gets brought up, people are like, "pointers... memory... dangerous!" That's actually the point. It's even coded into C2x charter ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm ): The new spirit of C can be summarized in phrases like: (a) Trust the programmer. (b) Don't prevent the programmer from doing what needs to be done. (c) Keep the language small and simple. (d) Provide only one way to do an operation. (e) Make it fast, even if it is not guaranteed to be portable. (f) Make support for safety and security demonstrable.
- loup-vaillant 10y ago
  (f) Does this mean they'll remove some undefined behaviour? Or at least mandates options to that effect? That would be marvellous.
  - wangchow 10y ago
    I tend to read undefined as don't do it
    - syncsynchalt 10y ago
      It's not always possible / feasible to avoid undefined operations. Use the modulo operator? Undefined unless you checked for negative first. Add two integers? Undefined unless you check for overflow. Granted those examples get a pass because on modern two-complement architectures everything handles the undefined behavior in an identical way.
      - loup-vaillant 10y ago
        I believe the modulo operator is implementation defined. As should be signed integer overflow, though it isn't. One big problem about "undefined" is, when some platform go bananas over some stuff, the behaviour is standardised as undefined for all platforms, allowing the compilers to go bananas. Which they do, because every bit of undefined helps them perform some micro-optimization they couldn't do before. I long for the day where the standard forces compilers to provide options such as -fwrap or -fno-strict on platforms that can reasonably support it.
willtim 10y ago
From a security perspective, C is inadequate. This is the biggest issue facing our use of the language currently.
- jstewartmobile 10y ago
  From a security perspective, if you think C is inadequate, try taking a look at the instruction set docs for one of Intel or AMD's semi-modern chips. ;-)
  - yxhuvud 10y ago
    That is not an excuse. Defence in depth is a thing.
    - jstewartmobile 10y ago
      If you're building on a sinkhole, I don't see how having really nice floors helps.
      - platz 10y ago
        I don't see how the chip's 'sinkhole' enabled bugs like heartbleed, which was industry-scale, which absolutely could've been prevented by having a really nice floor.
      - jstewartmobile 10y ago
        You can fix heartbleed--even in C. You can't fix TPM hacks, rowhammer, etc. without buying a new machine. That's not even getting into the potential of the missteps in the RMM / MMU / SMP / virt systems that exasperate even Torvalds and deRaadt.
        sitkack 10y ago
        You are making an all or none fallacy. While those things do exist, we can't use them as an excuse to prevent the common case.
sbov 10y ago
How do you define problem? In terms of consequences or mere presence of a bug? If it's consequences, is it plausible that you have had no problems because not enough people are interested in attacking your code? If you say you have never produced a memory/pointer related bug that got past you, then you probably are the rain man.
- jstewartmobile 10y ago
  I mean that through strict valgrind and fuzzers, I've never had it find anything in my own code. I've also never had a hard-crash from anything in my own code. I attribute this to personal paranoia about input and indices. Worst experiences I've had in that domain were due to inconsistencies in things like the Win32 API across different OS versions that were allegedly supposed to behave the same way. Sometimes I think better API and language documentation would improve programs more than better languages.
  - geofft 10y ago
    Wouldn't you prefer to have the computer deal with the personal paranoia for you? I love C dearly, but I can write so much faster in, say, Python, and that code is usually production-suitable. If I say "for line in open(sys.argv[1])", I don't have to spend 50 lines dealing with open() failing, or sys.argv() being the wrong length, or allocating a buffer to read into and recombining lines longer than the buffer, or whatever. Ideally in Python I'd print better error messages, but it's fine if I forget; Python will take care of each of those problems and do something safe, if not user-friendly. If I forget any of those in C, it's emphatically not fine. Rust - and many other higher-level compiled languages! - promise to bring that development speed and confidence back to the domains where C dominates.
    - jstewartmobile 10y ago
      I do prefer it, and for new things, I love Rust and Golang and Clojure. I even kind-of like Python (aside from the blocks-by-indentation thing). I'm just saying that for old things, staying the course will probably be more fruitful than fresh start in a different language.
pavlov 10y ago
I always felt that Objective-C was a great take on a "better C"... Definitely not conceptually better in the ways that Rust is, but simply better for a lot of the practical things where C suffers the worst. Obj-C was an appealingly simple extension to C from the compiler point of view, but for a long time it was hobbled by the runtime/framework situation, as the NeXT/Apple runtime wasn't open source. Just as that compatibility hurdle was getting fixed by open source efforts around 10 years ago, the iPhone happened and Apple went nuts with extensions to the language... It used to be that Objective-C proponents would brag that you can learn the syntax in 5 minutes if you know C. Now the language is filled with uncountable double-underscored keyword warts and @ declarations. Today's Obj-C looks more like an intermediate format for a Swift->C compiler rather than an evolution of Obj-C 1.0. I understand completely why that happened. I just wish that Obj-C had gained more of an open source foothold when the opportunity was there, so it wouldn't have been so dependent on Apple's stewardship which eventually killed it as an independent language.
- eschaton 10y ago
  The NeXT/Apple Objective-C runtime has been Open Source since the late 1990s, the API and ABI have been documented since the late 1980s so anyone could create a compatible runtime, and GCC has had a portable runtime almost since Objective-C was taken into its mainline.
- favorited 10y ago
  I can agree about the nullability annotations & generics additions, but having properties, ARC, & blocks made writing Objective-C programs so much nicer, IMO.
- mpweiher 10y ago
  Hear hear! And then I watch something like Gary Bernhard's "Boundaries" talk[1], which isn't bad, mind you, and think "maybe this Brad Cox guy with his Software ICs really knew what he was talking about?" Where Apple went off the rails with Objective-C was trying to make it into an OO language like Java. It isn't. It is a deliberate hybrid, with a component implementation language ("C") married to a component connection language ("Objective"). My own approach is to take this distinction seriously, and instead of doubling down on the "better Java" part like Swift does (which in Software-IC terms is focusing on the less interesting and mostly solved component implementation part) and instead expand on the ways we can connect components (dataflow, constraints, storage composition, etc.).[2] Minor correction: GNUStep, libFoundation etc. happened around 20 years ago, not 10. [1] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [2] http://objective.st/ http://objective.st/
stymaar 10y ago
> Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop). I agree with that, and most people do even in the Rust community. I don't expect people to rewrite their software in Rust, but if people could stop writing new C code[1], the world would become a better place in the next decades … > Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area. In 20+ years of C, you never faced a single segfault ?! I'm sorry but I don't trust you. You're basically pretending being the One True God of programming. [1]: even in a full C project, it's straightforward to write you new code in Rust in separate files, thanks to Rust really good interop with C. Example: https://bawk.space/2016/10/06/c-to-rust.html https://bawk.space/2016/10/06/c-to-rust.html
- jstewartmobile 10y ago
  My claim is that the particular class of bugs relating to memory/overflows have not been an issue in my career, while bugs arising from API and language ambiguities have caused considerable headaches.
  - emmelaich 10y ago
    The problems caused by language ambiguities and pointer arithmetic and addressing is exactly what makes C difficult. So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. But I agree that C difficulty is sometimes exaggerated - partly it's expectations. ps. by ambiguity do you mean undefined behaviour?
    - thegeekpirate 10y ago
      > So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. If after 20 years they don't know the C spec well enough to know if a piece of code should work or not, I simply wouldn't consider them very good programmers.
pjc50 10y ago
"(Self-inflicted)" is an important disclaimer, because it implies that you work mostly on your own from the metal up? (Also a meta-note about HN discussion: we have years of people saying "there's a problem here" and one guy saying "it's not a problem for me", seemingly unable to see why anyone else has a problem. "Works for me" is not a mission statement.)
- jstewartmobile 10y ago
  Nah. I have had to deal with memory issues in 3rd-party dependencies, so I'm not saying it never happens. I'm just saying I have much bigger problems in other areas that are mostly unaffected by "better" languages.
Volt 10y ago
>I've never had a (self-inflicted) problem in that area. That you know of.
pcwalton 10y ago
> In 20+ years of C, I've never had a (self-inflicted) problem in that area. Maybe I'm the rain man of bit-twiddling? Have people been actively looking for mistakes in your code to find exploits? I just wrote a simple throwaway .otf parser in C, which I've been coding in for a decade and a half. After trying to think about all the places overflow due to malicious input could occur, I just gave up and wrote "FIXME: Insecure" over it, pending a rewrite in something better. In general, I don't see how you can deny that memory safety problems exist. Pwn2Own is a thing. > What has caused me tremendous grief are all of the inconsistencies in the compilers, the gotchas of the precompiler, and the ambiguities in the language itself. C++ is even worse. > Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop). You just explained exactly why all those inconsistencies and ambiguities exist. And we will keep suffering from them as an industry until we decide to move beyond a language from 1978.
- jstewartmobile 10y ago
  Dude, I never denied that those problems exist, and I have no beef with your language. My primary points are: 1. Memory management has never presented itself as public enemy #1 in my personal career. Other things have always been far more troublesome. 2. For complicated programs that have been continuously developed and extended for decades, a re-write in a "better" language is not a particularly good idea. FWIW, for new stuff, Rust is a good choice. Also, being at Mozilla, I can understand why memory management seems like priority #1. You are a platform! The rest of us are building on the shifting sands that the west coast creates. Keeping up with Microsoft changing this and Google changing that is WAAAAY more trouble than pointer arithmetic (for me anyway).
  - pcwalton 10y ago
    > 2. For complicated programs that have been continuously developed and extended for decades, a re-write in a "better" language is not a particularly good idea. Can you explain the strategy you propose to stop the entire browser industry from getting knocked over at Pwn2Own every year?
maxxxxx 10y ago
I have seen memory errors in large C codebases produced by larger teams. I think C requires a certain level of discipline and a lot people working at large companies simply don't care enough. From my experience using a simple subset of C++ using things like shared_ptr reduces problems a lot.

faragon 10y ago

Also, there is the risk of re-doing everything and getting worse results: e.g. executable/library bloat, code harder to read/understand, interoperability/binding issues, etc.

k__ 10y ago
At least Rust allows to write drop-in replacements.
- faragon 10y ago
  Theoretically, yes. In practice, you'll get "Frankensteins" with multi-platform compatibility issues.

psyc 10y ago

I agree with you. I've been a C and C++ programmer for decades, and nothing to do with memory safety or leaks has ever risen to the level of prohibitive or even annoying. Ironically, I've had infinitely more grief from fighting hostile garbage collectors, but that's because I'm a game programmer. I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have. I'm always met with strawman arguments about how I can't possibly write "correct" code. It's a strawman because I don't claim to write correct code. I don't care if Herb Sutter can find 1000 "bugs" in my C++. I care that my users and myself are happy.

jstewartmobile 10y ago
Sometimes you have to wonder if these admonitions from industry trendsetters are really just sneaky tricks to slow the rest of us down... "Hey, that C++ code that's been working for years? All wrong! Go rewrite it in Node.js. No, no, no, in Go this time. Now Rust!" ...
- pdimitar 10y ago
  I absolutely don't disagree with both of you. That being said, I've been knowing game developers for years and while I don't know their exact complaints, they kept saying they wished they were working with something else than C++. I think it's mostly solving the same problems many times over and over, during their entire career.
  - deleted 10y ago
    [deleted]
  - psyc 10y ago
    I do wish I was working with something else. Something I'm still surprised doesn't exist yet. I understand the reason it doesn't exist is that a cherry-picked subset of C++ is good enough. This hypothetical language would be a greatly simplified C++ with a couple dozen small annoyances smoothed over.
    - pdimitar 10y ago
      Absolutely. I'd be delighted to code in a simplified C++.
    - buserror 10y ago
      Well, you CAN do simplified C++. Apple even had their own version of it called 'Embedded C++' (the drivers in OSX are like that) -- basically, remove RTTI, exceptions, templating and a few other bits and you get a C with namespacing, objects, nice context-based stack based objects and a few other nice things, without the bloat. So, yes technically you CAN write nice lightweight C++; but you won't be able to enforce it in a team, as everyone will need 'their' pet feature of doom to bring back the bloat. How do I know? Well, I tried for years to do it like that; and eventually I had to give up. Now I do plain C, because it can't be corrupted in the same way. "But, but, I just #included <vector>!!" "... What, for a 5 byte constant array?" "Yeah I know, but the compiler will just inline it!"

pdimitar 10y ago

IMO it's yes and no. YES: Because you're right. Small more iterative changes in terms of tightening up the language to allow for more predictable software (and environment like the kernel) can get us a long way ahead. NO: Because even though you're very correct, there comes a point in any software stack where the expenses of rewriting the whole thing are vastly smaller than the expenses of iteratively reworking it. I have drifted away from C/C++ a long time ago -- around 10 years. I personally got sick and tired of per-compiler quirks, different precompiler policies, and writing sed scripts to fix messed up preprocessed files, to name only 3 generic problems. IMO I believe if something between Golang and Rust comes along and brings only their positives to the table, it'll be very worth to rewrite (or make richer version of) a huge amount of legacy tools in them -- especially if they bring extremely easy cross-compiling and strong runtime guarantees. I don't know enough to claim either way but in my eyes C has been around for a very long time and a good chunk of the complaints are still in place. I'm tempted to think the community had its chance and that it's time something [somewhat] better must replace it.

jstewartmobile 10y ago
In the commercial space, devs already have to rework their apps frequently to handle the curve-balls MS/Apple/Google etc. throw at them. If we had a C compiler with webkit-level dominance, and we made just one fix to it every cycle, that would be a big thing, and it would be manageable! It's like, "Oh, to be C-2016 compliant I've got to get rid of all my calls to unsafe string functions." Search, replace, and some elbow-grease later, and I've improved my program with a much lower likelihood of breaking functionality.
- pdimitar 10y ago
  Since I am no longer heavily invested in the C/C++ stack I have no choice but to agree with you. My general point is that IMO the tech giants' patience towards C's persistent problems is long over and that's why we have Golang, Swift, Rust etc. Don't crucify me for the "persistent problems" thing please. ;) I fully understand the need for a language as close to the bare metal hardware as possible but many people -- me included -- prefer a more stable and predictable environment with the price of less speed. I believe there's no right or wrong side in this particular preference.

Keyframe 10y ago

Whenever C gets brought up, people are like, "pointers... memory... dangerous!" That's actually the point. It's even coded into C2x charter ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm ): The new spirit of C can be summarized in phrases like: (a) Trust the programmer. (b) Don't prevent the programmer from doing what needs to be done. (c) Keep the language small and simple. (d) Provide only one way to do an operation. (e) Make it fast, even if it is not guaranteed to be portable. (f) Make support for safety and security demonstrable.

loup-vaillant 10y ago
(f) Does this mean they'll remove some undefined behaviour? Or at least mandates options to that effect? That would be marvellous.
- wangchow 10y ago
  I tend to read undefined as don't do it
  - syncsynchalt 10y ago
    It's not always possible / feasible to avoid undefined operations. Use the modulo operator? Undefined unless you checked for negative first. Add two integers? Undefined unless you check for overflow. Granted those examples get a pass because on modern two-complement architectures everything handles the undefined behavior in an identical way.
    - loup-vaillant 10y ago
      I believe the modulo operator is implementation defined. As should be signed integer overflow, though it isn't. One big problem about "undefined" is, when some platform go bananas over some stuff, the behaviour is standardised as undefined for all platforms, allowing the compilers to go bananas. Which they do, because every bit of undefined helps them perform some micro-optimization they couldn't do before. I long for the day where the standard forces compilers to provide options such as -fwrap or -fno-strict on platforms that can reasonably support it.

willtim 10y ago

From a security perspective, C is inadequate. This is the biggest issue facing our use of the language currently.

jstewartmobile 10y ago
From a security perspective, if you think C is inadequate, try taking a look at the instruction set docs for one of Intel or AMD's semi-modern chips. ;-)
- yxhuvud 10y ago
  That is not an excuse. Defence in depth is a thing.
  - jstewartmobile 10y ago
    If you're building on a sinkhole, I don't see how having really nice floors helps.
    - platz 10y ago
      I don't see how the chip's 'sinkhole' enabled bugs like heartbleed, which was industry-scale, which absolutely could've been prevented by having a really nice floor.
    - jstewartmobile 10y ago
      You can fix heartbleed--even in C. You can't fix TPM hacks, rowhammer, etc. without buying a new machine. That's not even getting into the potential of the missteps in the RMM / MMU / SMP / virt systems that exasperate even Torvalds and deRaadt.
      - sitkack 10y ago
        You are making an all or none fallacy. While those things do exist, we can't use them as an excuse to prevent the common case.

sbov 10y ago

How do you define problem? In terms of consequences or mere presence of a bug? If it's consequences, is it plausible that you have had no problems because not enough people are interested in attacking your code? If you say you have never produced a memory/pointer related bug that got past you, then you probably are the rain man.

jstewartmobile 10y ago
I mean that through strict valgrind and fuzzers, I've never had it find anything in my own code. I've also never had a hard-crash from anything in my own code. I attribute this to personal paranoia about input and indices. Worst experiences I've had in that domain were due to inconsistencies in things like the Win32 API across different OS versions that were allegedly supposed to behave the same way. Sometimes I think better API and language documentation would improve programs more than better languages.
- geofft 10y ago
  Wouldn't you prefer to have the computer deal with the personal paranoia for you? I love C dearly, but I can write so much faster in, say, Python, and that code is usually production-suitable. If I say "for line in open(sys.argv[1])", I don't have to spend 50 lines dealing with open() failing, or sys.argv() being the wrong length, or allocating a buffer to read into and recombining lines longer than the buffer, or whatever. Ideally in Python I'd print better error messages, but it's fine if I forget; Python will take care of each of those problems and do something safe, if not user-friendly. If I forget any of those in C, it's emphatically not fine. Rust - and many other higher-level compiled languages! - promise to bring that development speed and confidence back to the domains where C dominates.
  - jstewartmobile 10y ago
    I do prefer it, and for new things, I love Rust and Golang and Clojure. I even kind-of like Python (aside from the blocks-by-indentation thing). I'm just saying that for old things, staying the course will probably be more fruitful than fresh start in a different language.

pavlov 10y ago

I always felt that Objective-C was a great take on a "better C"... Definitely not conceptually better in the ways that Rust is, but simply better for a lot of the practical things where C suffers the worst. Obj-C was an appealingly simple extension to C from the compiler point of view, but for a long time it was hobbled by the runtime/framework situation, as the NeXT/Apple runtime wasn't open source. Just as that compatibility hurdle was getting fixed by open source efforts around 10 years ago, the iPhone happened and Apple went nuts with extensions to the language... It used to be that Objective-C proponents would brag that you can learn the syntax in 5 minutes if you know C. Now the language is filled with uncountable double-underscored keyword warts and @ declarations. Today's Obj-C looks more like an intermediate format for a Swift->C compiler rather than an evolution of Obj-C 1.0. I understand completely why that happened. I just wish that Obj-C had gained more of an open source foothold when the opportunity was there, so it wouldn't have been so dependent on Apple's stewardship which eventually killed it as an independent language.

eschaton 10y ago
The NeXT/Apple Objective-C runtime has been Open Source since the late 1990s, the API and ABI have been documented since the late 1980s so anyone could create a compatible runtime, and GCC has had a portable runtime almost since Objective-C was taken into its mainline.
favorited 10y ago
I can agree about the nullability annotations & generics additions, but having properties, ARC, & blocks made writing Objective-C programs so much nicer, IMO.
mpweiher 10y ago
Hear hear! And then I watch something like Gary Bernhard's "Boundaries" talk[1], which isn't bad, mind you, and think "maybe this Brad Cox guy with his Software ICs really knew what he was talking about?" Where Apple went off the rails with Objective-C was trying to make it into an OO language like Java. It isn't. It is a deliberate hybrid, with a component implementation language ("C") married to a component connection language ("Objective"). My own approach is to take this distinction seriously, and instead of doubling down on the "better Java" part like Swift does (which in Software-IC terms is focusing on the less interesting and mostly solved component implementation part) and instead expand on the ways we can connect components (dataflow, constraints, storage composition, etc.).[2] Minor correction: GNUStep, libFoundation etc. happened around 20 years ago, not 10. [1] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [2] http://objective.st/ http://objective.st/

stymaar 10y ago

> Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop). I agree with that, and most people do even in the Rust community. I don't expect people to rewrite their software in Rust, but if people could stop writing new C code[1], the world would become a better place in the next decades … > Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area. In 20+ years of C, you never faced a single segfault ?! I'm sorry but I don't trust you. You're basically pretending being the One True God of programming. [1]: even in a full C project, it's straightforward to write you new code in Rust in separate files, thanks to Rust really good interop with C. Example: https://bawk.space/2016/10/06/c-to-rust.html https://bawk.space/2016/10/06/c-to-rust.html

jstewartmobile 10y ago
My claim is that the particular class of bugs relating to memory/overflows have not been an issue in my career, while bugs arising from API and language ambiguities have caused considerable headaches.
- emmelaich 10y ago
  The problems caused by language ambiguities and pointer arithmetic and addressing is exactly what makes C difficult. So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. But I agree that C difficulty is sometimes exaggerated - partly it's expectations. ps. by ambiguity do you mean undefined behaviour?
  - thegeekpirate 10y ago
    > So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. If after 20 years they don't know the C spec well enough to know if a piece of code should work or not, I simply wouldn't consider them very good programmers.

pjc50 10y ago

"(Self-inflicted)" is an important disclaimer, because it implies that you work mostly on your own from the metal up? (Also a meta-note about HN discussion: we have years of people saying "there's a problem here" and one guy saying "it's not a problem for me", seemingly unable to see why anyone else has a problem. "Works for me" is not a mission statement.)

jstewartmobile 10y ago
Nah. I have had to deal with memory issues in 3rd-party dependencies, so I'm not saying it never happens. I'm just saying I have much bigger problems in other areas that are mostly unaffected by "better" languages.

Volt 10y ago

>I've never had a (self-inflicted) problem in that area. That you know of.

pcwalton 10y ago

> In 20+ years of C, I've never had a (self-inflicted) problem in that area. Maybe I'm the rain man of bit-twiddling? Have people been actively looking for mistakes in your code to find exploits? I just wrote a simple throwaway .otf parser in C, which I've been coding in for a decade and a half. After trying to think about all the places overflow due to malicious input could occur, I just gave up and wrote "FIXME: Insecure" over it, pending a rewrite in something better. In general, I don't see how you can deny that memory safety problems exist. Pwn2Own is a thing. > What has caused me tremendous grief are all of the inconsistencies in the compilers, the gotchas of the precompiler, and the ambiguities in the language itself. C++ is even worse. > Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop). You just explained exactly why all those inconsistencies and ambiguities exist. And we will keep suffering from them as an industry until we decide to move beyond a language from 1978.

jstewartmobile 10y ago
Dude, I never denied that those problems exist, and I have no beef with your language. My primary points are: 1. Memory management has never presented itself as public enemy #1 in my personal career. Other things have always been far more troublesome. 2. For complicated programs that have been continuously developed and extended for decades, a re-write in a "better" language is not a particularly good idea. FWIW, for new stuff, Rust is a good choice. Also, being at Mozilla, I can understand why memory management seems like priority #1. You are a platform! The rest of us are building on the shifting sands that the west coast creates. Keeping up with Microsoft changing this and Google changing that is WAAAAY more trouble than pointer arithmetic (for me anyway).
- pcwalton 10y ago
  > 2. For complicated programs that have been continuously developed and extended for decades, a re-write in a "better" language is not a particularly good idea. Can you explain the strategy you propose to stop the entire browser industry from getting knocked over at Pwn2Own every year?

maxxxxx 10y ago

I have seen memory errors in large C codebases produced by larger teams. I think C requires a certain level of discipline and a lot people working at large companies simply don't care enough. From my experience using a simple subset of C++ using things like shared_ptr reduces problems a lot.