8 ms·

Man, I miss making a living as a C programmer. My happiest days as a dev were when my "stack" was Linux, C, Makefiles, and some shell scripts. Only thing I'd ch

by cblum 8y ago

Man, I miss making a living as a C programmer. My happiest days as a dev were when my "stack" was Linux, C, Makefiles, and some shell scripts. Only thing I'd change is that source control was svn instead of git. Sure, there was a lot more to type. Debugging was harder. But there was a beauty to that. A simple mental model. A sense of control. These days all jobs seem to be sort of online crap. Piles and piles of layers and complexity and heterogenous frameworks and tools. Being on call. Never being able to truly master anything because everything changes all the time. /nostalgia

freedomben 8y ago
Oh man, I feel exactly the same my friend. People who have never gotten into the C world find it frightening, but it's a beautifully simple language loaded with (at times dangerous) power. It's so much closer to the hardware that you can't use a declarative approach easily (which now that I've drunk the functional programming kool-aid, I do love), but in many ways it's actually much simpler to understand. You can also be pretty declarative if you are just smart about breaking things into functions. I still glance longingly at my dusty paper copy of The Linux Programming Interface (https://nostarch.com/tlpi https://nostarch.com/tlpi) /nostalgia
- mpweiher 8y ago
  > beautifully simple language :-) Of course there are those who claim it is actually frightfully complex, when it is those same people who are re-interpreting the standards to actually create that very complexity.
  - cblum 8y ago
    Not sure if this is what you meant, but a lot of the stuff they added to C in the latest standards really turn me off. C89 has a special place in my heart.
- tombert 8y ago
  Honestly, if you use one of the available GCs out there (like Boehm's), and give up on static typing, and heavily rely on function pointers, you can write C similar to how you'd write something like Haskell. Yes, it won't go as fast as it the most idiomatic C, and you can't really make an operating system if you have a GC, but really, how often do most of us actually write code that can't use a GC these days? Even with a GC, it'll still probably perform better than 90% of languages.
  - cblum 8y ago
    At that point it's practically not C anymore :) I'm not a fan of adding GC to C. I've hard my fair share of stress caused by GC issues. It's great 99% of the time but when you run into performance issues caused by the GC it becomes a very very leaky abstraction.
    - tombert 8y ago
      I'm ok with it not being 70's-era C to be honest; I even with the extra stuff, I find the language to be fairly simple to pick up compared to C++. I haven't had any problem with performance with the Boehm GC personally, though for what I've used C for is not-real-time video processing stuff. I found I typically got better throughput using Boehm than I did when I was manually managing my memory, but for what I was using it for, a small pause wasn't really a problem as long as the throughput wasn't really affected.
    - kevin_thibedeau 8y ago
      One may as well just use C# without classes.
      - n4r9 8y ago
        Pedantically speaking that's impossible. But loosely speaking that's the essence of how I write most of my C#.
  - disishhsha 8y ago
    If you have a GC and no static typing, is it better than other functional languages (many of which have benefits of both GC and static typing)? Not a rhetorical question, I have never used a GC with C.
- vardump 8y ago
  > People who have never gotten into the C world find it frightening... I got into C over 25 years ago. Didn't find it frightening back then, but I sure do now. Still use it pretty often for firmware and kernel driver development, but I want to replace it with something safer. Then again, I also use assembler for same reasons... sometimes C just doesn't cut it for interrupt handlers when every cycle and/or code byte size counts.
  - vectorEQ 8y ago
    > Still use it pretty often for firmware and kernel driver development, but I want to replace it with something safer. Then again, I also use assembler for same reasons... sometimes C just doesn't cut it for interrupt handlers when every cycle and/or code byte size counts. That's what you have ASM for :D j/k
  - freedomben 8y ago
    > Didn't find it frightening back then, but I sure do now. Why is that? Security related stuff?
    - vardump 8y ago
      Yup. Things are increasingly connected to network. Including legacy codebases. Also when you have larger teams and more people touching the code, C can really shoot at your feet and elsewhere. From new and surprising angles.
      - freedomben 8y ago
        No doubt. It's amazing too how some code that was never expected to be exposed to untrusted/unsanitized data gets re-factored into a new spot or called from somewhere else, and fails to provide sanitation expecting that the callee will do it, or simply forgetting altogether (easy when under pressure to deliver). I coded a pretty bad security hole myself once by doing something like that, and I am a security specialist that knows what to look for lol! I love C, but it really is a security nightmare full of footguns.
- vectorEQ 8y ago
  i still only code in C, didn't start in the stone ages, but i love it. C and asm give me the feeling i'm programming my computer, and really for low level stuff trying to find a good alternative which is as good and simple (yes simple :D c/asm is just pure logic!) is difficult for me. I don't code professionally though, since i can't for the life of me find a job in C which doesn't have already tons of guys like you guys with a century of experience in the language lining up to take it :D C/asm is awesome, can't bare anything else
zozbot123 8y ago
> ...But there was a beauty to that. A simple mental model. A sense of control. There's something to that, I think. And it's still an open question whether the newer languages that are in development at present will succeed in bringing some of that underlying "beauty" back. It's an important issue if we want lower-level programming to be more widely accessible. (To clarify - the underlying machine model of C is beautifully simple, and newer low-level languages tend to be built on something very much like it anyway. The C language itself is frightfully complex - albeit less so than that other language in the C family that's often conflated with it.)
- ineedasername 8y ago
  I wonder if, now that processor speeds are increasing at a much slower rate, there will be a return to that lower level programming to focus on speed improvements through more efficient code.
