> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.

This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to require a lot less maintenance down the line (less bugs, easier refactoring), and so it ends up canceling out a bit.

I also never find that Rust limits or controls me in my day to day work. There are some things you cannot do easily, sure, but those things tend to not matter in application code. Linked lists are hard, graphs are hard, but when writing an app, I just use an existing dependency like petgraph or std::collections::LinkedList instead of reimplementing those datastructures. And if you need to write those things, it's not like it's impossible, you just need to drop down to unsafe rust, and ideally figure out some safe way to expose that API.

Really, the biggest disadvantage of Rust is that its learning curve makes onboarding newcomers much harder if they don't have experience in the language. For Python/Go/JS/Ruby you don't really have this problem, even if a potential recruit doesn't have experience in the language, they will probably be able to pick it up as they go without too much trouble. But in Rust, it can take a fairly significant amount of time to get up to speed and stop fighting the compiler, in the order of several months.

This feels like a common pattern. Languages like Rust and Go seem to pick up a lot of users from the world of dynamic languages, who then incorrectly associate the productivity gains of static typing with the specific language they picked.

A lot of programs written in Rust would almost certainly be better off being written in Kotlin. The one in the article is a good example. Why are they writing a messenger bot in Rust? That doesn't seem like the sort of use case Rust was targeted at. It's also a modern language with a lightweight syntax and pretty good static typing, great refactoring tools etc, but it's way more user friendly. There's no borrow checker because it's GCd, compile times are much faster (at least for the JVM version) etc.

You can also use Kotlin/Native or GraalVM native-image to produce standalone executables that don't need a full JVM, if that's a requirement for your use cases. The native images are astounding. They can start faster than programs written in C and their memory usage is also way less than a typical JVM app. Downside is of course compilation time but you can avoid that by just developing on the normal JVM and then AOT compiling at the end when it's time to release.

> Why are they writing a messenger bot in Rust?

AFAICT Rust is a general purpose programming language. People can use it how they want. How do you learn a recent programming language? "hey boss I'm going to write production code in a new language that I haven't learned. Lol YOLO"

The funny thing about this is, using rust for production is way safer than an old language like C or even C++. So the YOLO part isn't crazy here. If you don't use unsafe you cannot, read can not, get data races, among a host of other common bugs.

Now if we were talking about some other "new languages" not naming names, you can memory leak kilobytes writing hello world... Yikes.

Well, the dispatcher problem is applicable outside of messenger bots too. But your point is right. I think it was a mistake that teloxide is written in Rust. I just wanted to learn a new language so I was like, why not writing such a library in Rust. Don't make my mistakes.

> We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to require a lot less maintenance down the line (less bugs, easier refactoring), and so it ends up canceling out a bit.

Python to Rust is a pretty radical swing from one approach to language design to another. I'd expect you could solve most of the maintenance problems with Python by switching to something statically typed but with garbage collection (e.g., C#, Java, or go), without incurring the costs of moving to Rust.

Well, we have other reasons to chose rust rather than a GC'd language (mostly has to do a lot of FFI, which Rust makes much easier than go or Java). I do agree that, if GC'd language fits the problem space, they tend to be much better.

GC has little to do with FFI though. In C# P/Invoke, you basically just declare a static method as external and specify the library where it lives, and that's that. So far as I know, Java has a similar story these days, no need to write JNI wrappers by hand etc. Go is special not because of GC, but because of its green threads.

GC and FFI do have a lot to do w/ each-other though, because FFI usually introduces unmanaged objects.

When a lot of what you're doing is interacting with low-level platform APIs, you end up having a lot of those unmanaged objects. After a certain point, the upsides of using a GC kind of disappear because you still have a lot of places you have to worry about those objects.

Of course, this can be worked around by providing managed wrappers around those unmanaged object, but at a certain point, it becomes easier to just drop down to an unmanaged but safe language (like Rust) that model the unmanaged resources more accurately. In my experience, it's somewhat easier to provide Safe Rust wrappers around your average Windows API than it is to provide a C# Managed Wrapper around the same.

