Hacker News Reader

Comment by Certhas | Hacker News Reader

Absolutely. The public sales pitch did not match the reality. This is what I meant with the "Claim to be Ṕython to get VC money" point.

To first order, today every programmer starts out as a Python programmer. Python is _the_ teaching language now. The jump from Python to C/Cpp is pretty drastic, I don't think that it's absurd that learning Mojo concepts step by step coming from Python is simpler than learning C. Not syntactically but conceptually.

View on HN

Maybe young generations have some issue learning polyglot programming, I guess.

While I agree using Mojo is much preferable to writing C or C++ native extensions, back on my day people learned to program in K&R C or C++ ARM in high school, kids around 12 years old, hardly something pretty drastic.

No wonder there's so much terrible unsafe C floating around...

Many famous Speccy and C64 titles, written in Assembly, were written by bedroom coders between the ages of 14 and 16 years old, getting some pocket money writing them on the UK scene.

Get hold of Retro Gamer magazine for some of their stories.

I've tried learning C a couple times and given up because the curve is too steep to be worth the climb. It's not even the language itself, it's the inherited weight of half a century's worth of cruft. I can't spend weeks fighting with compiler nonsense, header files and #include. Screw it, I'll just use Go instead.

I'm learning Rust and Zig in the hope that I'll never have to write a line of C in my career.

Geez, what a comment. C is much much more simpler than Rust. You’re not supposed to be spending weeks fighting includes or compiler errors, that means you’re have some very basic misconceptions about the language.

Just read K&R “The C programming language” book. It’s fairly small and it’s a very good introduction to C.

Agreed, I do bash C a lot, and it has plenty of issues, but hardly a monster that a mythological hero has to face.

And as tip for pointers, regardless of the programming language, pen and paper, drawing boxes and arrows, are great learning tools.

I do sympathize with the parent: The language itself might not be that difficult but you also have to factor in the entire ecosystem. What's the modern way to a build a GUI application in C? What's the recommended way to build a CLI, short of writing your own arg parser? How do you handle Unicode? How do you manage dependencies, short of vendoring them? Etc.

Even more than that: "How do you do a string?" has like 100 answers in C depending on what libraries are available, what your deploy target is...

Errors too. When, inevitably, you make mistakes the C might just compile despite being nonsense, or you might get incomprehensible diagnostics. Rust went out of its way to deliver great results here.

I am not arguing about how good or easy it is to use C in production, I’m merely stating that parent complaints about weeks of insolvable errors and issues with includes screams that he needs to read some good resource like book, because he is definitely misunderstanding something important.

C syntactically is straight forward, but conceptually may be harder than Rust. You’re exposed to the bare computer (memory management, etc) far more than with a GC language or even Rust arguably, at least for simple programs.

Towards deployment is even harder. You can very easily end up writing exploitable, unsafe code in C.

If I were a Python programmer with little knowledge about how a computer works, I’d much prefer Go or Rust (in that order) to C.

Rust memory model is very complicated. C memory model is very straightforward.

C before C11 has no memory model. Rust doesn't have one but effectively it inherits the C++/C memory model, so there is actually no difference.

The model you're referring to, a Memory Ordering Model, is literally the same model as Rust's. The "exception" is an ordering nobody knows how to implement which Rust just doesn't pretend to offer - a distinction which makes no difference.

That applies only if you take "memory model" to mean modeling the effects of concurrent accesses in multithreaded programs.

But the term could also be used more generally to include stuff like pointer provenance, Rust's "stacked borrows" etc. In that case, Rust is more complicated than C-as-specified. But C-in-reality is much more complicated, e.g. see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm

This is true, but when you get something wrong related to the memory model in C, it just says "segfault". Whereas in Rust it will give you a whole explanation for what went wrong and helpful suggestions on how to fix it. Or at the very least it will tell you where the problem is. This is the difference between "simple" and "easy".

Writing hello world in C is easy. Writing complex software without memory issues and vulnerability is pretty hard.

THe thing is, if one is an expert it is incredibly difficult to understand the beginner perspective. Here is one attempt:

C is simpler than Rust, but C is also _much_ simpler than Python. If I solve a problem in Python I have a good standard library of data types, and I use concepts like classes, iterators, generators, closures, etc... constantly. So if I move to Rust, I have access to the similar high-level tools, I just have to learn a few additional concepts for ressource management.

In comaprison, C looks a lot more alien from that perspective. Even starting with including library code from elsewhere.

Reply on news.ycombinator.com