- p1esk 8y ago
  I bet that's what some people were saying referring to assembly when C came out :)
  - AnimalMuppet 8y ago
    People said it about assembly when it came out. The actual (binary or octal) machine codes gave you an intimacy with the hardware that assembly took away. (People actually said that.)
    - p1esk 8y ago
      If you like "intimacy with hardware" you can drop down one level below machine code and design a processor on an FPGA with Verilog. Or, to go even deeper, design a custom circuit with SPICE. C might be the optimal point on the abstraction ladder as far as the trade off between (exposed) complexity and control.
      - AnimalMuppet 8y ago
devenson 8y ago
Golang gives me that same C feeling.
- agumonkey 8y ago
  Russ Cox articles do have that simple and defined quality of old days.
- cblum 8y ago
  I've been slowly making my way through A Tour of Go and I really like what I've seen so far.
  - romeisendcoming 8y ago
    Funny. I looked through the GO book and walked away feeling justified in being diligent with C. Maybe that's because I dislike jumping through other peoples hoops when I know better.
- jxub 8y ago
  The GC and goroutines make it more abstracted from the metal than it looks, while lacking the conveniences of the zero-cost abstractions available in lower-level languages like Rust. The only upside of taking the opposite side of the Rust tradeoff is compile time.
  - zozbot123 8y ago
    > The only upside of taking the opposite side of the Rust tradeoff is compile time. Not so, there are a few specialized domains where having tracing GC easily available is genuinely useful. (Pretty much anything having to do with general graphs - the sort of stuff you'd traditionally use LISP for!) Go is a great fit for these use cases.
  - freyir 8y ago
    It still gives me the feel of C, despite the abstractions (which I generally appreciate). Rust is like something else entirely.
fit2rule 8y ago
This is why I feel that the solution to most of the modern ailments in development is to just put Lua everywhere. All the great stuff of C, and all the new-school shit too. If you do this, it'll seem soon enough that the Javascript nightmare was just a dream. Takes balls though.
- cblum 8y ago
  I wish! One of the coolest projects I've worked on used Lua. We wrote the core in C++ and then everything else on top of it in Lua.
- sifoobar 8y ago
  I do the same thing with a twist [0], since I'm not very fond of some of Lua's design choices. Lack of a decent type system, the table mess, etc. And I think Forth and Lisp make better glue languages. Can't stop smiling these days when I see people fighting over which language will rule them all. I spent tens of years searching for that language myself. Time I would rather have spent solving real problems using the best tools. [0] https://gitlab.com/sifoo/snigl https://gitlab.com/sifoo/snigl
- bogomipz 8y ago
  What would some examples be of Lua addressing modern ailments? I'm also curious to hear why it's such a good fit for those ailments. Thanks.
  - fit2rule 8y ago
    Its not Lua specifically addressing modern ailments, its the attitude that taking full control to put the same common codebase on as many of the target platforms as possible can be profitable, in light of the vendor mess which is, presumably, what we're talking about here. It can be a very disturbing thing to realise what a few tweaks here and there to package.json might do to ones love life. Lua is a great, easy to use, easy to apply, language -- with a healthy framework ecosystem, and it is very easy to put it to use in a legacy code-base, since its C-based, and we all know that C still makes the world go around. However, its not the fact of Lua, but the fact of 'put our own VM everywhere' that wins, imho.
justadudeama 8y ago
James Mickens has a great part of a talk where he talks about this: https://youtu.be/7Nj9ZjwOdFQ?t=1574 https://youtu.be/7Nj9ZjwOdFQ?t=1574 A little too close to home.
- agumonkey 8y ago
  I was about to say "warning, these are the kind of talks that will revive COBOL.. "
stallmanifold 8y ago
This is one reason I wonder whether there is room in the world for a better C. Low complexity programming languages with a simple machine mental model along the lines of Go (or perhaps in future, Zig and Jai?) for doing systems programming, with a strong static type system, and a rock solid build system. Early in my career I did a lot of bare metal and embedded systems programming and the one thing I miss about C is the predictable assembly output. I primarily use Rust for this purpose right now but I wonder if there's a place for something simpler for doing really low level stuff (i.e. programming hardware directly, device drivers) that's better than C. EDIT: grammar.
- AndyKelley 8y ago
  > I wonder if there's a place for something simpler for doing really low level stuff (i.e. programming hardware directly, device drivers) that's better than C. Like this? https://andrewkelley.me/post/zig-stack-traces-kernel-panic-bare-bones-os.html https://andrewkelley.me/post/zig-stack-traces-kernel-panic-b...
  - christophilus 8y ago
    I like Zig. Have you tried it? I’d be interested in hearing about your experience. I haven’t been able to think of a project to use it for, though, as all of my work these days is web related.
    - dinglejungle 8y ago
      (you replied to the creator of Zig, fyi)
      - deleted 8y ago
        [deleted]
      - christophilus 8y ago
        facepalm I need to start looking at usernames before replying!
booknomads 8y ago
I miss it so much.. btw if you haven't check out Casey Muratori's Handmade Hero on youtube, it will fill you with joy.
reza_n 8y ago
We are always hiring full time C developers doing exactly what you said. Msg me if you (anyone) is interested.
- pnw_hazor 8y ago
  I see the insides of a lot of startups. The C/C++ based companies generally seem to be solving serious problems with good engineering. Startups using frothier tech are often (not always) toy companies building toy products (hyper-scale toys are still toys).
pnw_hazor 8y ago
Programming is kind of joke these days. Each time a new "hotness" language, framework, pattern, or dev/devops process comes out you have a rush of professional gurus working hard to build their business (e.g., speaking fees/books/blogging/training) by teaching that this is the new true way. In the late 90's I began to notice how the new kids kept advocating for the newest so-called best practices to do things that the bad-old practices could handle just fine. Seeing the writing on the wall, I dipped out of the game a few years later. Unfortunately, the unhelpful tech churn has worsened. Similarly, the quality of the product produced has worsened, or at best, not improved. Note, hyper-scale advertisement services, global human tracking, and digital Skinner boxes are not an improvement to anything. Meanwhile 50 year-old programmers with deep general development knowledge cannot find jobs. I guess it is easier for young founders to justify using frothy tech if there are fewer old-timers around to suggest otherwise. edit-to-add: /get-off-my-lawn
- zozbot123 8y ago
  There's a lot of BS, but there are some real improvements as well. Many innovations that are considered best practices today actually came out in the 1990s. The Java programming language became incredibly popular, being a machine-independent, memory-safe language and system that could deal out-of-the-box with concurrency and networking-- The Go of its day, to some extent (and indeed it had a whole lot in common with Go's predecessors, Alef and Limbo). Functional programming was popularized around that time. The C++ standard introduced us to the notion of zero-overhead abstractions combined with strong static checking, which Rust is refining today. And of course, the Web became widespread around that time, as well. Whatever you might think about "hyper-scale advertisement services, global human tracking, and digital Skinner boxes", Amazon first became prominent in the dotcom era, and it's quite massive today.
  - pnw_hazor 8y ago
    I have been reacquainting myself with some so-called best practices as I muddle through my recent side-projects. While some newer languages are interesting, the dev stacks today are a mess. Also, While we have safe pointers and GC everywhere, the lack of technical discipline/professionalism in the industry is worse than ever. I recognize that the C-suite and VCs share in the blame for this, but devs are the ones building things and evangelizing the newest-hotness that comes onto the scene. But I do have to remind myself that compared to traditional engineering tracks, software engineering is still in its infancy. /get-off-my-lawn