---

And yes, go is special because it has very smol stacks, so doing any kind of FFI on it is a bad idea.

Unless your code is strictly glue between those lower-level APIs, GC is still a benefit for the majority of it. And, on the other hand, the lack of it in FFI is, at worst, similar to C... except you still have all the other language features (like, say, null safety or pattern matching) at your disposal.

I'm genuinely curious as to what would make FFI in Rust easier than in C#, assuming an apples-to-apples comparison (i.e. use of "unsafe" and associated features in both cases"). Most complexity in P/Invoke shows up when you try to use it to automatically map data to managed data types; but in modern C#, you might as well just use raw pointers, stackalloc, spans etc.

Rust seems to excel in having an ecosystem that provides binding helper libraries like PyO3, Neon and napi-rs, Helix, etc. which both ensure "if it compiles, you're doing the C glue properly" and provide a layer for automatic type conversion.

...so requiring `use of "unsafe"` is often akin to forbidding Cargo/pip/NPM/etc. and then calling the language un-productive or faulting a procedural/imperative language for performing badly when you code as if you're writing Haskell.

https://www.hobofan.com/rust-interop/

https://areweextendingyet.github.io/

Using the ecosystem rather than reinventing it is a core tenet of Rust's value proposition.

I’m still learning Rust, but the idea of having to use unsafe features to implement something as simple as a linked list seems “wrong” to me. What am I missing?

I kind of hit a wall with Rust after realizing that something like doubly linked lists are difficult because when two nodes are referring to a node between them, you don't have a clear owner. So basically all situations where you have two or more references to an object need to be thought out carefully, and for me it was a bit of a let down (even though I fully understand the reasoning behind it and why it's useful). For now I stick with languages with GC.

So here's a weird thought, why should you ever write your own doubly linked list? Why shouldn't you use one that a community of people has vetted and juiced for performance instead? In C what I just said is for some reason heresy.

But yes you are right, anytime you have two or more accesses to a data structure you do have to think a little harder about it. Usually you just want to use a reference to that object, sometimes it makes sense to clone it, sometimes you want to pass it by value and return it by value. In the case of doubly linked lists you probably want to drop into unsafe code.

I get it though, GC languages are more zen in that regard.

Writing your own data structures allows you to write it to suit the specific needs/constraints of your problem/domain. Typically that means you get something that is significantly simpler, faster and with a different feature set.

Libraries are typically optimized for generic use, so are often more complex, slow, and difficult to extend with new features (both coding wise or the features might not be suitable / have trade offs for other people).

Won't let me reply to fizzynut, but this is a reply to you.

Yes making data structures is important, and the reality of that is, there are people in the ecosystem creating fancy ones which can be leveraged for your use case.

If that doesn't exist then yea you have to write them. Sometimes that's difficult(you need to use unsafe), sometimes it's easyish and you can use all safe(I did this for a graph type). It can be done(lots of people are doing it), but I think what it shows is, data structures can be difficult to do correctly.

In a worst case scenario you could write it in asm inside rust if you really need a low level control, or write it in C/unsafe rust and ffi or just write it in.

Basically worst case scenario in rust is writing something closer to C.

Lots of people writing their own data structures and libraries should be a reflection of the different needs and diversity of the ecosystem, but if it's a reflection of difficulty then it tends to lead to a much narrower ecosystem.

That isn't to say a narrow ecosystem is necessarily bad, it can often be good if a particular language is used for a specific domain as all the libraries and data structures will likely be a better fit for your problems. Going outside of those constraints can often be very punishing in those languages though.

The fact is that writing a doubly linked list correctly is hard and it's easy even for veterans to miss things. Rust is going to put those invariants in your face.

