Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Rust and C++

kukuruku.co

Post reply on HN
Print view View original

61–70 of 139 posts

Re: Comparing Rust and C++

#61

Post by blub »

JulianMorrison wrote: post #44
claudius wrote: post #6

It might be a good idea to compare C++ and Rust and not “C with Classes and no use of compiler options” and Rust. They do have a fair point about ugly template error messages, but the remaining issues are mostly moot: Freed memory issues can be avoided using std::unique_ptr and its siblings, lost pointers to local variables shouldn’t occur when using references instead of pointers, uninitialised variables are warned…

C++ is like a fairytale forest, where staying on the one safe path through the woods (unmarked, known only by whispered lore) will give you a reliable system, but where you are constantly tempted by easier-looking diversions at the end of which lurk grues. And heaven help you if nobody has yet whispered to you the secret of the one safe path. Or if you consulted an older textbook, and the idiom it taught has a grue.

It's pretty well known that one should read Stroustrup's book and the Meyers books. If one were to learn in a vacuum, perhaps they would take a false path, but the community is in agreement on what the best learning resources are.

As cute as your comment is trying to be, most languages cannot be learned by blindly trying things out, one should actually read a few books, try to be a part of the community and so on.

Re: Comparing Rust and C++

#62

Post by humanrebar »

nly wrote: post #55
humanrebar wrote: post #53

Earlier quoted context omitted.

HTTP is welcome, but I'll take logging, JSON, XML, unit testing, and a database interaction layer before that. Most of those are types of "serialization", I guess, but I'll go ahead and be a little more specific. And a type-safe dependency injection framework wouldn't be the worst thing in the world either.

HTTP is a continued pain point for C++ I find. It falls in to an impossible valley of "too simple for anyone to have bothered writing a really good standalone library" and "too complex to write myself". I don't see anyone jumping at the chance to build a HTTP request state machine built on top of nothing but the standard library when the standard library has no standard solution for efficient asynchronous operations…

I'm not saying it's not needed, but there's a huge chunk of the C++ world that doesn't do web development. The other things I mentioned are more generally useful. In particular, XML support probably needs to come before HTTP support.

Not that I'd turn my nose up at standard HTTP support.

Re: Comparing Rust and C++

#63

Post by bjz_ »

p0nce wrote: post #47
ekidd wrote: post #42

Earlier quoted context omitted.

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. The main Rust community tries to discourage Rust "zealotry." For example, on /r/rust, the rules include: 4. When mentioning other languages, keep the discussion civil. No zealotry! Anyway, as for your other question: E.g. something like boost asio would be between hard to impossible to implement in Rust because the…

> 4. When mentioning other languages, keep the discussion civil. No zealotry! This article still reads like zealotry. No tradeoffs are shown, only praise. C++ examples are alien. Like GP, I had the same experience with C++ templates being able to do more things than Rust's traits (like templating by a value).

I think the emphasis was meant to be on "the main Rust community". I would hope that most of us would try our best not to misrepresent other people's hard work. I definitely agree that whilst Rust's generics are far nicer to work with thank duck-typed templates, there are still gaps when it comes to matching C++'s expressive metaprogramming. Templating over values, constexprs and variadic type parameter lists are the main ones. I do know that the former two are planned, but that will have to be after 1.0.

Re: Comparing Rust and C++

#64

Post by nly »

skriticos2 wrote: post #57
nly wrote: post #51

Comparing languages with constraints which were laid in bedrock 30 years apart is fairly uninteresting. C++ is constrained by its compatibility with C, and always will be. Even C++17, which will be the biggest shift in the language ever, won't change this. I see very little evidence that most programmers actually care about the advantages Rust the language , as specified today, brings. I'd contest that these days the…

It's tricky and there is no one-language-to-rule-them-all because they have up- and downsides. C++ has the advantage of an incredible amount of code written in over the years that mostly works. It also executes fast. It's also easy to find developers for it. With the new addons to the specification it's even possible to write readable code with it.. However, it has a stupidly long, verbose and feature creepy standard…

The C++ language specification is only ~450 pages, the rest of the ~1200 or so pages is the standard library specification.

> Java.. I'm not entirely sure what Java does well.

* Package/module system is dead "drop your JAR here" simple.

* Humongous standard library.

* Oracle provide a really powerful free JIT (probably still one of best for real world performance when it comes to JITing static languages)

* Standardised language specification (like C and C++)

* A well specified, really simple bytecode that other compilers and runtimes can target.

* It's a newbie friendly, procedural, object-oriented language that encourages 'patterns' that make developers feel comfortable and that they know how to tackle problems (whether it's the right way is another matter)

* Relatively safe, meaning there is less to learn (no pointers, memory management, arithmetic overflow etc).

Re: Comparing Rust and C++

#65

Post by humanrebar »

skriticos2 wrote: post #57
nly wrote: post #51

Comparing languages with constraints which were laid in bedrock 30 years apart is fairly uninteresting. C++ is constrained by its compatibility with C, and always will be. Even C++17, which will be the biggest shift in the language ever, won't change this. I see very little evidence that most programmers actually care about the advantages Rust the language , as specified today, brings. I'd contest that these days the…