SlowRobotAhead 8y ago
Pssst, come over to embedded. We’re in C all day long using kilobytes not gigabytes. I don’t need to chase the latest framework... but I’m also on my own for almost everything. Pros and Cons, but I wouldn’t leave it for anything web related.
- bitwize 8y ago
  The Rust Evangelism Strike Force is gunning for the embedded space, too. As soon as the tooling becomes widespread enough to support the most-used microcontrollers, C will be a niche language even in embedded.
  - ThenAsNow 8y ago
    Was this comment meant pejoratively?
  - SlowRobotAhead 8y ago
    Yea... We'll see. Rust has had quite awhile to make an attempt at Embedded and unless you count drivers for a couple STMs and a few other (mostly outdated) chips - I haven't seen a single thing that says progress. I'd like to see Rust happen, because I don't see C++ as the embedded future. At least Rust had the good sense to leave garbage collection out. However... I'll believe it when I see it. And by that, I mean when STM and Nordic and NXP and others are pushing out their own Rust device support files on their sites. When Keil or IAR or Rowley or Atollic pushes out a full featured IDE that uses a Rust compiler. When Rust is not only supporting the latest run of chips but there is a way to debug them with code-overlay. But until then...
    - steveklabnik 8y ago
      The biggest are of progress has been in using those devices as a test bed to stabilize features working on embedded generally. You can now develop for those devices on stable, which is a huge advantage.
    - pjmlp 8y ago
      > I don't see C++ as the embedded future. AUTOSAR moved from C to C++14 as the certified language. mbed is written in C++.