My advice would be not to judge any language on how easy it is to implement a doubly linked list. 99% of code you write will likely not be that, and that particular data structure exposes a lot of choices and trade offs at a time when youd be better served learning other parts of the language.

Unpopular opinion but the whole memory safe idea is more niche than HN commenters would have us believe. Most of us are writing web apps and services that do not have strict memory requirements nor catastrophic failure modes.

Dynamic languages and GC'd languages cover most of what our employers are paying us for: web apps, backend services. It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors.

Rust has its place, but it's a very small place. These days computers are so fast there's companies worth billions built on Ruby and Python, if you go native with a GC language you'll cover 98% of your needs.

Rust IMHO has gone too far towards safety at the expense of developer ergonomics and pragmatism. We're so expensive that adopting a subpar language that is easier to grok is often a savvier business decision.

> Most of us are writing web apps

Indeed. I'm a Rust dev somewhere it actually matters (video dev - we have to process 60 frames a second, for hours/days on end, with completely predictable performance, without crashing once) and I'd never pick it if I just wanted to build a webapp where nothing really matters and if the whole thing falls over we can just put it in a retry loop.

There's plenty of code out there that /cannot/ be written in Ruby/Python/Go/C#. Rust solves some really hard problems for people working on that type of code. But it's not what most people on HN are working on.

I think the problem is that a lot of web developers do not really understand that this type of code exists, and that languages which do not target web development can be exciting.

Your video app is a perfect example of where Rust shines. I'd add embedded development, data-intensive, fault-intolerant systems and game engines are perfect for this language.

But without even going as far as frontend web applications, stuff like backend services, system services, GUI applications, CLI applications, etc., don't actually need all that much memory safety and control over allocations.

Completely agree! When you need to compute numbers or deal with raw bytes, you have C. When you need to be high-level, you have Python, Java, C#, etc. Rust is applicable only in areas where you need both a high-level and systems language. Examples include interpreters, operating systems, browsers, game engines, etc. The hype of Rust just exceeds its problem domain.

This feels a bit like complaining that a tank is badly designed because nobody drives them on the highway...

My understanding is that Rust was designed to be a safe(er) language to write low-level system code than C/C++, not to compete with Python/Ruby/Java for web development applications.

I'm not complaining about Rust. It's a very good language.

I'm complaining about everybody on programming forums, including HN, seeing Rust as the replacement for most, if not all languages. My opinion is that Rust's ideal problem space is much narrower than people think.

Bingo, it's a true systems language. That said, the fact that people can and do write web applications(for practical reasons) with it kind of says something about it's breadth.

The whole point of system languages is that they reach the whole stack.

True, yet what you see around HN and other places are people trying to use it for web development.

Front end or back end? I see nothing wrong with rust on the back end, not sure how it would even work on the front

WebAssembly.

There seems to be a myth that Rust is unusual in being memory safe. All modern GCed languages are memory safe (assuming you don't do anything obviously unsafe like manipulate raw pointers, which some languages might let you do if you really want to).

>It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors.

Nil dereference errors don't demonstrate an absence of memory safety. If the runtime checks for a nil reference before dereferencing and then raises an exception, that's perfectly safe.

I'm not sure if you understand what safe means in this context. One common example is modifying a vector element by reference. If you grab a reference to an item, push something else to the vector, then try to access through that reference, the vector may have re allocated during the push and you're either no longer looking at valid memory because it's been freed, or you're looking at a stale copy of the element.

I don't think the null handling in rust is about memory safety so much as it is their choice in error handling. If you come across a null pointer dereference and your code doesn't handle it, that's a hidden bug. Triggering an exception and handling it is a valid approach, but there are trade-offs. If no code handles the nil exception for example then it's no better than crashing as you would in C. Wrapping things up in try catch can lead to missing recoverable errors or unexpected states. The choice to disallow null is one to avoid common bugs, not one for memory safety, as far as I understand it.

I'm 100% sure that I understand what safe means in this context. All modern GCed languages are memory safe and will not access invalid memory regions unless you use specifically unsafe features.

> One common example is modifying a vector element by reference. If you grab a reference to an item, push something else to the vector, then try to access through that reference, the vector may have re allocated during the push and you're either no longer looking at valid memory because it's been freed, or you're looking at a stale copy of the element.

There aren't that many languages which both use GC and allow you to take references to elements of a vector. Go would be one example. I can assure you that you cannot access undefined memory regions by doing this in Go. (What would happen is that the original allocation backing the vector would be retained in addition to the new allocation.)

>If no code handles the nil exception for example then it's no better than crashing as you would in C

C programs are not guaranteed to crash when a pointer has an invalid value. Dereferencing a NULL pointer will reliably cause a crash if you're running the code on top of a modern general purpose operating system with memory protection, but invalid pointers (which don't necessarily have to be NULL) have the potential to access arbitrary memory regions without raising any kind of error.

