6 ms·

If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compet

If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew up. To all the people popping off about how great other languages are, tell me: when will we see the Unreal Engine written in Python, or Pascal, or Algol, or Rust, or Go... the next big step is WebASM (or .cu), and that's way more footbullet-y than C. And what is the native language all of your sub-30 year old interpreted languages were written in? Thank you!

tester756 6y ago
Just because I want to know people opinion's (+they may be more than happy to shit on C#:) C# But please, nothing about using unsafe.
maerF0x0 6y ago
Not that I dont believe there are any, but I'd love to hear your perspective... Go (golang)
- crimper 6y ago
  channel programming and the races caused by closing channels. channels seem nice and easy until they don’t. the whole var/:=/= assignment combined with the error handling style and the shorthand is another one
  - maerF0x0 6y ago
    yeah the lack of determinism in selecting a channel can be tricky for causing bugs where order matters. Luckily in smaller cases you're likely to encounter them as flakey tests (eg 1/2 the time) select { case <-ch1: case <-ch2: }
    - crimper 6y ago
      thanks for this, i couldn’t articulate it so clearly. Another gotcha is responding to closed channels, it makes sense in the grand scheme of things but when the program grows it gets tricky
  - dpatterbee 6y ago
    Only close channels when trying to tell the receiver that you're not sending more data. Otherwise let the garbage collector deal with it. Channels seem easy until they don't until they do again in my experience. Don't understand your second point.
- SavantIdiot 6y ago
  Well, shit. Got me there.
- boolemancer 6y ago
  defer having function scope instead of, well, scope scope. Using defer to unlock locks can lead to some fun deadlocks if you don't realize the issue with the scope, and it's completely unintuitive to someone with experience with other implementations of similar concepts.
eschaton 6y ago
This is a grossly inaccurate description of computing at the time of the rise of C. C was competing with Pascal/Modula, BLISS, PL/I, BCPL, and so on, not assembly on punched cards. The “C competing with assembly” meme was very specific to microcomputer game and operating system development, not more general microcomputer application development, and not to minicomputer or mainframe development.
- JoeAltmaier 6y ago
  Mainframes very quickly were outclassed by minicomputers. They could not respond quickly to technology changes as fast. C was indeed king for decades.
  - int_19h 6y ago
    C was not without competition on microcomputers, either. A lot of DOS software was written in Pascal, for example - and it wasn't any slower for that.
    - Turing_Machine 6y ago
      A lot of it was written in Turbo Pascal, which (among many other things that would have caused Niklaus Wirth to break out in hives) let you include inline machine code (and later, inline assembly language).
      - int_19h 6y ago
        That's true, but so did C compilers at the time. And most software didn't actually make use of it - they didn't have to, because Turbo Pascal had e.g. pointer arithmetic as powerful as in C. But anyway, we were talking about the real world software on microcomputers, not just standards in the abstract. With that in mind, I think TP/BP is a better example of Pascal in the wild than anything Wirth ever made.
rodgerd 6y ago
There's far more critical code in the world running on COBOL and s3[79]0 assembler. COBOL is vastly more important than C.
- mkipper 6y ago
  citation needed I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.
  - burnished 6y ago
    COBOL is still used in many banking systems such as ATMs. These are 'critical' systems by most any definition of the word 'critical'.
    - varjag 6y ago
      That's a hugely broad definition of critical, enough to encompass most of business and finance software.
    - mkipper 6y ago
      Sure. But is there far more critical COBOL than C out there? The OS kernel for nearly every PC and server on earth is written in C. Almost every electronic device on earth complicated enough to require software is probably running at least some firmware written in C. I think those both outnumber ATMs by a hefty margin.
    - Cullinet 6y ago
      take a look at VMS to behold how elegantly and seamlessly we wrote software in whichever language suited the task most appropriately, barely conscious of the concept of foreign functions being a horror story for future generations instead of being entirely standard and letting us switch from BLISS to Pascal to ADA and C and C++ and DEC BASIC and throw in a few DCL macros or optimize the compilers to which source was of course provided and so that's how we delivered really rather efficient programs, really, in LOC, since nobody was hammering square pegs into semantic round holes or chasing effects when you needed to manage types intrinsically to your critical path routines but didn't need to extend the type system throughout your code base because RDB quaintly would let you call it in FORTRAN and get down to typology from the elements of mathematical sets themselves if you must, nicely isolated and ACID wrapped with system wide cluster transaction management available for everything and everyone's needs and the filesystem designed orthogonal to the database letting you think of your data in a single unified concept with primordial os level guarantee of data integrity for corollary sanity checking
cygx 6y ago
Recall that during the rise of C, people were writing machine code on punch cards. Or Fortran, Algol, Lisp, Cobol, Basic, Pascal, ...
Gibbon1 6y ago
My favorite assembly foot gun was a guy I worked with had a cute routine. You had a call to the routine, followed by a null terminated string after that. The routine would spit the string to the terminal. And then return to the location after the string. He had some bug where in one place it returned to the start of the string, executed it, and kept going. The end result just happened to be a nop. Had been like that in production for a couple of years.
- watersb 6y ago
  And when you fix it, everything breaks.