entelechy0 8y ago
You can relive the dream if you believe. I still operate in makefiles and shell scripts to this day.
Teknoman117 8y ago
Debugging was harder as compared to what? I'll take debugging C over modern C++ any day...
vram22 8y ago
>Man, I miss making a living as a C programmer. Same here. I worked quite a lot on C on Unix and some on Windows (including working on a successful database middleware product on Windows, which was used in some VB+Sybase/Oracle client-server projects) before I got into other languages like Java, Ruby (and Rails) and now Python for quite a while. Great fun working in C, although of course frustrating at times too, debugging weird issues. Also, somehow, I never found working with pointers (at least for simple to intermediate uses of them) confusing, like some do. (I once taught a C programming class at a large public sector company; while I was explaining the int main(int argc, char argv stuff, and the pointer to pointer stuff, the head of their IT dept. who was in the class, said "now it is 'overhead transmission' :)". Maybe I didn't have trouble with pointers because I had some hobbyist assembly language programming background from earlier, including learning about different addressing modes, such as direct, indirect, indexed indirect (or vice versa) (on the 6502 processor), etc., plus used to read a lot on my own about microprocessors, computer architecture, and suchlike related areas, even though they were not directly relevant to my higher-level application programming work (hint hint, to kids learning computers today). Working close to the machine is good. Also, a bit off topic, I kind of independently discovered the concept of refactoring. I was in a nice relaxed state one afternoon, at work, after a good lunch, but not heavy, so not drowsy, working on some Unix C program (likely a CLI one), and over a period of time, I noticed that I had been making small (behavior-preserving) incremental improvements to the code, one after another. In a very relaxed way, without any tension, taking my time for each small change, so I was fairly sure that each small refactoring change did not change the meaning or correctness of the program. Thought that was a good technique after I realized that I had been doing it. Unfortunately did not keep doing it with other code. It was only some years later that I read about the term "refactoring" and about Martin Fowler's book on the subject. I'm sure others must have discovered the concept similarly. Anyway, interesting incident.
- vram22 8y ago
  >In a very relaxed way, without any tension, taking my time for each small change, so I was fairly sure that each small refactoring change did not change the meaning or correctness of the program. Unlike the rushed, tense way in which some (many?) projects are conducted these days (and plenty earlier too), with people playing whack-a-mole with bugs introduced by said rush, "because we have to ship last week".

by cblum 8y ago

freedomben 8y ago

Oh man, I feel exactly the same my friend. People who have never gotten into the C world find it frightening, but it's a beautifully simple language loaded with (at times dangerous) power. It's so much closer to the hardware that you can't use a declarative approach easily (which now that I've drunk the functional programming kool-aid, I do love), but in many ways it's actually much simpler to understand. You can also be pretty declarative if you are just smart about breaking things into functions. I still glance longingly at my dusty paper copy of The Linux Programming Interface (https://nostarch.com/tlpi https://nostarch.com/tlpi) /nostalgia

mpweiher 8y ago
> beautifully simple language :-) Of course there are those who claim it is actually frightfully complex, when it is those same people who are re-interpreting the standards to actually create that very complexity.
- cblum 8y ago
  Not sure if this is what you meant, but a lot of the stuff they added to C in the latest standards really turn me off. C89 has a special place in my heart.
