Hacker News Reader

Comment by leshow | Hacker News Reader

> Go is faster than Java / C#, more memory-efficient than Java / C#, and definitely has better concurrency than Java / C#

C# is a great language and has a ton of modern features. It's also quite a bit faster than the author is giving it credit for. In fact there was a network stack written in it that was posted here last week that had it beating Go by an order of magnitude.

I don't really agree with the statement that 'Rust is a better C++' either. It very much can take the place of C in many applications also.

View on HN

"beating Go by an order of magnitude."

This is not what happend, Go was faster until batch size was > 16 then C# took over, but still C# latency was 2-3x higher than Go in every benchmarks.

Also C# / Java had to use C code where the Go driver was pure Go.

https://github.com/ixy-languages/ixy-languages/raw/master/im...

At 20Mpp/sec the C# latency was no longer on the graph:

https://github.com/ixy-languages/ixy-languages/raw/master/im...

I think it's fascinating that someone could look at those graphs and come away with the conclusion that c# is an order of magnitude faster than go.

On the repo page, there’s a latency graph, and on it there are two green lines. One is for Javascript and has poor latencies. The other is Go and has some of the best latencies. Because the Go one is clustered with other overlapping lines, I think people often misinterpret the Javascript line as the Go line.

https://github.com/ixy-languages/ixy-languages

It's also fascinating that someone could look at those graphs and say that "Go was faster until batch size was > 16 then C# took over," when Go was barely faster but C# was significantly faster.

Well, in my defense, I wasn't looking at the graph when I wrote that, I was trying to remember a graph that I saw a week ago.

C# had to use C code due to lack of .NET knowledge of the authors as discussed on the other thread.

Would be interesting to get a PR then and see the difference.

If you go to the other thread someone posted a GitHub gist showing how to use mlock() from C#, which apparently was impossible to do.

There would be 20 fewer lines of C?

Yes, interop and Span<> should be fine...

As if you have a choice to not use pure Go code, it doesn't play nice with C.

Cgo is a very well supported paradigm and many projects use cgo copiously.

I considered using Rust for a project, but I ended up going with C# because it appeared to have better support for Oracle database access and I could easily have a nice Windows desktop UI. C# seems more mature or fleshed out, but some of that may just be due to the "simplicity" of Go.

GUI is definitely an open problem in Rust, but to be fair, cross platform GUI is hard. In all of programming, it seems that Qt is about the best that we have when it comes to cross platform GUI, and I don't think most Rust developers care enough about Windows to write and maintain native Windows-only GUI libraries. C# (or I guess F# or any of the other .NET languages) is definitely a better fit for Windows UI programming.

If I was doing windows programming I would definitely write a c# GUI everyday-all day over what's currently available in rust, but still do my business logic in Rust :) . I simply adore the language at this point.

I agree. .NET is not bad at all. I work with F# and like the results

BUT

Is easier to make faster/memory-efficient app in Rust or Go than in .NET.

The "defaults" of a language matter a lot. And what it give for "free" impacts a lot. Specially for the code made by less skilled OR skilled-but-tired developers.

Go is garbage-collected just like .NET.

Rust indeed always pushes you towards efficiency :)

Not necessarily. I've moved C++ code to C#, and it got much faster. The reason is because of copy (and other flavors of) c'tors that needlessly copied data because it was either happening unbeknownst to the author, or it was easier than dealing with the consequences of proper aliasing semantics. I have a feeling that this is not uncommon. So IOW, bad manual memory management is going to perform worse than modern GC systems. Pretty much the same as an automatic transmission on a high-end sports sedan -- unless you really know what you're doing, the AT is going to do a better job of shifting than you are.

> Go is garbage-collected just like .NET.

And I bet the .NET GC is much better than Go.

But what I was trying to say is that is very common in .NET to build layers of layers of abstraction. .NET is still largely used by a lot of "enterprisey" developers with bad or non-existence training.

