Live data from Hacker News

Switching to C over 'Modern' Programming Languages

devtails.xyz

111–120 of 170 posts

Re: Switching to C over 'Modern' Programming Languages

#111
post #89
post #86

Earlier quoted context omitted.

> It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use. Well, not sure about the LISP programmers, but C programmers have a good reason: they work under different environments (from embedded to Windows, legacy UNIX, the latest Ubuntu, ...) and also have different needs, regar…

What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want. The only problem is C is simply not expressive enough to have proper abstractions like that.

Last time I checked "Formatting is Unreasonably Expensive for Embedded Rust" (1)

And/or you need a crate like alloc, heapless, etc.

For the sake of a sprintf "abstraction"...

(1) https://jamesmunns.com/blog/fmt-unreasonably-expensive/

Re: Switching to C over 'Modern' Programming Languages

#112
post #107

Earlier quoted context omitted.

They literally cannot. For one, neither C++ or Rust conform to standard C, meaning they already deviate from what C does on a basic level. Their industry uses are highly different as well. C is almost a requirement for embedded systems, and while C++/Rust can be used there, they’re simply too complex and in Rust’s case additionally too young to be adopted. C++, and possibly Rust (if it can get its act together), are…

So your answer is “because they are not C”…? What does language complexity has to do with anything? It will get compiled down to machine code, and both can be and are used for embedded. They occupy the exact same low-level niche as C, hell, they may be even more level as they can also do things like SIMD. Linux kernel is C because Linus doesn’t like C++, it’s that easy. And usually no, why would you use multiple lang…

It is quite difficult to write idiomatic C++ without memory allocation, for one, which is often a requirement for embedded code or any high-availability code that is not allowed to have memory fragmentation.

Sure, it's possible (you can write C in C++, for the most part, and to its credit, C++ has placement new). But many of C++'s niceties require memory allocation, making much of its value-add over C questionable.

Re: Switching to C over 'Modern' Programming Languages

#113

Earlier quoted context omitted.

They literally cannot. For one, neither C++ or Rust conform to standard C, meaning they already deviate from what C does on a basic level. Their industry uses are highly different as well. C is almost a requirement for embedded systems, and while C++/Rust can be used there, they’re simply too complex and in Rust’s case additionally too young to be adopted. C++, and possibly Rust (if it can get its act together), are…

Linux isn't written in standard C. Not only does it not accept C's aliasing rules (hence the kernel is compiled with them disabled, which the standard doesn't offer), it doesn't even accept the memory model, because it had its own memory model first and it likes that one better. As a result to some extent GCC and Clang are also compilers for some sort of "Linux C" which is strongly reminiscent of the ISO standard lan…

I'll just leave this here: https://lkml.org/lkml/2018/6/5/769 ;p

And maybe this: https://dl.acm.org/doi/10.1145/3477113.3487274

Re: Switching to C over 'Modern' Programming Languages

#114
post #89
post #86

Earlier quoted context omitted.

> It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use. Well, not sure about the LISP programmers, but C programmers have a good reason: they work under different environments (from embedded to Windows, legacy UNIX, the latest Ubuntu, ...) and also have different needs, regar…

What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want. The only problem is C is simply not expressive enough to have proper abstractions like that.

If all you do is write code on Linux/Windows/MacOS, C++ strings might be fine. Things are different in the wider world. Many places I use C don't even have a C++ compiler (embedded, in particular).

Re: Switching to C over 'Modern' Programming Languages

#115

Earlier quoted context omitted.

> C gives you enough rope to shoot yourself in the foot. If this was intended to illustrate the unexpected consequences of undefined behavior it succeeded remarkably well!

Undefined Behaviour was a very late 'addition' to C, it only became necessary when C was standardised around 1990. And only after two more decades passed, UB became an actual problem when compiler vendors decided that it's fine to exploit it for optimization tricks.

“Decided that it’s fine to exploit it for optimisation tricks” is a poor characterisation. The reality is, if you define particular behaviours you will harm performance in some cases. If you define how something in particular should happen, then all architectures will need to implement that, regardless of their underlying semantics.

eg. C leaves the case of exceeding the size of an int undefined. In most cases it has a predictable effect on modern, mostly similar architectures but that is by no means guaranteed, and forcing an architecture to calculate overflow a particular way seems like a negative.

That being said, everyone has a pet example of a compiler doing some really odd and deep optimisations - I suspect that’s mostly due to successive layers and optimisers adding up to have unexpected effects, rather than a deliberate effort by compiler writers - but I’m no expert on the matter.

Re: Switching to C over 'Modern' Programming Languages

#116

Earlier quoted context omitted.

"Rust forces me to think a little bit more [..]" My reaction to that has always been that it forces us to think about the things we would have had to think anyways if we wanted to create reasonably reliable and secure software. So in the end if saves work, even if it doesn't appear like that at first.

The other side of the medal (especially for game development), is that in the higher level parts of game code you need quick turnaround times for experimentation and tweaking, and most of that code won't even make it into the final product (so all the upfront time you spent thinking about proper architecture and ownership details is wasted up there). The traditional solution is to have different languages for differe…

I wish there was a language that is to JavaScript/TypeScript/Python/Lua what Rust is to C++/C/Java.

Re: Switching to C over 'Modern' Programming Languages

#117
post #73
post #36

Earlier quoted context omitted.

I'm a C programmer by day and I disagree with them, C is only simple if you're trying to do simple tasks with it. The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change i…

> The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change it to a longer string. But then how do I store the buffer size? As a C programmer shouldn't you have a library ab…

My c knowledge is obviously old. I wonder if the author is lamenting the lack of a "modern" string manipulation in the standard library beyond just working on char buffers?

Re: Switching to C over 'Modern' Programming Languages

#118

Earlier quoted context omitted.

The other side of the medal (especially for game development), is that in the higher level parts of game code you need quick turnaround times for experimentation and tweaking, and most of that code won't even make it into the final product (so all the upfront time you spent thinking about proper architecture and ownership details is wasted up there). The traditional solution is to have different languages for differe…

I wish there was a language that is to JavaScript/TypeScript/Python/Lua what Rust is to C++/C/Java.

I'm not personally familiar with it, but I think you want to take a look at Elixir. I've heard it often in the same vein as Rust but for web. Not exactly the same, but in terms of a high-quality language.

https://elixir-lang.org/

https://www.phoenixframework.org/

Re: Switching to C over 'Modern' Programming Languages

#119
For some time I think about using Rust, but in a cut down manner. Ignore Cargo and most of its stdlib. Not to use traits. Allow myself to use unsafe once in a while. Basically a subset of Rust that would be just safer-C. I wonder if that would be effective for me. Maybe even compile times would be acceptable. I guess, I must just try.

I am one of those that tried Rust, but guess back to C for my own projects. It's usually that I like to write smaller utilities and many quirks of C are not as painful. I like to write things that do not use dynamically allocated memory for example. Also plethora of available alternative C compilers for example something using QBE gives me a nice warm feeling. Yes, it is not all technical for me.

Re: Switching to C over 'Modern' Programming Languages

#120
post #51

I used to love C for its simplicity. There was just no surprises, and the limited feature set enforced a certain programming style that also happens to run very well on modern CPUs. But the C standard library is just awful. It's so inconsistent and full of quirks you just have to know. Like how some string functions allow you to specify a size, while others don't. And how strtok keeps track of an internal state and b…

check out hare-lang.org (still wip, but quite good already)
Post reply on HN