tombert 8y ago
Honestly, if you use one of the available GCs out there (like Boehm's), and give up on static typing, and heavily rely on function pointers, you can write C similar to how you'd write something like Haskell. Yes, it won't go as fast as it the most idiomatic C, and you can't really make an operating system if you have a GC, but really, how often do most of us actually write code that can't use a GC these days? Even with a GC, it'll still probably perform better than 90% of languages.
- cblum 8y ago
  At that point it's practically not C anymore :) I'm not a fan of adding GC to C. I've hard my fair share of stress caused by GC issues. It's great 99% of the time but when you run into performance issues caused by the GC it becomes a very very leaky abstraction.
  - tombert 8y ago
    I'm ok with it not being 70's-era C to be honest; I even with the extra stuff, I find the language to be fairly simple to pick up compared to C++. I haven't had any problem with performance with the Boehm GC personally, though for what I've used C for is not-real-time video processing stuff. I found I typically got better throughput using Boehm than I did when I was manually managing my memory, but for what I was using it for, a small pause wasn't really a problem as long as the throughput wasn't really affected.
  - kevin_thibedeau 8y ago
    One may as well just use C# without classes.
    - n4r9 8y ago
      Pedantically speaking that's impossible. But loosely speaking that's the essence of how I write most of my C#.
- disishhsha 8y ago
  If you have a GC and no static typing, is it better than other functional languages (many of which have benefits of both GC and static typing)? Not a rhetorical question, I have never used a GC with C.
vardump 8y ago
> People who have never gotten into the C world find it frightening... I got into C over 25 years ago. Didn't find it frightening back then, but I sure do now. Still use it pretty often for firmware and kernel driver development, but I want to replace it with something safer. Then again, I also use assembler for same reasons... sometimes C just doesn't cut it for interrupt handlers when every cycle and/or code byte size counts.
- vectorEQ 8y ago
  > Still use it pretty often for firmware and kernel driver development, but I want to replace it with something safer. Then again, I also use assembler for same reasons... sometimes C just doesn't cut it for interrupt handlers when every cycle and/or code byte size counts. That's what you have ASM for :D j/k
- freedomben 8y ago
  > Didn't find it frightening back then, but I sure do now. Why is that? Security related stuff?
  - vardump 8y ago
    Yup. Things are increasingly connected to network. Including legacy codebases. Also when you have larger teams and more people touching the code, C can really shoot at your feet and elsewhere. From new and surprising angles.
    - freedomben 8y ago
      No doubt. It's amazing too how some code that was never expected to be exposed to untrusted/unsanitized data gets re-factored into a new spot or called from somewhere else, and fails to provide sanitation expecting that the callee will do it, or simply forgetting altogether (easy when under pressure to deliver). I coded a pretty bad security hole myself once by doing something like that, and I am a security specialist that knows what to look for lol! I love C, but it really is a security nightmare full of footguns.
vectorEQ 8y ago
i still only code in C, didn't start in the stone ages, but i love it. C and asm give me the feeling i'm programming my computer, and really for low level stuff trying to find a good alternative which is as good and simple (yes simple :D c/asm is just pure logic!) is difficult for me. I don't code professionally though, since i can't for the life of me find a job in C which doesn't have already tons of guys like you guys with a century of experience in the language lining up to take it :D C/asm is awesome, can't bare anything else

zozbot123 8y ago

> ...But there was a beauty to that. A simple mental model. A sense of control. There's something to that, I think. And it's still an open question whether the newer languages that are in development at present will succeed in bringing some of that underlying "beauty" back. It's an important issue if we want lower-level programming to be more widely accessible. (To clarify - the underlying machine model of C is beautifully simple, and newer low-level languages tend to be built on something very much like it anyway. The C language itself is frightfully complex - albeit less so than that other language in the C family that's often conflated with it.)

