Hacker News Reader

>the one easier to use is going to get wider spread / adoption

Between Rust and C++, this is Rust. In C++ you need to a lot more memory safety verification in your head, there are thousands of footguns that you need to be aware of at all times, the template metaprogramming facilities are really hard to grok with their weird syntax.

Rust is strict, but for the kinds of applications that you would replace C++ in this makes it a lot easier to learn.

I think the sentiment that Rust is hard comes from people that come from managed languages (Python/Java/C#) that aren't used to manual memory management. From that perspective Rust is indeed hard.

C++ has much more bigger inertia. It is like the "default" for all the areas where it is being used. So when learning a language people would rather go to C++ first and then to Rust, if they are really planning to work in corresponding area (game dev etc.). Or even go to C.

Rust will probably replace C++ in some areas where it is a legacy app (or part of the app) that is not changed frequently anymore.

I'm used to writing C, and think pointers are easy to understand. I wouldn't call rust 'hard' to learn, but it is without a doubt painful. You also aren't doing manual memory management in rust either... I'd assume the sentiment comes from the irrelevant hoops rust makes you jump through to just compile something simple.

You don't need to be aware of 1000s of foot guns for every block of non rust code. But you do have to remember dozens of pedantic rules, or stdlib wrappers just to trick rust into allowing you to compile your simple/demo code.

> You don't need to be aware of 1000s of foot guns for every block of non rust code. But you do have to remember dozens of pedantic rules

Have you tried using rust-analyzer? I'm usually a bit of an IDE skeptic, but Rust is one of those languages where tight integration with the IDE really helps IMO. It's night and day, I honestly wouldn't want to write Rust without rust-analyzer, but with it it's quite pleasant.

I deleted all IDE features (other than good highlighting) and I'm never going back! I kept adding more and more IDE features, and my subjective enjoyment and happiness writing code kept decreasing. I deleted them, and I love writing code again!

I think the fact that the language is aggravating without complex and tight IDE integration is one of the best indictments of the language there is. Java is another language that's intolerable without impossibly complex IDE support. The more rust matures the more it feels like that.

Unlike your parent, I don't use an IDE at all, I write Rust in just a plain vim, no language server, I don't even bother with syntax highlighting.

Still, I'd say that actually the distinction that's aggravating you is almost entirely that Rust won't compile a lot of code that's nonsense, whereas in C++ that code compiles - it's still nonsense, but it compiled anyway. I think that's just plainly worse.

The very first time I used rust for a work project, I tried to implement a tree... well actually I tried to implement a linked list first, later hoping to expand it into a graph.

The distinction that's aggravating me is the compiler refuses to compile code that I know is correct, but it's not smart enough to prove it, so it just gives me the finger instead.

Yep. I've been developing in C++ professionally for a decade and I still have to look up "what's the safe way of making a string literal available in a header file" when it comes up.

C++ was the first programming language I ever learned, but I've only written a few hundred lines of it over the last 2 decades. Never professionally.

Can you elaborate on the dangers of doing this incorrectly? What kinds of dangers are there in making a string literal available to a header file.

Not OP but I think it depends on your definition of 'string'. For example there are some very grumpy devs who believe that C has no strings, and that "const char*" cannot ever be considered a string, and that anyone else who claims so is wrong.

This is made more confusing by C++ basically insisting that your "basic" built-in string type has to have the small string optimisation. The guts of std::string in any of the three popular stdlib implementations are... pretty complicated. In contrast Rust's String is literally just Vec<u8> [a growable array of bytes] plus a promise that these bytes are always a UTF-8 encoded string.

And by C++ taking a long time to get the natural string slice type, which it calls `std::string_view`. This type is what you almost always want in APIs that aren't responsible for growing and changing strings - for the names of things, labels, parsing and so on. Because this type was not in C++ 98 or C++ 11 or even C++ 14 people would use `std::string` instead even though they did not need to modify, let alone grow, the text or, since they don't want the overhead of `std::string`, they would use `char *`

It was correct for C++ to seek to do better than C here, but while what they delivered was a lot more powerful it's not clearly better and I think has contributed to widespread misunderstanding.

C++ doesn't require any of this. Everyone implements it this way because it is cheap and improves performance. And people don't take (const) char * they take const std::string &.

I largely agree with the "programming languages are a communication technology [thus critical mass is critical]" bit, we spend more time reading and explaining code than we do writing it. That's why I'm really hopeful for Rust web frameworks like Loco to get to mainstream-ish.

There are just _so goddamn many_ webdevs that a reasonably popular web framework can bootstrap a language out of the mid-popularity uncanny valley. On the flipside, a lot of webdevs are interested in Rust, but aren't really personally set up to do some embedded or systems stuff, so the activation energy for a given developer getting into it remains slightly higher than other languages.

Golang is not much more widely used comparing to rust? both are 17+ years old and they're around 2% of the market.

I think a question that must be asked is "what market?" Go is a very niche language in it's application: it is ubiquitous in the Docker/Kubernetes DevOps world. It's also successful as an alternative to Node in the server/micro services world. And there are many CLI tools written in it (but CLI tools can be written in any language whether or not it has critical mass - there are popular ones even in Haskell!).

Excluding CLI, Go's use cases virtually did not exist when Go was created. So Go was "the right language at the right time" to grow up with it's niches (decent performance, easy to learn, easy to reuse library code, easy to deploy, easy concurrency). It is virtually non-existent anywhere else.

On the other hand, Rust competes in exactly the same high-performance/low-overhead space that C++ dominates. Because of Rust's complexity, it is very unlikely that it can compete anywhere else. Rust must displace C++, or at least be a viable alternative to it.

> Because of Rust’s complexity

I would argue there is 2 types of complexities here:

1. Complexities when developing (Rust) 2. Complexities once running in production (C++)

I’d much much prefer to have errors and frustrations developing than users dropping out of the sky at 40,000ft

The issue is that for all rusts complexities, it can still have production issues.

... and for all of C++'s perceived simplicity compared to Rust, it can still have compilation issues (looking at the compiler errors output by template classes can be a downright nightmare)

For sure.

But C++ devs aren’t trying to convince rust devs to change their stack.

But I can guarantee C++ developers are trying to convince the world that C++ is safe enough for everyone

Can you?

I’ve never heard that from a C++ dev.

I don’t think any C++ dev worth talking about thinks that C++ is particularly safe, just that (modern) C++ has plenty of powerful safety features. (Like smart pointers. Analogous to rust’s Rc and Arc)

So much so that it approaches rust’s safety promises in the most common cases.

In what I’ve seen, C++ devs are largely unconvinced that rust is more safe than modern C++ in the most common cases, but rust has a much higher complexity cost, especially when integrating with C code.

It’s really hard to convince hardcore C and C++ devs to use rust, because most of the touted features are seen as fixes for skill issues. Not because they believe that rust is not safer.

I wrote a BBS in Rust. It need sleep neither high performance nor low overhead, but it was a delight to write. For example, the compiler error messages are so detailed and explanatory that I learned a lot of the language from it telling me what I was doing wrong and offering suggestions.

I would’ve written it in Python a year ago. Now I wrote it in Rust because it was genuinely fun and the results came out nicely.

I have zero interest, none, nada, in C++. (Readers: please don’t try to win me over. I know more about the subject than you might think and it’s an informed opinion.) For me, Rust doesn’t compete with C++ at all. It’s probably replacing my Python coding more than anything else. The output looks and feels quite Pythonic, but with strict types and AOT compilation to native code. I’m loving it.

> I wrote a BBS in Rust.

A BBS? Does this have a different meaning now than in 1986? Where do I dial up to it?

Same meaning. You get a Meshtastic radio and send it commands through a chat.

See https://honeypot.net/2024/11/28/first-light-of.html for screenshots.

This is my experience as well. I wrote Telegram bots in Python and Go for myself, they had weird bugs difficult to debug. Then I wrote it in Rust and it works. I don't have to go back every three weeks to reset the server. Would I write it in C++? No way.

What do you mean when you say “Go’s usecases did not exist”? It was invented to write concurrent servers in that would have readable, performant implementations suitable for use across teams, to make code review faster and better, to displace C++, and to prove that certain design principles from Dis / Plan9 were superior to those in Java. I’m not really clear how those usecases did not exist at the time. If you mean “Go is for scheduling containers”, you are wrong, but just because one popular application exists that doesn’t imply that is “what it’s for”.

I inherited a project that uses Go for an industrial control system. It needs to manage valves and pumps and sensors in a performant and accurate and reliable manner, and that's what the developer (an electrical engineer) chose. FWIW the system has been in production for a couple years and works splendidly.

The me of yesteryear probably would have developed such a thing in C++. In an alternate universe, there's a version of me that learned Rust 5-10 years ago and would have chosen that.

> an industrial control system. It needs to manage valves and pumps and sensors in a performant and accurate and reliable manner

How does it deal with GC pauses? Wouldn't they introduce unacceptable jitter for this kind of application?

Anyway, it's relatively straightforward to rewrite from Go to Rust if you aren't doing things that essentially rely on GC (which is quite rare).

A PLC controller deals with anything that requires tight timing, so the Go portion is mostly higher-level control of the system and states.

So only high level non-safety-critical code, I see.

I hope someone properly checked that no safety properties depend on Go there. I bet nobody actually did so...

Go’s GC is pretty snappy these days, but I don’t think it’s that snappy. :)