atoav 6y ago
Yeah there are footguns in every language. But this is not a boolean question about the presence of footguns, this is about how much one has to know to be able to handle a language safely. I know C/C#/Python/Rust/Javascript. After a decade of using C I am still not totally sure if I didn't dangle a pointer somwhere in precisely the wrong way to create havoc. And yeah, that means I have to get better, etc. But that is not the point. The point is, that even with a lot of experience in the language you can still easily shoot yourself into the foot and don't even notice it. Meanwhile after a month of using Rust I felt confident that I didn't shoot myself in the foot, because I know what the compilers e.g. ownership guarantuees. While in C shooting myself into the foot happen quite often in Rust I would have to specifically find a way to shoot myself into the foot without the compiler yelling at me, and quite frankly I havent found such a way yet. Javascript is odd, because the typesystem has quite a few footguns in it. This is why such things like Elm or Typescript exist: to avoid these footguns. I don't want to take away from the accomplishments of C, and I still like the language, but to claim it is equally likely in all languages to shoot yourself into the foot is not true.
badsectoracula 6y ago
> when will we see the Unreal Engine written in... Why would a huge C++ (not C, btw) codebase with roots going back to the 90s be rewritten in any other language? And in fact how is the language Unreal Engine written in relevant to C having footguns?
samatman 6y ago
Your edit really isn't helping your case. Those of us who have always known about less dangerous 'system' languages (Pascal probably being the most popular) lament the fact that so much code got written in C instead. It wasn't inevitable. It was preventable! It just didn't happen that way for reasons which are largely historical. I don't work for the Rust Evangelism Strike Force, my main project is written in (as little) C (as possible), but I beg anyone who has a choice: use something else! Rust is... fine, Zig is promising. Ada still works! Writing out the set {Python, Pascal, Algol, Rust, Go} tempts me to say uncharitable things about your understanding of the profession, but I accept you were just being snarky so I'll just gesture in the direction of how $redacted that is.
int_19h 6y ago
Consider the fact that Simula-67, which predated C by 3 years, had classes and objects very similar to what Java offers (and then some - e.g. coroutines), and a built-in string processing library that used object-oriented syntax. The reason why C won had little to do with its advantages as a language over the competitors. It just happened to be the systems language for Unix, which was the winner in the early OS wars on microcomputers (for unrelated reasons). Once it became so established, there was a positive feedback loop: you would write portable code in C, because you knew that it was the fastest language that most platforms out there would support. And then any new platform would offer a C compiler, because they wanted to be able to run all the existing C code out there. And so, here were are.

tester756 6y ago

Just because I want to know people opinion's (+they may be more than happy to shit on C#:) C# But please, nothing about using unsafe.

maerF0x0 6y ago

Not that I dont believe there are any, but I'd love to hear your perspective... Go (golang)

crimper 6y ago
channel programming and the races caused by closing channels. channels seem nice and easy until they don’t. the whole var/:=/= assignment combined with the error handling style and the shorthand is another one
- maerF0x0 6y ago
  yeah the lack of determinism in selecting a channel can be tricky for causing bugs where order matters. Luckily in smaller cases you're likely to encounter them as flakey tests (eg 1/2 the time) select { case <-ch1: case <-ch2: }
  - crimper 6y ago
    thanks for this, i couldn’t articulate it so clearly. Another gotcha is responding to closed channels, it makes sense in the grand scheme of things but when the program grows it gets tricky
- dpatterbee 6y ago
  Only close channels when trying to tell the receiver that you're not sending more data. Otherwise let the garbage collector deal with it. Channels seem easy until they don't until they do again in my experience. Don't understand your second point.
SavantIdiot 6y ago
Well, shit. Got me there.
boolemancer 6y ago
defer having function scope instead of, well, scope scope. Using defer to unlock locks can lead to some fun deadlocks if you don't realize the issue with the scope, and it's completely unintuitive to someone with experience with other implementations of similar concepts.

eschaton 6y ago

This is a grossly inaccurate description of computing at the time of the rise of C. C was competing with Pascal/Modula, BLISS, PL/I, BCPL, and so on, not assembly on punched cards. The “C competing with assembly” meme was very specific to microcomputer game and operating system development, not more general microcomputer application development, and not to minicomputer or mainframe development.

JoeAltmaier 6y ago
Mainframes very quickly were outclassed by minicomputers. They could not respond quickly to technology changes as fast. C was indeed king for decades.
- int_19h 6y ago
  C was not without competition on microcomputers, either. A lot of DOS software was written in Pascal, for example - and it wasn't any slower for that.
  - Turing_Machine 6y ago
    A lot of it was written in Turbo Pascal, which (among many other things that would have caused Niklaus Wirth to break out in hives) let you include inline machine code (and later, inline assembly language).
    - int_19h 6y ago
      That's true, but so did C compilers at the time. And most software didn't actually make use of it - they didn't have to, because Turbo Pascal had e.g. pointer arithmetic as powerful as in C. But anyway, we were talking about the real world software on microcomputers, not just standards in the abstract. With that in mind, I think TP/BP is a better example of Pascal in the wild than anything Wirth ever made.