ineedasername 8y ago
I wonder if, now that processor speeds are increasing at a much slower rate, there will be a return to that lower level programming to focus on speed improvements through more efficient code.
p1esk 8y ago
I bet that's what some people were saying referring to assembly when C came out :)
- AnimalMuppet 8y ago
  People said it about assembly when it came out. The actual (binary or octal) machine codes gave you an intimacy with the hardware that assembly took away. (People actually said that.)
  - p1esk 8y ago
    If you like "intimacy with hardware" you can drop down one level below machine code and design a processor on an FPGA with Verilog. Or, to go even deeper, design a custom circuit with SPICE. C might be the optimal point on the abstraction ladder as far as the trade off between (exposed) complexity and control.
    - AnimalMuppet 8y ago

devenson 8y ago

Golang gives me that same C feeling.

agumonkey 8y ago
Russ Cox articles do have that simple and defined quality of old days.
cblum 8y ago
I've been slowly making my way through A Tour of Go and I really like what I've seen so far.
- romeisendcoming 8y ago
  Funny. I looked through the GO book and walked away feeling justified in being diligent with C. Maybe that's because I dislike jumping through other peoples hoops when I know better.
jxub 8y ago
The GC and goroutines make it more abstracted from the metal than it looks, while lacking the conveniences of the zero-cost abstractions available in lower-level languages like Rust. The only upside of taking the opposite side of the Rust tradeoff is compile time.
- zozbot123 8y ago
  > The only upside of taking the opposite side of the Rust tradeoff is compile time. Not so, there are a few specialized domains where having tracing GC easily available is genuinely useful. (Pretty much anything having to do with general graphs - the sort of stuff you'd traditionally use LISP for!) Go is a great fit for these use cases.
- freyir 8y ago
  It still gives me the feel of C, despite the abstractions (which I generally appreciate). Rust is like something else entirely.

fit2rule 8y ago

This is why I feel that the solution to most of the modern ailments in development is to just put Lua everywhere. All the great stuff of C, and all the new-school shit too. If you do this, it'll seem soon enough that the Javascript nightmare was just a dream. Takes balls though.

cblum 8y ago
I wish! One of the coolest projects I've worked on used Lua. We wrote the core in C++ and then everything else on top of it in Lua.
sifoobar 8y ago
I do the same thing with a twist [0], since I'm not very fond of some of Lua's design choices. Lack of a decent type system, the table mess, etc. And I think Forth and Lisp make better glue languages. Can't stop smiling these days when I see people fighting over which language will rule them all. I spent tens of years searching for that language myself. Time I would rather have spent solving real problems using the best tools. [0] https://gitlab.com/sifoo/snigl https://gitlab.com/sifoo/snigl
bogomipz 8y ago
What would some examples be of Lua addressing modern ailments? I'm also curious to hear why it's such a good fit for those ailments. Thanks.
- fit2rule 8y ago
  Its not Lua specifically addressing modern ailments, its the attitude that taking full control to put the same common codebase on as many of the target platforms as possible can be profitable, in light of the vendor mess which is, presumably, what we're talking about here. It can be a very disturbing thing to realise what a few tweaks here and there to package.json might do to ones love life. Lua is a great, easy to use, easy to apply, language -- with a healthy framework ecosystem, and it is very easy to put it to use in a legacy code-base, since its C-based, and we all know that C still makes the world go around. However, its not the fact of Lua, but the fact of 'put our own VM everywhere' that wins, imho.

justadudeama 8y ago

James Mickens has a great part of a talk where he talks about this: https://youtu.be/7Nj9ZjwOdFQ?t=1574 https://youtu.be/7Nj9ZjwOdFQ?t=1574 A little too close to home.

agumonkey 8y ago
I was about to say "warning, these are the kind of talks that will revive COBOL.. "

stallmanifold 8y ago

This is one reason I wonder whether there is room in the world for a better C. Low complexity programming languages with a simple machine mental model along the lines of Go (or perhaps in future, Zig and Jai?) for doing systems programming, with a strong static type system, and a rock solid build system. Early in my career I did a lot of bare metal and embedded systems programming and the one thing I miss about C is the predictable assembly output. I primarily use Rust for this purpose right now but I wonder if there's a place for something simpler for doing really low level stuff (i.e. programming hardware directly, device drivers) that's better than C. EDIT: grammar.

AndyKelley 8y ago
> I wonder if there's a place for something simpler for doing really low level stuff (i.e. programming hardware directly, device drivers) that's better than C. Like this? https://andrewkelley.me/post/zig-stack-traces-kernel-panic-bare-bones-os.html https://andrewkelley.me/post/zig-stack-traces-kernel-panic-b...
- christophilus 8y ago
  I like Zig. Have you tried it? I’d be interested in hearing about your experience. I haven’t been able to think of a project to use it for, though, as all of my work these days is web related.
  - dinglejungle 8y ago
    (you replied to the creator of Zig, fyi)
    - deleted 8y ago
      [deleted]
    - christophilus 8y ago
      facepalm I need to start looking at usernames before replying!

booknomads 8y ago

I miss it so much.. btw if you haven't check out Casey Muratori's Handmade Hero on youtube, it will fill you with joy.

reza_n 8y ago

We are always hiring full time C developers doing exactly what you said. Msg me if you (anyone) is interested.

pnw_hazor 8y ago
I see the insides of a lot of startups. The C/C++ based companies generally seem to be solving serious problems with good engineering. Startups using frothier tech are often (not always) toy companies building toy products (hyper-scale toys are still toys).

pnw_hazor 8y ago

Programming is kind of joke these days. Each time a new "hotness" language, framework, pattern, or dev/devops process comes out you have a rush of professional gurus working hard to build their business (e.g., speaking fees/books/blogging/training) by teaching that this is the new true way. In the late 90's I began to notice how the new kids kept advocating for the newest so-called best practices to do things that the bad-old practices could handle just fine. Seeing the writing on the wall, I dipped out of the game a few years later. Unfortunately, the unhelpful tech churn has worsened. Similarly, the quality of the product produced has worsened, or at best, not improved. Note, hyper-scale advertisement services, global human tracking, and digital Skinner boxes are not an improvement to anything. Meanwhile 50 year-old programmers with deep general development knowledge cannot find jobs. I guess it is easier for young founders to justify using frothy tech if there are fewer old-timers around to suggest otherwise. edit-to-add: /get-off-my-lawn

zozbot123 8y ago
There's a lot of BS, but there are some real improvements as well. Many innovations that are considered best practices today actually came out in the 1990s. The Java programming language became incredibly popular, being a machine-independent, memory-safe language and system that could deal out-of-the-box with concurrency and networking-- The Go of its day, to some extent (and indeed it had a whole lot in common with Go's predecessors, Alef and Limbo). Functional programming was popularized around that time. The C++ standard introduced us to the notion of zero-overhead abstractions combined with strong static checking, which Rust is refining today. And of course, the Web became widespread around that time, as well. Whatever you might think about "hyper-scale advertisement services, global human tracking, and digital Skinner boxes", Amazon first became prominent in the dotcom era, and it's quite massive today.
- pnw_hazor 8y ago
  I have been reacquainting myself with some so-called best practices as I muddle through my recent side-projects. While some newer languages are interesting, the dev stacks today are a mess. Also, While we have safe pointers and GC everywhere, the lack of technical discipline/professionalism in the industry is worse than ever. I recognize that the C-suite and VCs share in the blame for this, but devs are the ones building things and evangelizing the newest-hotness that comes onto the scene. But I do have to remind myself that compared to traditional engineering tracks, software engineering is still in its infancy. /get-off-my-lawn