> I can assure you that you cannot access undefined memory regions by doing this in Go.

Current implementation of slices and interfaces in Go is not memory safe in presence of data races:

https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

This is the kind of edge case you can find in lots of languages, including Rust (which has plenty of past and present soundness bugs).

Data races are violations of the memory model; of course any code which produces data races cannot be understood as memory safe?

As far as I remember, some languages like Java are memory safe even if the code produces data races. That means you can't have a reference to a value supposed to be of type A being actually of type B.

That's part of what the Rust borrow checker does for you: tracking who owns what and enforcing single ownership makes data races that much harder to cause.

Turns out I'm the one who forgot what memory safety is o.o I think the part that makes rust's memory safety special is that it also lacks garbage collection

Some people misunderstand unsafe for being anything more than plain memory corruption.

Nope, unsafe isn't a way to do dependent typing in Rust.

The reference to the slot in a vector has to be a kind of object which tracks the vector itself, and an offset into the vector. It can't just be a wrapper for a naked address.

You might be right for the majority, but there are many other large groups who don't have computers that are more than fast enough. There are a lot of interesting and complex problems that can be solved in something like rust that the languages you name cannot be used for. Right now I'm using C++, but rust is of real interest to me (as is ADA, which in some variants lets me prove my code correct)

"It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors."

This is something that escapes a lot of people nowadays.

Everyone uses a browser and they are inherently unsafe.

I feel it is a bit ironic that Apple and Google rather introduce mitigations for C++ in their browser engines than introduce Rust into the codebase.

Meaning that Firefox's gains with Rust will eventually be lost given its market adoption is slowing reaching zero.

Google is investigating Rust as part of a multi-pronged strategy and, while it has the "this is not an official Google project" boilerplate, the `autocxx` crate (a header-parser/code-generator addon for the `cxx` interop crate) is by Google employees.

https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...

https://www.chromium.org/Home/chromium-security/memory-safet...

https://github.com/google/autocxx

the thing about Rust's ownership model is that a reference is not ownership, it's 'borrowing', and should be treated as such. But - and here's the kicker - the borrow happens as long as that reference is stored, not just when it's accessed i.e. dereferenced. This makes a number of data structures and patterns difficult and impossible to implement as you can't keep track of references to anything. You can't really make an opaque handle, for example, that can do operations through a stored reference. You have to store some ID or something and then when you want to do operations you need to pass the original container to the function anyway - so what's the point of even having reference types at that point?

IMHO Rust's lifetime analysis should consider borrows only at the point of dereference, not just whenever you encounter an & symbol. They already do that with raw pointers - you can have as many pointers as you want but you only need to mark `unsafe` if you actually dereference one. So at least someone on the team knows how to make that work functionally.

You’re missing that you don’t have to use unsafe, you use a wrapper type which is essentially a smart reference-counted pointer. Rust makes these things explicit.

Because it's a library feature, exactly the thing you should use "unsafe" in, since it should be simple enough to be obviously correct

you're not missing anything.