With Go you get a much simpler deal: You have structs (like POCOS in C#) and you pass them. Sometimes, you put traits.

Is alike what is preached for good F#/C# code, but .NET still carry the inertia.

However, if you get into .NET with modern runtime (aka: around 4.5+) and idioms then I think the results will be very good.

'Rust is a better C++' works well in that, insofar as C++ aimed at being a better C, (IMO) Rust seems well positioned to do it better.

What features does Rust have that C++ lacks that allows it to be used as a C replacement when C++ can't be?

Memory safety?

C++ has lots of bells and whistles, some of which Rust doesn't have (classes, to name one), but those aren't necessarily more important bells and whistles.

Also, the Rust infrastructure is light-years ahead of linking in libraries in C/C++. Compile times are higher, but not horribly so.

> Also, the Rust infrastructure is light-years ahead of linking in libraries in C/C++. Compile times are higher, but not horribly so.

Sorry, but you've got this backwards. From a user's perspective, cargo seems like a much nicer build system than the more-or-less manual build systems of make et al. But that's because cargo is opinionated and inflexible: it really wants to be the primary driver of the build system, and it also doesn't quite support all of the things you can do with custom linking.

As a result, when you have large projects composed of multiple libraries, your choices are either to drive rustc manually and skip cargo altogether, or to create a single macro crate for cargo to link all the rust code as a sublibrary for linking into your main project code. You end up with something like this: https://dxr.mozilla.org/mozilla-central/source/toolkit/libra... to describe all of the Rust libraries you have in your project.

What you're saying is essentially that Cargo follows the principle of "easy things should be easy; hard things should be possible". CMake, Autotools, Make, etc. do not follow this principle; hard things are possible, but easy things are not easy. This might look like inflexibility, but I don't really see that. Cargo does let you do hard things; it's just that it has a "normal" workflow as well, which makes the simple case simple.

... is that bad?

Seems different. But it doesn't seem bad.

Granted, I've not worked on a project of that size, but it seems to me that if it works for 'normal' sized projects quite well and works as well as anything else for large projects (as in, nothing works perfectly for large projects, they all need tweaking), then it is ahead of the alternatives.

What it shows is that Rust's aggressive approach to static linking means that it doesn't slot into build systems the same way that C/C++ code does. This has benefits for smaller projects, but it probably discourages use in larger projects.

I don't know what all of the trade-offs are, so I don't know where the current situation sits in this space. https://gist.github.com/rylev/0e3c3895dcb40b6a1c1cf8c427c01b... is the minutes of a session between the scary-custom-build-system people discussing (among other things) the pain points of cargo with their build systems.

That only happens in an extremely small amount of cases. Almost all of the time cargo does nothing but make your life easier.

No tool is perfect, but the team seems pretty dedicated to improving things.

Sure, but memory safety is irrelevant when considering C++ as a C replacement (C++'s memory safety, terrible as it is, is not worse than C's). I'm purely curious as to why you'd be able to write something in either a) C b) Rust but not c) C++.

You are reading that backwards. The comment said that Rust is better positioned as a C replacement than it is as a C++ replacement. It said nothing about C being able to do things C++ can’t.

I think that's true. Also given the dominance of C in the unix eco system, it's a more important problem to solve.

> Sure, but memory safety is irrelevant when considering C++ as a C replacement (C++'s memory safety, terrible as it is, is not worse than C's).

Wouldn't it be fair to say that reducing memory unsafety as much as possible without hurting performance is a good goal to have when making a replacement for C? Assuming that's the case, it's relevant that C++ doesn't eliminate it as much as Rust when comparing the two languages as C replacements.

(1) Memory safety guarantees through the ownership model, a clear delineation of unsafe code that doesn't follow it. Also, no UD.

(2) Both Rust and C++ can be used to write most / all of the code that can be written in C, at a zero runtime cost. Their difference is in ergonomics, safety features, ecosystem maturity, etc.

Arguably, the point is precisely that Rust lacks features that C++ has which make C++ not as good as it could be at replacing C.

Rust has put more effort than C++ into figuring out how much of the standard library can be used in "freestanding environments" (to borrow the C terminology). C++ without exceptions, RTTI, and the standard library is already a pretty effective C replacement.

The other "feature" that C++ has in this space is that it has a bad reputation as far as the C stalwarts are concerned, whereas Rust has not gained that reputation.

C++ isn't very homogenous in the features that people use. I was speaking more to the fact that one can use Rust in situations where C traditionally dominates. OS's, embedded development. It's memory safety model allows you to section off unsafe code and craft safe interfaces while still operating on the bare metal. Like sibling comments mentioned, no_std is pretty great too.

I don't think the parent was saying you can use Rust anywhere you can't use C++. I think they were saying, Rust is not only a good C++ alternative, but also a good C alternative.

Assuming GP's post was not edited, I don't see where it implies that Rust can be used as a C replacement where C++ can't.

This is a good question, and it's a shame that none of the responses so far answer it.

The answer to that specific question is borrow checker (i.e. memory safety) and much better type system.

Those things can't be essential in a C replacement, because C doesn't have them. The statement implies that there are things C can do that C++ can't but Rust can.

Reply on news.ycombinator.com