rodgerd 6y ago

There's far more critical code in the world running on COBOL and s3[79]0 assembler. COBOL is vastly more important than C.

mkipper 6y ago
citation needed I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.
- burnished 6y ago
  COBOL is still used in many banking systems such as ATMs. These are 'critical' systems by most any definition of the word 'critical'.
  - varjag 6y ago
    That's a hugely broad definition of critical, enough to encompass most of business and finance software.
  - mkipper 6y ago
    Sure. But is there far more critical COBOL than C out there? The OS kernel for nearly every PC and server on earth is written in C. Almost every electronic device on earth complicated enough to require software is probably running at least some firmware written in C. I think those both outnumber ATMs by a hefty margin.
  - Cullinet 6y ago
    take a look at VMS to behold how elegantly and seamlessly we wrote software in whichever language suited the task most appropriately, barely conscious of the concept of foreign functions being a horror story for future generations instead of being entirely standard and letting us switch from BLISS to Pascal to ADA and C and C++ and DEC BASIC and throw in a few DCL macros or optimize the compilers to which source was of course provided and so that's how we delivered really rather efficient programs, really, in LOC, since nobody was hammering square pegs into semantic round holes or chasing effects when you needed to manage types intrinsically to your critical path routines but didn't need to extend the type system throughout your code base because RDB quaintly would let you call it in FORTRAN and get down to typology from the elements of mathematical sets themselves if you must, nicely isolated and ACID wrapped with system wide cluster transaction management available for everything and everyone's needs and the filesystem designed orthogonal to the database letting you think of your data in a single unified concept with primordial os level guarantee of data integrity for corollary sanity checking

cygx 6y ago

Recall that during the rise of C, people were writing machine code on punch cards. Or Fortran, Algol, Lisp, Cobol, Basic, Pascal, ...

Gibbon1 6y ago

My favorite assembly foot gun was a guy I worked with had a cute routine. You had a call to the routine, followed by a null terminated string after that. The routine would spit the string to the terminal. And then return to the location after the string. He had some bug where in one place it returned to the start of the string, executed it, and kept going. The end result just happened to be a nop. Had been like that in production for a couple of years.

watersb 6y ago
And when you fix it, everything breaks.

atoav 6y ago

Yeah there are footguns in every language. But this is not a boolean question about the presence of footguns, this is about how much one has to know to be able to handle a language safely. I know C/C#/Python/Rust/Javascript. After a decade of using C I am still not totally sure if I didn't dangle a pointer somwhere in precisely the wrong way to create havoc. And yeah, that means I have to get better, etc. But that is not the point. The point is, that even with a lot of experience in the language you can still easily shoot yourself into the foot and don't even notice it. Meanwhile after a month of using Rust I felt confident that I didn't shoot myself in the foot, because I know what the compilers e.g. ownership guarantuees. While in C shooting myself into the foot happen quite often in Rust I would have to specifically find a way to shoot myself into the foot without the compiler yelling at me, and quite frankly I havent found such a way yet. Javascript is odd, because the typesystem has quite a few footguns in it. This is why such things like Elm or Typescript exist: to avoid these footguns. I don't want to take away from the accomplishments of C, and I still like the language, but to claim it is equally likely in all languages to shoot yourself into the foot is not true.

badsectoracula 6y ago

> when will we see the Unreal Engine written in... Why would a huge C++ (not C, btw) codebase with roots going back to the 90s be rewritten in any other language? And in fact how is the language Unreal Engine written in relevant to C having footguns?

samatman 6y ago

Your edit really isn't helping your case. Those of us who have always known about less dangerous 'system' languages (Pascal probably being the most popular) lament the fact that so much code got written in C instead. It wasn't inevitable. It was preventable! It just didn't happen that way for reasons which are largely historical. I don't work for the Rust Evangelism Strike Force, my main project is written in (as little) C (as possible), but I beg anyone who has a choice: use something else! Rust is... fine, Zig is promising. Ada still works! Writing out the set {Python, Pascal, Algol, Rust, Go} tempts me to say uncharitable things about your understanding of the profession, but I accept you were just being snarky so I'll just gesture in the direction of how $redacted that is.

int_19h 6y ago

Consider the fact that Simula-67, which predated C by 3 years, had classes and objects very similar to what Java offers (and then some - e.g. coroutines), and a built-in string processing library that used object-oriented syntax. The reason why C won had little to do with its advantages as a language over the competitors. It just happened to be the systems language for Unix, which was the winner in the early OS wars on microcomputers (for unrelated reasons). Once it became so established, there was a positive feedback loop: you would write portable code in C, because you knew that it was the fastest language that most platforms out there would support. And then any new platform would offer a C compiler, because they wanted to be able to run all the existing C code out there. And so, here were are.