SlowRobotAhead 8y ago

Pssst, come over to embedded. We’re in C all day long using kilobytes not gigabytes. I don’t need to chase the latest framework... but I’m also on my own for almost everything. Pros and Cons, but I wouldn’t leave it for anything web related.

bitwize 8y ago
The Rust Evangelism Strike Force is gunning for the embedded space, too. As soon as the tooling becomes widespread enough to support the most-used microcontrollers, C will be a niche language even in embedded.
- ThenAsNow 8y ago
  Was this comment meant pejoratively?
- SlowRobotAhead 8y ago
  Yea... We'll see. Rust has had quite awhile to make an attempt at Embedded and unless you count drivers for a couple STMs and a few other (mostly outdated) chips - I haven't seen a single thing that says progress. I'd like to see Rust happen, because I don't see C++ as the embedded future. At least Rust had the good sense to leave garbage collection out. However... I'll believe it when I see it. And by that, I mean when STM and Nordic and NXP and others are pushing out their own Rust device support files on their sites. When Keil or IAR or Rowley or Atollic pushes out a full featured IDE that uses a Rust compiler. When Rust is not only supporting the latest run of chips but there is a way to debug them with code-overlay. But until then...
  - steveklabnik 8y ago
    The biggest are of progress has been in using those devices as a test bed to stabilize features working on embedded generally. You can now develop for those devices on stable, which is a huge advantage.
  - pjmlp 8y ago
    > I don't see C++ as the embedded future. AUTOSAR moved from C to C++14 as the certified language. mbed is written in C++.