> And if you need to write those things, it's not like it's impossible, you just need to drop down to unsafe rust, and ideally figure out some safe way to expose that API.

I'm sure you know this already, but for the people reading this: first of all "unsafe" is a very rare, and it's only "less safe" more than fully "unsafe"; ie it's still safer than C++.

And the second thing is that, often you don't have to drop into unsafe Rust, it's possible to achieve most stuff without it, but might incur a small performance cost (idk if some of those can be optimised away by compilers or not).

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.

This sounds as insane to me as a carpenter who works with power tools saying. "Having safety measures which limits you and controls how you you have to do certain things does not sound appealing to those who need a house build, fast."

I mean, while my understanding of the construction market is rudimentary at best - isn't it actually the case that construction often _does_ end up rushed, or compromised at design level, exactly because of that?

It's not good, and when a bridge falls over the results are a bit more... dramatic and undeniable - but it's not really my impression that other branches of engineering are particularly immune from corner-cutting and deliberate under-estimation.

Edit: though I'll say, just having someone "at random" say they expect better in their industry is an anecdotal evidence that it is at least a bit better. Also, you get to work outside. Truly, grass is greener on the other side of the road.

Or use a GC language with a great typesystem and have both safety and fast efficient development cycles.

That is an option, or if you don't want to deal with a GC because it's eating 70% of your clock cycles under load you can use rust get performance gains and still be writing safe code...

if your GC eats 70% is your clock cycles, your language has a broken GC. in modern Java/C#, GC time is rarely more than 10%

To get to a low GC overhead in Java (and perhaps other languages too) you have to pay with an increase in memory consumption. Sometimes as much as 100% additional RAM to avoid frequent full GC scans.

That's true, but malloc/free based systems also have a relatively high memory overhead due to fragmentation and programmers being worse at inserting frees than the GC. It's not at all clear that the C/C++ model of memory management has lower than 100% overhead for long running programs.

> but malloc/free based systems also have a relatively high memory overhead due to fragmentation

In case you haven't seen it, there's been some interesting progress on that front:

https://www.youtube.com/watch?v=c1UBJbfR-H0

Rust only limits you from writing nonsense code. Seriously that's what the compiler is doing, and that's what people are complaining about. "Why won't this language let me write bad code!". I get it it's hard to learn at first, but, it sounds a little silly to people who have spent the time learning the language...

Believe it or not industry has and is continuing to adopt rust. Microsoft, AWS, government agencys in Europe, the Linux kernel itself (the only other language allowed there is C - think about it). It's really not all hype, people like it because it solves a class of problems from never happening while still performing very well.

I invite you to join the community and learn it. It's a lot of fun once you get proficient with it.

> Rust only limits you from writing nonsense code

This is the ideal, but not always the reality. The Rust borrow checker isn't perfect, so sometimes it rejects code that should work perfectly fine. Hopefully as the language matures (Polonius, GATs, HRTBs…) these cases will become rarer.

Is there a simple example you can point to of rejected code that should work perfectly fine?

A doubly linked list is a classic example. To implement this in Rust you need to use unsafe code.

Come to think of it, an even simpler example is a mutable iterator for a typical data structure. Such iterators usually require 'unsafe' code to implement, even though they are perfectly safe to use. https://stackoverflow.com/questions/63437935/in-rust-how-do-...

Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk. So when you do get UB from using unsafe you look at those places rather then your entire code base...

A lot of people don't seem to realize how easy it is to get UB in other languages. The C spec for example claimed not having a trailing newline at the end of a file was UB...

I also don't think this was an example of code that should compile but doesn't. Rusts' ownership rules make this task hard, but there are lots of people using doubly linked lists in rust... Yes they used unsafe code to do it, and yes it does compile .

The question was show us a case where the borrow checker was wrong.

>Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk.

I'm fully aware of this. That's why I put 'unsafe' in quotes.

