Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I stopped everything and started writing C again

kmx.io

Post reply on HN
Print view View original

101–110 of 475 posts

Re: I stopped everything and started writing C again

#101

Post by baq »

codr7 wrote: post #99
baq wrote: post #19

Earlier quoted context omitted.

Rust has three major issues: - compile times - compile times - compile times Not a problem for small utilities, but once you start pulling dependencies... pain is felt.

Compared to C I'd say the biggest issue is complexity, of which compile time is a consequence.

The C standard makes provisions for compiler implementers which absolve them from responsibility of ignoring the complexity of the C language. Since most people never actually learn all the undefined behavior specified in the standard and compilers allow it, it might seem the language is simpler, but it's actually only compilers which are simpler.

You can argue that Rust generics are a trivial example of increased complexity vs the C language and I'd kinda agree: except the language would be cumbersome to use without them but with all the undefined C behavior defined. Complexity can't disappear, it can be moved around.

Re: I stopped everything and started writing C again

#102

Post by dgacmu »

johnisgood wrote: post #40
dgacmu wrote: post #38

Earlier quoted context omitted.

Correctness is not just about security. And the threat environment to which a program may eventually be exposed is not always obvious up front. Also, no: that's only true for some kinds of programs. Rust, c++, and go all have a much easier ecosystem for things like data structures and more complex libraries that make writing many programs much easier than in C. The only place I find C still useful over one of the oth…

> much easier ecosystem for things like data structures and more complex libraries that make writing many programs much easier than in C. So many people have implemented those data structures though, and they are available freely and openly, you can choose to your liking, i.e. ohash, or uthash, or khash, etc. and that is only for a hash table. Those complex libraries are out there, too, for C, obviously. The reason f…

There are! But composability is easier in the languages that have generics/templates/etc. There's less passing around of function pointers and writing of custom comparator functions, using something like binary search or sort as an example, and the fact that those comparators can be inlined can often make the rust or C++ version faster than the "as simple to write" C version.

Obviously, all of these languages are capable of doing anything the others can. Turing complete is turing complete. But compare the experience of writing a multithreaded program that has, as part of it, an embedded HTTP server that provides statistics as it runs. It's painful in C, fairly annoying in C++ unless you match well to some existing framework, pretty straightforward in Rust, and kinda trivial in Go.

Re: I stopped everything and started writing C again

#104

Post by anta40 »

randomNumber7 wrote: post #27

Despite what some people religiously think about programming languages, imo C was so successful because it is practical. Yes it is unsafe and you can do absurd things. But it also doesn't get in the way of just doing what you want to do.

If you want to do microcontroller/embedded, I think C it still the overall best choice, supported by vendors. Rust and Ada are probably slowly catching up.

Re: I stopped everything and started writing C again

#105

Post by irq-1 »

kokada wrote: post #71
brucehoult wrote: post #26

Earlier quoted context omitted.

Try doing C with a garbage collector ... it's very liberating. Do `#include ` then just use `GC_malloc()` instead of `malloc()` and never free. And add `-lgc` to linking. It's already there on most systems these days, lots of things use it. You can add some efficiency by `GC_free()` in cases where you're really really sure, but it's entirely optional, and adds a lot of danger. Using `GC_malloc_atomic()` also adds eff…

I think one of the nice things about C is that since the language was not designed to abstract e.g.: heap is that it is really easy to replace manual memory management with GC or any other approach to manage memory, because most APIs expects to be called with `malloc()` when heap allocation is needed. I think the only other language that has a similar property is Zig.

Odin has this too:

> Odin is a manual memory management based language. This means that Odin programmers must manage their own memory, allocations, and tracking. To aid with memory management, Odin has huge support for custom allocators, especially through the implicit context system.

https://odin-lang.org/docs/overview/#implicit-context-system

Re: I stopped everything and started writing C again

#106

Post by johnisgood »

dgacmu wrote: post #102
johnisgood wrote: post #40

Earlier quoted context omitted.

