6 ms·

> 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

by leshow 7y ago

> 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.

patrec 7y ago
What features does Rust have that C++ lacks that allows it to be used as a C replacement when C++ can't be?
- w56rjrtyu6ru 7y ago
  Compile-time memory safety by default.
- pdpi 7y ago
  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.
- nine_k 7y ago
  (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.
- eximius 7y ago
  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.
  - patrec 7y ago
    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++.
    - ummonk 7y ago
      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.
      - patrec 7y ago
        I think that's true. Also given the dominance of C in the unix eco system, it's a more important problem to solve.
    - saghm 7y ago
      > 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.
  - jcranmer 7y ago
    > 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/library/rust/shared/Cargo.toml https://dxr.mozilla.org/mozilla-central/source/toolkit/libra... to describe all of the Rust libraries you have in your project.
- kyllo 7y ago
  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.
- twic 7y ago
  This is a good question, and it's a shame that none of the responses so far answer it.
  - ummonk 7y ago
    The answer to that specific question is borrow checker (i.e. memory safety) and much better type system.
    - twic 7y ago
      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.
- jcranmer 7y ago
  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.
- dthul 7y ago
  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.
- leshow 7y ago
  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.
pdpi 7y ago
'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.
Thaxll 7y ago
"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/img/batches-3.3.png https://github.com/ixy-languages/ixy-languages/raw/master/im... https://github.com/ixy-languages/ixy-languages/raw/master/img/latency-hdr-hist-10.png 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/img/latency-hdr-hist-20.png https://github.com/ixy-languages/ixy-languages/raw/master/im...
- tedunangst 7y ago
  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.
  - zeeboo 7y ago
    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 https://github.com/ixy-languages/ixy-languages
  - leshow 7y ago
    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.
  - joelfolksy 7y ago
    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.
- c0ff33 7y ago
deleted 7y ago
[deleted]
cicero 7y ago
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.
- PyroLagus 7y ago
  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.
  - stjohnswarts 7y ago
    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.
mamcx 7y ago
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.
- floatboth 7y ago
  Go is garbage-collected just like .NET. Rust indeed always pushes you towards efficiency :)
  - thelazydogsback 7y ago
    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.
  - mamcx 7y ago
    > 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.

by leshow 7y ago

patrec 7y ago

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

w56rjrtyu6ru 7y ago
Compile-time memory safety by default.
pdpi 7y ago
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.
nine_k 7y ago
(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.
eximius 7y ago
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.
- patrec 7y ago
  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++.
  - ummonk 7y ago
    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.
    - patrec 7y ago
      I think that's true. Also given the dominance of C in the unix eco system, it's a more important problem to solve.
  - saghm 7y ago
    > 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.
- jcranmer 7y ago
  > 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/library/rust/shared/Cargo.toml https://dxr.mozilla.org/mozilla-central/source/toolkit/libra... to describe all of the Rust libraries you have in your project.
kyllo 7y ago
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.
twic 7y ago
This is a good question, and it's a shame that none of the responses so far answer it.
- ummonk 7y ago
  The answer to that specific question is borrow checker (i.e. memory safety) and much better type system.
  - twic 7y ago
    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.
jcranmer 7y ago
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.
dthul 7y ago
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.
leshow 7y ago
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.

pdpi 7y ago

'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.

Thaxll 7y ago

"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/img/batches-3.3.png https://github.com/ixy-languages/ixy-languages/raw/master/im... https://github.com/ixy-languages/ixy-languages/raw/master/img/latency-hdr-hist-10.png 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/img/latency-hdr-hist-20.png https://github.com/ixy-languages/ixy-languages/raw/master/im...

tedunangst 7y ago
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.
- zeeboo 7y ago
  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 https://github.com/ixy-languages/ixy-languages
- leshow 7y ago
  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.
- joelfolksy 7y ago
  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.
c0ff33 7y ago

deleted 7y ago

[deleted]

cicero 7y ago

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.

PyroLagus 7y ago
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.
- stjohnswarts 7y ago
  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.

mamcx 7y ago

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.

floatboth 7y ago
Go is garbage-collected just like .NET. Rust indeed always pushes you towards efficiency :)
- thelazydogsback 7y ago
  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.
- mamcx 7y ago
  > 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.