However, it's surely fair to point out that you can't implement doubly linked lists or mutable iterators in Rust without giving up Rust's usual guarantee of memory safety. If this guarantee is not actually that big of a deal, as you appear to be suggesting, then why all the hype about it from Rust advocates?

>The question was show us a case where the borrow checker was wrong.

No, that was not the question. OP just asked for 'rejected code that should work perfectly fine'. There are of course loads of examples of such code. Perhaps the simplest is the case of mutable iterators that I mentioned. A correctly implemented mutable iterator is perfectly safe, but rejected by Rust's borrow checker unless certain parts of the implementation are marked unsafe.

It seems you are slightly misunderstanding the point of 'unsafe' as a concept.

And no, memory safety is a huge deal, it is just that the borrow checker cannot verify the soundness of certain code, meaning you have to provide the guarantees normally given to you outside 'unsafe' blocks.

Yes, this means that a few data structures require 'unsafe', but you should be creating safe wrappers around these structures; 'unsafe' won't propagate up your code and poison everything.

> it is just that the borrow checker cannot verify the soundness of certain code

And I was just proving examples of such code for someone who asked. Honestly, some Rust folks get so defensive it makes them very prone to misinterpret simple factual statements about Rust as criticism.

Apparently you don’t disagree with any of the factual statements that I’m making. You just have some vague unsubstantiated feeling that I don’t ‘get’ Rust.

I'm not fighting your claim that the borrow checker has perfectly reasonable situations it can't deal with. That's why 'unsafe' exists. I've already said that.

You're adding other claims and statements that make me question if you actually understand the thing you are criticising.

If you'd say what those claims and statements were, then we could have a conversation. It's not conducive to a good discussion to reply just by saying "you're wrong and you don't get it".

Yes, it has limits. And unsafe let you C++ your way out of it. At least, little code requires unsafe and thar makes it easier to audit.

"I invite you to join the community and learn it. It's a lot of fun once you get proficient with it."

I will if the Rust community agrees on a lighter, less complex language core.

"Microsoft, AWS, government agencys in Europe, the Linux kernel itself (the only other language allowed there is C - think about it)."

Again, they are using only a subset of the language. Linus allowed it in the kernel once devs agreed only to use the Rust core features. They even had to make a new memory allocator, IIRC.

You’re confusing standard library naming. Rust has a layered standard library, “core” and then “std” on top of it. They’re using the core library, because that’s what you do in an OS context. But as far as I know they don’t restrict any language features.

They also didn’t have to write a new allocator; they did extend the interface of the “alloc” library (which sits between core and std) which was then also accepted upstream.

So, what software can you make without relying on "std" library?

I think that a lot of complexity in Rust comes from many different ways to handle memory. You have your Arcs, Boxes, Cells, etc. Then you have a core "alloc" library.

Maybe if everyone agreed on a single reliable method to handle heap memory (since using stack is easy), Rust wouldn't be so hard to use.

The syntax also could be improved. Seeing <Box(T)> or whatever nested three or more levels deep hurts my eyes.

You don't have access to the C standard library in the Linux kernel either, so what is your point? Ime., the core library of Rust is much nicer to work with than the absolute bare bones landscape that is C when compiled with -nostd.

Boxes, cells, arcs, etc. exist for different purposes and if you'd take two hours to actually read about them and their uses, you'd understand why they exist.

You can write lots of stuff. The stuff you lose access too is mostly things that rely on the OS to function, so you lose file system stuff, networking stuff, things like that. Of course, people have written their own implementations of these things when it makes sense to do so.

Thank you Steve. There is so much misinformation surrounding rust it's unreal...

It's also kind of normal to you know tweak a language so it integrates with an OS better... Even if they did change their allocator, who cares?

The problem with rust is its community. A bunch of groupies acting worst than kpop stans on twitter. If you don't make abstraction and write spaghetti code, or if you clone everything, then yeah rust work-ish.

> complex language which limits you