> much easier ecosystem for things like data structures and more complex libraries that make writing many programs much easier than in C. So many people have implemented those data structures though, and they are available freely and openly, you can choose to your liking, i.e. ohash, or uthash, or khash, etc. and that is only for a hash table. Those complex libraries are out there, too, for C, obviously. The reason f…

There are! But composability is easier in the languages that have generics/templates/etc. There's less passing around of function pointers and writing of custom comparator functions, using something like binary search or sort as an example, and the fact that those comparators can be inlined can often make the rust or C++ version faster than the "as simple to write" C version. Obviously, all of these languages are cap…

When it comes to multithreaded programs, I much prefer Go over C, too. :)

Re: I stopped everything and started writing C again

#107

Post by saati »

kqr wrote: post #8

I started programming with C a long time ago, and even now, every few months, I dream of going back to those roots. It was so simple. You wrote code, you knew roughly which instructions it translated to, and there you went! Then I try actually going through the motions of writing a production-grade application in C and I realise why I left it behind all those years ago. There's just so much stuff one has to do on one…

> You wrote code, you knew roughly which instructions it translated to, and there you went!

This must have been a very very long time ago, with optimizing compilers you don't really know even if they will emit any instructions.

Re: I stopped everything and started writing C again

#108

Post by codr7 »

baq wrote: post #101
codr7 wrote: post #99

Earlier quoted context omitted.

Compared to C I'd say the biggest issue is complexity, of which compile time is a consequence.

The C standard makes provisions for compiler implementers which absolve them from responsibility of ignoring the complexity of the C language. Since most people never actually learn all the undefined behavior specified in the standard and compilers allow it, it might seem the language is simpler, but it's actually only compilers which are simpler. You can argue that Rust generics are a trivial example of increased co…

True, if C wanted to be Rust it would be just as complicated.

But who cares?

The fact that C chooses not to nail everything down makes it a simpler and more flexible language, which is why it's sometimes preferred.

Re: I stopped everything and started writing C again

#109

Post by kokada »

irq-1 wrote: post #105
kokada wrote: post #71

Earlier quoted context omitted.

I think one of the nice things about C is that since the language was not designed to abstract e.g.: heap is that it is really easy to replace manual memory management with GC or any other approach to manage memory, because most APIs expects to be called with `malloc()` when heap allocation is needed. I think the only other language that has a similar property is Zig.

Odin has this too: > Odin is a manual memory management based language. This means that Odin programmers must manage their own memory, allocations, and tracking. To aid with memory management, Odin has huge support for custom allocators, especially through the implicit context system. https://odin-lang.org/docs/overview/#implicit-context-system

Interesting that I was thinking of a language that combined Zig and Scala to allocate memory using implicits and this looks exactly what I was thinking.

Not that I actually think this is a good idea (I think the explicitly style of Zig is better), but it is an idea nonetheless.

Re: I stopped everything and started writing C again

#110

Post by ryandrake »

codr7 wrote: post #93
markus_zhang wrote: post #44

C, or more precisely a constrained C++ is my go to language for side projects. Just pick the right projects and the language shines.

I've tried, but never succeeded in doing that; the complexity eventually seeps in through the cracks. C++'s stdlib contains a lot of convenient features, writing them myself and pretending they aren't there is very difficult. Disabling exceptions is possible, but will come back to bite you the second you want to pull in external code. You also lose some of the flexibility of C, unions become more complicated, struct…

> C++'s stdlib contains a lot of convenient features, writing them myself and pretending they aren't there is very difficult.

I've never understood the motivation behind writing something in C++, but avoiding the standard library. Sure, it's possible to do, but to me, they are inseparable. The basic data types and algorithms provided by the standard library are major reasons to choose the language. They are relatively lightweight and memory-efficient. They are easy to include and link into your program. They are well understood by other C++ programmers--no training required. Throughout my career, I've had to work in places where they had a "No Standard Library" rule, but that just meant they implemented their own, and in all cases the custom library was worse. (Also, none of the companies could articulate a reason for why they chose to re-implement the standard library poorly--It was always blamed on some graybeard who left the company decades ago.)

Choosing C++ without the standard library seems like going skiing, but deliberately using only one ski.

Post reply on HN