Rust is not "17+ years old" in any relevant sense. Rust 1.0 only came out in 2015, and the first genuinely usable version arguably was only in late 2018 after non-lexical lifetimes (NLL) were added. Golang is a lot older than Rust, practically speaking.

Beta wasn't better. VHS matched broadcast quality for less money and substantially more runtime per tape.

Dvorak isn't particularly better because typing speed isn't worth optimizing for if you are good enough and the difference if any is small.

Lua isn't better than js if it needs to run in the browser natively.

As with most things, I think that not only is "better" subjective, but such dogmatism is a sign that you are not considering that other relevant perspectives or context may exist that can disagree with you. I think true intelligence by definition requires humility and realizing that we can't know everything, there are things we don't know that we don't know, and the world is not so black and white.

Good point. At the cost of relearning typing some folks may increase their speed but its not easy to determine if they would have won similar gains spending time improving habits with qwerty.

That said its nearly irrelevant because for most jobs typing speed isn't a limiting factor for those with average typing speed for proficient users.

> Dvorak isn't particularly better because typing speed isn't worth optimizing for if you are good enough

Is Dvorak even quicker? I tried learning it and found some quirks, for example, lots of English words end in "ght" (thought, bought, draught, taught, etc...) which is extremely awkward to type on a Dvorak layout (you need to strike all three with one finger whereas on QWERTY it's split between both hands so you can alternate).

I agree with your point though. I type 80+ WPM on QWERTY with no maintenance and honestly, I type way faster than I can even think about what to type (especially for programming). Now that my college essay days are way behind me, I don't think it even matters.

More than just Swift has been influenced by various ideas in Rust. Zig and Vlang are among such other newer, easier, modern features having and somewhat safer languages who claim and show influence.

Languages like Golang, can make a good argument of being the VHS to Betamax, because it is among the easier to learn memory safe languages. Golang is much more strongly positioned to take over C#, Java, and even Python spaces. Not just technically, as a language, but because of the large corporate machinery and jobs behind it, that is the result of being a Google product.

As for Rust's main claim to fame, memory safety, lots of other lesser known languages are hard at work to become direct viable alternatives to Rust. Some of them are: Hylo, Vale, Lobster, etc... Vlang, while not quite trying to aim as high as the others (on memory safety), uses an optional GC (like Nim and Dlang), and is among the safer languages. It then becomes a question of how much the extra burden of Rust is needed, for the project in question.

>May be I should repost this every time there is an argument about Rust. And to expand on that, in communication technology, the one easier to use is going to get wider spread / adoption.

Which frustrates me in many respects. Especially in a specialization like tech where the audience should be used to picking up new tools to make for the best project. But I know most projects are made with business constraints in mind (i.e money and time) and cheapest almost always wins.

> they're means to communicate ideas to other programmers

This is somewhat of an anthropocentric point of view. (In particular, assembler is as far as it gets from this.)

People can and do write assembly code for others to read.

>"Rust is a superior technology to C++....it disciplines you to do the things the right way."

It is not. The only thing it disciplines one to do is to bend them to confines of particular safety model. And Rust creators do not have the ultimate authority to say what is the right way anyways. No one does. There are multiple concepts fitting different situations. Rust ignores many. As a general language it looks way too opinionated to me.

This is what keeps tripping me up, it is very difficult to be both general and not opinionated. C++ is general, you can use it however you want. Especially in many unsafe ways. Like it or not, this is great news for a general low-level language. A language that tells me how to build, where my files should live and what tools I am to use may be a great user experience, it is not very general. Still not sure what to make of this and where I land on this.

>"Like it or not,"

I do not give a flying fuck. Language is a tool. I work with many languages. If clients wants language XYZ then XYZ it is. My private opinion does not matter in this case

>If clients wants language XYZ then XYZ it is.

I don't care how much you pay me (well, not in a practical sense), I'm not going to bash a bunch of screws in with a hammer. In my industry, the languages and tools do in fact matter and impact the quality of the project. It's hard enough as is without some unreasonable clients saying "oh yeah, can you make this in powerpoint?"

>"I'm not going to bash a bunch of screws in with a hammer."

My clients are not that dumb.

I'm exaggerating with that metaphor, but it's honestly not as much as I'd wish. I envy your clients. But I'm not too surprised, either. That's just a result of my domain, sadly.

> Rust ignores many [safety models]. As a general language it looks way too opinionated to me.

I'd like to see some actual examples of this, and I assume many Rust devs would react the same way. In practice, most proposed "safety models" that Rust complains about don't really work when considering that code must be enabled to interact not just within a single module but rather across modules. This is where Rust nudges developers to make the right choices for successful programming "in the large", while still providing the "unsafe" featureset for safety assurances within a single, self-contained context.

> Rust ignores many [safety models]

...

>I'd like to see some actual examples

When I said opinionated and ignores I did not mean safety models. I meant programming concepts like OOP for example. And do not tell me that it is not needed, wrong, etc. It is totally fine and useful for some situations and not so much for others. Developer should have a choice.

>Rust creators do not have the ultimate authority to say what is the right way anyways. No one does.

If you feel that way, you are free to take the reigns and put unsafe blocks everywhere. Languages by design need to be opinionated (even stuff like machine language), and most of them do not let you say "it's cool, I know what I am doing here" to begin with.