Rust really does not limit you. Anything possible in C or C++ can be done in Rust if you're willing to use unsafe code.

You could also say the same thing about Assembly.

I'm not sure this is true. The aliasing model of unsafe Rust seems much more difficult to write correct code for than these other aliasing models.

Use UnsafeCell if that’s your problem.

This is not the case if you are designing a library. Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff.

Most of that difference is in things that happen at compile time, so this is not a question of Turing completeness.

> Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff.

Do you have any examples?

All above languages are turning complete, so if you can express it in one you can express it in another. The question isn't can you write it, the question is how hard is it to do, and how performant the code will be.

The heart of C++ is destructors: a bit of code that you can write and the compiler will ensure runs when code goes out of scope/is deleted. You can do this in C by remembering to manually call the right code when doing clean up, but it is easy to forget and thus error pron. (I think Rust has this too?)

C++ gives you the ability to do a virtual base class interface, which - as most people know - just means it writes a vtable behind the scene for you. Sometimes people write a vtable by hand in C: it is just a struct of function pointers, but the syntax to do it in C++ is a lot nicer. If you need an interface of some sort the win goes to C++ because the syntax is a lot nicer. (I'm not sure what Rust does about interfaces, I think it has something)

C++ gives you control over copying structs. In C structs are only copied member wise, if the struct has a pointer you need to keep track of both copies so you don't free it early. In C++ you write a copy function that will make a copy of the pointer. You can do this in C by remembering to call the right function when copying a struct, but the default is the wrong thing. (I'm not sure what rust has here, but at the very least the borrow checker will stop you from making a mistake)

C++ gives you move objects - a way to express that a struct is going out of scope, but only after a different one is taking over the contents. This is a variation of the previous, except that you know the original doesn't need valid data anymore and so you just copy pointers and null them in the original. C doesn't have this concept, you can get around it with use of pointers and manual copying of structs in the right places, but the code is ugly. (again, I'm not sure what rust does, if nothing else the borrow checker should allow the compiler to make some optimizations on this lines)

There are a lot more areas where C++ gives you syntax to write correct code that C does not. Rust intentionally doesn't have some of them (class inheritance has been abused often, but I still find it useful enough in a few cases that I think rust is wrong for throwing it out), and in other cases has come up with a better syntax. Overall I don't know enough about Rust to judge it, but I'll take C over C++ anyday.

Note, the above is about the advantages of C++ over C. C++ has a lot of warts that are out of scope for that discussion. I am not claiming C++ is perfect. If you are starting a new project you should seriously consider your language options - including some not mentioned here)

I will note that Rust has all of those features you mentioned. 1) Traits 2) You have to be explicit, by implementing the Clone trait, otherwise arguments are passed by reference or moved. 3) Rust has both RAII and linear typing, which is effectively a proven-correct form of moves - you can't access something that has been moved, unlike C++.

Rust doesn't have class inheritance, no, but often combining traits and delegating to a "parent" field works. Although sometimes that can be considerably more cumbersome, yeah.

I agree that the GP comment does not capture what Rust is unable to express.

You can also see it this way: The philosophy behind C++ is that the existance of a pointer implies ownership. In C, the existance of a pointer only implies liveness (normally; but really the code can decide on its own whether its safe to dereference the pointer).

With the C++ approach I've found myself overthinking the problem many times. But with the insight that pointers are just data, and memory management can be independent, it turns out that programming with raw pointers need not be hard. There is no problem passing a pointer without "move semantics" shenanigans.

You are confused.

There is no sense, in C++, in which a naked pointer implies or suggests ownership. It is the opposite: the continued validity of a pointer value depends on ownership maintained elsewhere. Nowadays libraries keep track of ownership. Most commonly the library delegates that responsibility to Standard std::unique_ptr, for familiarity. Not doing that indicates something different in play.

(It is, in fact, UB even in C to copy the value of a pointer to an object that does not exist anymore. This is the case regardless whether it had pointed to or into a stack or a heap object.)