entelechy0 8y ago

You can relive the dream if you believe. I still operate in makefiles and shell scripts to this day.

Teknoman117 8y ago

Debugging was harder as compared to what? I'll take debugging C over modern C++ any day...

vram22 8y ago

>Man, I miss making a living as a C programmer. Same here. I worked quite a lot on C on Unix and some on Windows (including working on a successful database middleware product on Windows, which was used in some VB+Sybase/Oracle client-server projects) before I got into other languages like Java, Ruby (and Rails) and now Python for quite a while. Great fun working in C, although of course frustrating at times too, debugging weird issues. Also, somehow, I never found working with pointers (at least for simple to intermediate uses of them) confusing, like some do. (I once taught a C programming class at a large public sector company; while I was explaining the int main(int argc, char argv stuff, and the pointer to pointer stuff, the head of their IT dept. who was in the class, said "now it is 'overhead transmission' :)". Maybe I didn't have trouble with pointers because I had some hobbyist assembly language programming background from earlier, including learning about different addressing modes, such as direct, indirect, indexed indirect (or vice versa) (on the 6502 processor), etc., plus used to read a lot on my own about microprocessors, computer architecture, and suchlike related areas, even though they were not directly relevant to my higher-level application programming work (hint hint, to kids learning computers today). Working close to the machine is good. Also, a bit off topic, I kind of independently discovered the concept of refactoring. I was in a nice relaxed state one afternoon, at work, after a good lunch, but not heavy, so not drowsy, working on some Unix C program (likely a CLI one), and over a period of time, I noticed that I had been making small (behavior-preserving) incremental improvements to the code, one after another. In a very relaxed way, without any tension, taking my time for each small change, so I was fairly sure that each small refactoring change did not change the meaning or correctness of the program. Thought that was a good technique after I realized that I had been doing it. Unfortunately did not keep doing it with other code. It was only some years later that I read about the term "refactoring" and about Martin Fowler's book on the subject. I'm sure others must have discovered the concept similarly. Anyway, interesting incident.

vram22 8y ago
>In a very relaxed way, without any tension, taking my time for each small change, so I was fairly sure that each small refactoring change did not change the meaning or correctness of the program. Unlike the rushed, tense way in which some (many?) projects are conducted these days (and plenty earlier too), with people playing whack-a-mole with bugs introduced by said rush, "because we have to ship last week".