[aslihana]

I liked this article so much.

But i want to attach something on your "some opinion" title's

> You should learn Zig (or C) before you learn Rust

part.

I had learned C before Rust but, vectors are not used in C. It belongs to C++. And although I know C, Rust is still very confusing to me. In my opinion, it would be better learn C++ before Rust.

[tialaramex]

I learned C a very long time ago, but I'm not at all confident that it would be better, starting now, to learn C first before I learned Rust. I think Rust's design is a cleaner foundation.

Example: (Destructive) Move assignment is the correct thing, if you introduce that to begin with, showing Copy as an optimization, I think that makes more sense than the way it's often taught knowing people are familiar with languages that default to (or only have) copy assignment.

Another example: Rust doesn't have boolean coercion, the boolean coercion is so rife that you find it in otherwise seemingly principled languages, but the consequences are quite awful - in Rust you can cheerfully teach the entire language without this concern, because Rust doesn't have this coercion. "false" is neither true nor false, it's a string, 0 is neither false nor true, it's an integer. Many modern languages avoid C's extreme coercions - you can't write "Ten" + 5 or 'a' + 1 in such languages, (in a few of them it's a concatenate operation, which I don't love either, but at least it's not some weird coercion) - but they still insist "false" is true because it seemed easier and C did it. Rust does not.

[hardware2win]

What do you mean that there are no vectora in C?

You mean by default?

[antoineMoPa]

std::vector is a C++ thing right? There is no vector standard in C as far as I know.

[tialaramex]

A more general name for this kind of thing is a growable array. The choice to name this "vector" is regrettable given the other things that word means, and the Rust name Vec is at least an improvement on that.

std::vector is famously the only C++ standard library container which isn't crap, but, the fun thing is that it's still a bit crap anyway. Like a lot of C++ standard library features it could be better, but that'd be an ABI break, so too bad either use somebody's custom replacement which is better or put up with the good-but-not-great std::vector

[moffkalast]

Well any newer language just seamlessly rolls that functionality into regular arrays and calls them lists, Java and C# call it an ArrayList. I'm not sure if there's a standard naming convention for it.

What really disqualifies C for anything practical these days is the strings. In that it has zero native support for them, they're not a first-class citizen as they damn well should be, they're a complete illegal alien. String.h is such a trainwreck from a UX perspective that I despise every minute I ever had to work with it. C++ at least has some out of the box support for them, even if it's very barebones and clunky af.

Like aside from getting an educational perspective of how incredibly limited and poorly designed languages used to be, there's no reason we should still be building our cars out of wood with stone wheels which is what using C (and C++ to some degree for that matter) feels like. For learning how processors and computers work at the lowest level, going with something like assembly on a microcontroller makes more sense anyway.

[tialaramex]

C++ 17's std::string_view is finally the table stakes bare minimum type, but notice that's a library feature so it's not actually part of the core language. std::string_view is approximately &[u8] that is, it's a non-owning reference to some bytes, it knows where the bytes are, and it knows how many of them. This means it's a fat pointer. In 1975 this was perhaps too expensive to be reasonable, it's 2023, we have enough registers, use a fat pointer and suck it up.

I would like more, indeed a lot more, but in a resolutely bit banging language I will put up with &[u8] and that's what std::string_view gives you in practice. The out-of-box string literal in C++ is unacceptable, as is std::string (an owning, growable string) used for read-only purposes. None of this stuff should have survived into C++ 11, and yet today you will still see it used.

[jstimpfle]

Not having first class "strings" (which are a cloudy concept) is exactly the right call for a systems programming language that is concerned with the harder truth about in-memory structures.

If you want to "join together" strings data and printf/snprintf isn't convenient enough, go ahead and use different tool. But don't act like computers can natively compute the concatenation of two string buffers, and offer you the result into your expecting hands. On a lower level, everything needs to be stored in memory somewhere, and if "just somewhere in a heap allocation" is good enough for your purposes, use a different language but don't expect best performance nor simplicity.

[moffkalast]

Tbf, anything but bytes is a cloudy concept and not accepting that is just making things harder for yourself for literally no reason. If you have native arrays, you can have native strings, end of discussion.

C doesn't have strings is because there wasn't a well accepted library for them at the precambrian time it was being designed. Otherwise it would've, not out of some ideological fit-for-purpose nonsense. It was supposed to be a high level language, as high as they could go with systems being as crap as they were back then.