Strings in most languages:
(☞ﾟヮﾟ)☞ foo: string = "bar"

Strings in rust:
(╯‵□′)╯︵ AHHHHHHH!
borrowed value does not live long enough
types differ in mutability
cannot assign twice to immutable variable

lol

Strings are pretty complex in pretty much every language with manual memory management.

If you thought strings were simple in C/C++, wait till you have to work with a ton of them in a large scale application.

Reassigning immutes is disallowed in all the languages

TypeScript?

While i think rust sucks ass and id much rather use c

1) simple scoping issue, at least the error is explicit
2) this usually happens when you try to modify an immutable thing in place, which makes sense
3) yeah

The real mindfuck is when you start using libraries and half of them have mutable variables and the other half only uses references.

None of those errors are specific to strings though, they're lifetime/mutability errors which would just as well apply to other values. But I get your frustration.

It takes a bit to get used to Rust memory trickery... but when it clicks, it's like "well duh, that just seems like a good practice". Rust just points out things which could actually cause errors in other languages as well.

But it does take a few weekends of stabbing with a rusty knife at some pet projects while occasionally throwing objects through your room, before you get used to it.

In C you just have char*

This can be many kinds of string! It only seems like one. It can be String, &str, &'static str, OsString and many more.

I'd rather have them as separate types because then at least the compiler tells you when you have a bug instead of finding out in production.

Also, don't be afraid to clone! Other languages do this implicitly

@Geoxion And in C you have no idea who owns that little pumpkin patch of memory.

Rust multithreading & async is like immersing yourself in a godly S-tier chocolate fountain and thinking "so this is what sweet warm dessert sauce feels like when it flows over my balls".

Sorry, be right back, have to masturbate a bit.

https://blog.rust-lang.org/2015/04/...

@bittersweet it's all because mut &str is a lie.

@bittersweet In C, you know exactly who does - whomever the docs say owns it.

This is why most respectable libraries have documentation that states "This is statically allocated" or "this must be freed when finished" or "free this memory by calling X function".

So yes, you do. C is easy when you respect the other developers writing the code you work with.

@junon What I mean is — it's not enforced in code. You must manually stick to agreed upon rules. Given the many examples of software with memory leaks and security flaws, the conclusion is that humans can't stick consistently to rules very well.

@junon so if it's a must have for good code that it is documented, then why not embed it as a feature in the language?

That way you can't have wrong or missing docs.

@Geoxion Because "embedding" it into the language is a trade-off, usually removing chances for optimizations.

@bittersweet You realize the entire world runs on C, right? That's like saying "undefined references happen in some JavaScript, don't use javascript then."

I hate javascript more than most people, and even Id say that's a ludicrous line of thinking.

@junon I would agree that if you're writing perfect code for peak performance, then yeah, that may be right. But almost no one is doing that.

Not having those kind of features may also cost performance in everyday code. Having those features allows for easier abstractions. The abstractions that work well in C may not be the ones that are highest performing.

Good article on this:
http://dtrace.org/blogs/bmc/...

And because I'm posting already, Rust after the honeymoon: http://dtrace.org/blogs/bmc/...

@Geoxion Who said nobody is doing that? lolol

@junon if you're a really good programmer with rigorous disciplined memory management skills then I believe you could get more optimisation.

But I'm just happy when my application doesn't crash. Different people have different priorities I guess. :)

@junon So just because something has been done in a certain way for a long time, means we shouldn't look to improve? Yikes.

I'm not saying: "don't learn C" or "don't learn JavaScript".

I'm just saying: "Be aware that popular languages have flaws, and that there are alternatives which address those flaws"

And yes, those alternatives have flaws of their own, of course.

@junon ok, so you may. But then still, I can't believe more than 5% of your application is meaningfully being benchmarked with for example regression testing and branch miss analysis.

@gibus If you're happy your application doesn't crash, that's on you, but I prefer to have a bit higher standards for my own code.

@bittersweet Mmmmmm yes please keep putting words in my mouth.

@Geoxion That's over-optimization unless there's a bottleneck. I'm talking about preventing needless copies, etc. Branch mispredicts are important in hot code paths, sure, but you don't automate that much in most projects anyway unless you have to have performance guarantees mandated by a standard or a contract, etc.