In C, there is no way to express library ownership of a pointer. So, in C there is always potential for confusion about ownership.

> You are confused.

I give you one advice: Think twice before writing this way again. You are not putting enough effort into understanding what I'm trying to say, and coming across as an arrogant prick.

https://news.ycombinator.com/item?id=31494099

Admittedly, I didn't make my point sufficiently clear, but this isn't even about being right or wrong. (And, once more, I understand what you say. Stop belittling me.)

You must be stuck in C++98 land. In C++11 a pointer always means live (though you may not have rights to store that pointer for later). We use smart pointers to force ownership.

I know. I'm not stuck in C++98 land. I'm talking about how problems are approached in C++ and more generally, OOP land. In large parts of the community, there seems to be this idea that (almost) each little pointer (naked or not isn't my point here) should also be a handle to control the lifetime of the object that it points at.

I'm not saying that it has to be this way, but there is a reason why something like unique_ptr (that can be quite tedious to use in my experience) has become so popular in many projects - IMO it is overused, often leading to more typing work instead of less.

If one is sufficiently used to this way of modelling, it can come as a surprise that memory management needn't be so hard, and doesn't require smart pointers or anything, if the program design (global flow of data etc.) is sufficiently clear.

Thanks, that is a very detailed answer[1].

I'm somewhat confused about why it was downvoted - there is nothing there controversial at all.

[1] In my own toy language, I'm kinda leaning towards objects with destructors. Definitely without the footguns in C++, but destructors nonetheless.

Possibly because it does not mention almost all of the C++ features that Rust still lacks.

> but I'll take C over C++ anyday.

Did you mean the opposite?

opps, yes I did.

What I'm about to write isn't to pick at you - I think it's a systemic issue, and "professional programmers" unfortunately have limited influence on it, at least right now - though I believe "we" could change it - but not while acting as individuals.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.

See, I don't think Rust makes that _harder_ - I think it surfaces the real complexity, makes is undeniable. So far in my - by now 20 year old - career, when I've seen most teams faced with complexity that might either slow down a project, or be swept under the rug, the latter was always chosen.

There are _business reasons_ for that, software projects don't live in a vacuum - but those reasons are... _depressing_ at best - by far the biggest one I've seen is that a correctly estimated project would never be approved. Let's just say that figuring that out is a cognitive hazard that can easily increase risk of burning out - literally the sort of knowledge you're better off ignoring.

So ultimately my line of thinking is, Rust's problem in the business sense is basically the same as when you try to code in it: it _tells you that you're trying to sweep something under the carpet_. It tells you that your feature's cost is under-estimated. And to be fair: what can you do about it? The feature wasn't truly estimated by you. It was, almost certainly, estimated by your boss to be "one sprint at most," before he even asked you, and "please estimate this" has an expected answer, and giving any other one has a high social cost. And goddess protect you if your answer might call the entire business model into question.

I don't think any of us can change this, nor that the software engineering workforce is ready to push for changing this. Because even if we convince _our boss_ - the investors will just pick someone else, after all.

--

Anyhow, now you'd be excused in expecting me to advocate some sort of gatekeeping - but no, what I like about Rust is that it attempts to make programming more accessible in a _very different way_ to how many high-level programming languages did. For example:

- it's not _just_ a systems programming language. It doesn't divide programming into "stuff for anyone" and "eldritch monstrosities for the Chosen Ones" - eldritch stuff is just around the corner, in the same language, - it doesn't try to hide the complexity - it tries to give you tools to _explore it_, - and, expanding on the latter, its community values documentation and teaching over restricting use cases.

I don't think Rust is entirely _successful_ at that - but I think that the different model for accessibility is, if anything, more interesting than the borrow checker. I don't think we really need a single language - a garbage collector can be performant and useful, for example, and does it really _have to_ actually result in sweeping complexity under the rug?