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

C meeting is over. C23 added:

twitter.com

Post reply on HN
Print view View original

81–90 of 363 posts

Re: C meeting is over. C23 added:

#81

Post by dureuill »

donkarma wrote: post #75
dureuill wrote: post #61

Earlier quoted context omitted.

You could get productive in Rust in 3 months max, and then the productivity gains would quickly outweigh the initial investment

Rust code takes longer to write than C code

My experience is mainly with C++, but from my own evaluation I'm x2 to x3 more productive overall in Rust than in C++. The reasons are a simpler build system that makes using the ecosystem faster, more expressive type system (iterators with combinators, sum types), the safety part that allows to not accidentally introduce UB and to not waste time with static and runtime analysis, shortening debug and review time. This compounds over time to give a better maintenance time.

I don't have a similar evaluation for C Rust, but I suspect the result would be even more skewed in Rust's favor: sure, you might be writing individual lines faster in C, but the lack of iterators, generics, traits and RAII, and the relative difficulty to use dependencies means that you will waste a lot of time reinventing the wheel, often suboptimally.

Re: C meeting is over. C23 added:

#82

Post by OJFord »

flyinglizard wrote: post #53
bruce343434 wrote: post #39

Earlier quoted context omitted.

I'm going for C, because I am experienced with C and despite it being more tedious, with having to do everything yourself, I stick with it because the compile times, and in fact the compile process, are so much faster and simpler. I really enjoy the direct feedback I can get. I considered C++ but that too had terrible compile times. Ideally a debug build should simply not take longer than 100ms for a codebase that is…

Why does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.

Are your rust builds really that fast? Wth am I doing wrong! I'd love to measure it in seconds.

Re: C meeting is over. C23 added:

#83

Post by pornel »

kstenerud wrote: post #15
mungoman2 wrote: post #2

I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?

I will. C is everywhere and is not going away (it's #2 on TIOBE and on the rise again). Now that fewer people are learning it, I get more juicy contracts.

C is probably still popular, but TIOBE is less accurate than a horoscope.

TIOBE index shows C has lost 62% of its users in 2016-2018, then almost tripled in popularity next year, and then again lost almost half of its users.

Do you think such swing of popularity is possible for such an established slow-moving language? I don't think so — it just shows how far TIOBE can diverge from reality, and that the error bars on the index should be +/- 50%. A few % blip means nothing. TIOBE is measuring rollouts of new Google search algorithms, not language popularity.

Re: C meeting is over. C23 added:

#84

Post by gefhfffh »

bruce343434 wrote: post #65
gefhfffh wrote: post #43

Earlier quoted context omitted.

I get that the compile process is faster, but simpler? In my experience, the compile process usually consists of "cargo build" A advantage of Rust is that usually you spend way less time debugging, because the compiler prevents many mistakes from compiling in the first place.

I have an IDE with clang-lint and I find that it can spot pretty much every mistake. It can even detect some lifetime issues. Other than that my programming style is very much pass-by-value, trust the compiler to inline it, so the typical memory safety issues are simply not relevant to me.

Before I tried Rust (I got sick of it and the slow progress of Herb Sutter's research), I have used CLion with clang-tidy and had plenty of memory issues going undetected.

Needless to say I didn't restrict myself to pass-by-value (compatible -> structs with ptrs are problematic as well) style, which seems quite restrictive

Re: C meeting is over. C23 added:

#85

Post by WithinReason »

10x-dev wrote: post #72
WithinReason wrote: post #40

Earlier quoted context omitted.

Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?

Control over the code that actually runs. We already lose quite a bit of control with C (e.g. it reorders your code as it pleases) to gain portability across CPUs, otherwise we'd have to rewrite the code in several assembly languages. If you consciously choose to give up even more control over the code that runs (because a compiler that targets C necessarily adds another layer of autogenerated code that you don't con…

The downside of reordering being performance? Or something else?

Re: C meeting is over. C23 added:

#86

Post by 10x-dev »

kaba0 wrote: post #64
10x-dev wrote: post #32

Earlier quoted context omitted.

C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the metal, with excellent debugging support, portability and integrations. No other language has been battle tested for longer and more extensively than C. Your kernels, OSes, drivers, databases, web servers and compilers are written in C. If some of these featur…

C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it. C is not any closer t…

Are you going to mix all those languages into one project and somehow use their advantages but steer away from their disadvantages?

Sure, other languages have caught up or have improved on some of the features where C shines.

Let's remove portability and integration from the feature list, because that's strongly related to C's tenure.

Which one of the languages you listed matches the rest of the feature set I brought up?

  * Small language
  * Fast compile times
  * Fast binaries
  * Small binaries
  * Great debugging experience
  * Close to the metal
In my opinion, they all fail in at least one category, and that's expected - additional functionality can't come for free. You can only accept its cost.

Re: C meeting is over. C23 added:

#87

Post by WithinReason »

DyslexicAtheist wrote: post #79
WithinReason wrote: post #41

Earlier quoted context omitted.

Is it a good summary that the only reason for deciding for C instead of Rust/Nim/Zig is that not enough programmers know Rust/Nim/Zig?

imo not the only reason but it's the most cited one by those who give me a budget and limit my freedom to use the tool I personally think is right for the job. just because I can sell an engineering audience on my (IMHO correct but artisanal) views doesn't mean it's what is best for the business. Because they know the moment they come back "crying" saying "we can't find anyone with these skills" I'll consider it as t…

Well then "legacy reasons" cited by GGGP was actually right. That's what I was wondering as well.

Re: C meeting is over. C23 added:

#89

Post by drran »

donkarma wrote: post #75
dureuill wrote: post #61

Earlier quoted context omitted.

You could get productive in Rust in 3 months max, and then the productivity gains would quickly outweigh the initial investment

Rust code takes longer to write than C code

Total time of «coding + debugging» (development time) is shorter for safe Rust, because Rust eliminates few classes of errors. Unsafe Rust and C are same, but Rust have better abstractions (match operator, Rust enum's, typed macros, etc.)

Re: C meeting is over. C23 added:

#90

Post by pornel »

dkjaudyeqooe wrote: post #10
mungoman2 wrote: post #2

I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?

C is a portable alternative to assembly language.

Where's my overflow flag?
Post reply on HN