It's tricky and there is no one-language-to-rule-them-all because they have up- and downsides. C++ has the advantage of an incredible amount of code written in over the years that mostly works. It also executes fast. It's also easy to find developers for it. With the new addons to the specification it's even possible to write readable code with it.. However, it has a stupidly long, verbose and feature creepy standard…

I'd disagree that Go is a systems programming language in the way that C++ is a systems programming language. As in, I'm not sure you would implement a garbage collector in Go. However, both Go and the typical processor are evolving, to that may change over time.

To be fair, if I were wanting to find all matches for a regular expression in a given text file, I sure wouldn't use C++, even though C++ is certainly capable of doing that.

Re: Comparing Rust and C++

#66

Post by lmm »

frozenport wrote: post #28
shmerl wrote: post #12

Earlier quoted context omitted.

What do you mean less common? Less commonly used or less commonly useful? Idiomatic C++11 discourages usage of raw pointers altogether. C++ introduced RAII ideas quite a long time ago, it's just in practice they weren't always followed and only in C++11 they were backed by standardized features from stdc++. Rust has an advantage of following this approach from the very beginning and not having all kind of legacy bagg…

Not only legacy, many hardware vendors provide only C bindings leaving the management of resources to the user.

How many hardware vendors provide any kind of Rust bindings at all? Let's compare like with like.

Re: Comparing Rust and C++

#67

Post by humanrebar »

Kilgort wrote: post #41
Matthias247 wrote: post #36

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. Yes, Rust has some interesting safety features that prevent some issues that you can run into with C++ (but not all). And yes, most of us will agree that header files suck and the rust approach here is nicer. That template error message are also PITA is also well known - but on the other hand templates are differen…

shared_ptr thing(new SomeThing()); shared_ptr iface = thing Rust is not OOP language, so it's logical that it can't do this. Rust got type system more like Haskell, and for me it's a big plus as I don't like C++ OOP that was taken from Simula and not even from SmallTalk. I don't like talking like this, but C++ OOP is complete trash(beat me for talking like this). Also you are saying that Rust is not alternative for C…

> shared_ptr thing(new SomeThing()); shared_ptr iface = thing

Not sure what you're trying to do there, but Rust can certainly alias one object with more than one trait reference. In this particular case, you're using two mutable references to the same object, which Rust doesn't allow. But if both were immutable references, there wouldn't be an issue, assuming the right declarations preceded your code.

Re: Comparing Rust and C++

#68

Post by kibwen »

I've flagged this because not only is it an unfair characterization of C++, it's also using a version of Rust that is six months out of date.

As a Rust fan, I don't think we need to resort to cheap shots. The language stands well enough on its own; misinformation and propaganda pieces won't get us anywhere.

Re: Comparing Rust and C++

#69

Post by Matthias247 »

keeperofdakeys wrote: post #40
Matthias247 wrote: post #36

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. Yes, Rust has some interesting safety features that prevent some issues that you can run into with C++ (but not all). And yes, most of us will agree that header files suck and the rust approach here is nicer. That template error message are also PITA is also well known - but on the other hand templates are differen…

Just on your last point, Rust does have the ability to do unsafe code (and many multi-threading primitives use these internally). The real question is, how can these be exposed to Rust in a way that plays nicely with other Rust code. There are things like RefCell, which enables multiple threads to hold a reference to an object, with run-time checking of borrows. Or there are also explicit mutex wrappers that can be u…

The real question is, how can these be exposed to Rust in a way that plays nicely with other Rust code.

Yes, that's exactly the question I'm asking myself. I know that you can do everything in unsafe, but as soon as I step into that mode I'm getting the feeling that it might end up in the same level as C++ or probably even more complicated.

It probably shouldn't have to do with dealing explicitly with mutexes. If you have to I think that things like std::sync::Mutex are no good solutions because they are not really general purpose. If you really deal with low-level multithreading problems you often have multiple mutexes that might need to be locked in a special order and the mutexes are normally part of a data structure and do not own the data.

But multithreading is only a part of the whole problem. The other one is achieving easy-to-use and safe concurrency in a single thread (like Javascript APIs).

Re: Comparing Rust and C++

#70

Post by nly »

humanrebar wrote: post #62
nly wrote: post #55

Earlier quoted context omitted.

HTTP is a continued pain point for C++ I find. It falls in to an impossible valley of "too simple for anyone to have bothered writing a really good standalone library" and "too complex to write myself". I don't see anyone jumping at the chance to build a HTTP request state machine built on top of nothing but the standard library when the standard library has no standard solution for efficient asynchronous operations…

I'm not saying it's not needed, but there's a huge chunk of the C++ world that doesn't do web development. The other things I mentioned are more generally useful. In particular, XML support probably needs to come before HTTP support. Not that I'd turn my nose up at standard HTTP support.

I recommend the libraries from CodeSynthesis for your XML and database needs. The documentation for both is superb, and the APIs are crisp and modern. JSON I'd go with either JSON Spirit (boost header dependency) or JsonCpp (git version[0], since there hasn't been a release in 3 and a half years. 1.0 was tagged recently though)

For webdev I've personally used CppCMS, which is of good quality, although it is a framework and not a toolkit (it's MVC and the views want to use inheritance, has its own networking and template framework etc)

[0] https://github.com/open-source-parsers/jsoncpp

Post reply on HN