Hacker News Reader

Comment by lmm | Hacker News Reader

I think Rust's merits are real but mostly those of OCaml or Haskell which have been around for decades. I'm glad to see an ML-family language finally having a cultural moment - it's a bit unfortunate that it comes with manual memory management that 99% of programmers don't need, but it's still a great thing.

Rust is also giving the - to put it bluntly - idiots - who insist their application has to be written C or C++ "because it's fast" a better language without having to overcome that idiocy. I'm not sure if that's a good or a bad thing - it's beneficial in the short term, but letting idiotic attitudes towards performance persist seems like storing up trouble for the future.

For the people who genuinely need manual memory management Rust is a major breakthrough. But those people are such a tiny niche as to not be worth worrying about. People who claim to need manual memory management are overwhelmingly likely to be in the previous category.

View on HN

> it's a bit unfortunate that it comes with manual memory management that 99% of programmers don't need

For what I've seen, that's actually the #1 feature of Rust.

A programmer who wants to use a ML-like language that doesn't need that feature should instead be using Haskell or F#; Rust is designed for systems-level programming, where being able to control every cycle of the processor is important. For that, you need manual memory management.

>A programmer who wants to use a ML-like language that doesn't need that feature should instead be using Haskell or F#

Or ocaml...

> A programmer who wants to use a ML-like language that doesn't need that feature should instead be using Haskell or F#

Indeed. Since I think that's the majority of programmers (whether they know it or not), I wish it was Haskell and F# that were getting the mainstream attention, and Rust that was the niche language with the, well, small cult following.

Well I'm one of those idiots then. Currently, I'm employed to write very fast scientific and engineering software. We work almost entirely in C because it gives the performance we need (and not just because of memory management). Programming in C makes it very easy to assess what is causing performance bottlenecks as the disassembly maps tightly to the C code (typically 1:3 to 1:6 source to instruction ratio). This makes it easy to assess if the symbolic code needs changing or the compiler just isn't doing a good enough job and you may need to use intrinsics or rewrite in assembly. And I can tell you this is a massive sector employing a lot of engineers.

I mean, what do you want me to say? Yes, judging by what you've said and without knowing the details of your requirements, I think it's most likely you (and your organization) are among the idiots. I've worked in that sector, replacing that kind of code with higher-level code in a "slow" language that somehow managed to run orders of magnitude faster, because when you're in the trees of disassembly and intrinsics it's all too easy to miss the forest of using the wrong algorithm or even making a calculation that just isn't necessary. Even in the cases where you don't make that kind of mistake, you can fix a problem with generated assembly as many times as you like and it will all be worthless compared to fixing the problem in the compiler once and for all.

There is good, valuable work being done in that world, don't get me wrong, and it's entirely possible you're on that side of things - but it's very much the exception rather than the rule IME.

Well if you use a poor implementation or the wrong algorithm then you're going to get poorer performance in any language. However, all things being equal, you're not going to get better performance from a higher level language and you certainly cannot fine tune the implementation for a particular platform as you can with lower level code - that's a fact. Now whether it is worthwhile doing that depends on each case and how long the process takes to execute. I often prototype in higher level languages including R, Python and C#. Once I need a professional implementation or put them into commercial software I use C even if the front end is written in C#. C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.

> all things being equal, you're not going to get better performance from a higher level language

Not remotely true if one of those things being equal is programmer time/effort, IME.

> you certainly cannot fine tune the implementation for a particular platform as you can with lower level code

Compilers can and do. JIT can allow even better tuning than is possible in C, as it can take the input data into account.

> C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.

Not remotely supported by any benchmark I've ever seen. The latest techempower benchmarks show a factor of 1.3x-7x difference between C and C# depending on the benchmark; the shootout is similar as far as I can tell from the unhelpful website. Not even a single order of magnitude, much less orders plural. (And benchmarks are the best possible case for C: tiny pieces of code where you can do a level of manual tuning that would be completely unreasonable to do on realistic-sized programs).

You're entitled to your opinion of course.

Just for fun try implementing gauss jordan method in C# - it is prohibitively slow once you go beyond a dimension of 10 where you have millions of linear systems to solve. C has no problem even with much, much larger systems. As for data size - rule number one, when implementing a numerical method you always vectorise and unroll where possible. That means padding your data to a multiple that eliminates remainder loops and helps compiler exploitation of SIMD or VXA. If padding cannot be applied for a particular numerical method then use sparse or elimination methods to get the requisite multiple. In short, you control the data size, alignment and packing - the programmer determines what is best for the target platform and doesn't leave it in the hands of the run-time environment gods.

In my experience there are orders of magnitude differences between C and C# when you get down to heavyweight number crunching. I implemented a simple kriging method in C# as a demo for my colleagues it took about 2 minutes for a really modest situation with handful of controls and low resolution grid. I was actually concerned that my implementation was really crap. I migrated the same algorithm over to C and it took about 5 seconds. In fairness that was about 5 years ago but makes the point. For other things like FFTs there is only a gain of about x2 migrating to the C language. But that modest change is probably due to the fact that both the C# implementation and C implementations are using native libraries for cos and sin which is typically where the bottleneck is for any DFT implementation.

We're both entitled to our opinions, but I've mentioned a couple of specific public (published) benchmarks for mine - do you have anything like that for yours?

Links would be good. And on that...

Could you provide a link to heavy numerical operations - btw, ones that use native libraries don't count cause it ain't the C# implementation doing the work? As I've said there are some routines where C# performs fine but for heavy-weight modelling requiring intense arithmetic matrix/vector operations it is just too slow. What's more the benchmark for a single run does not always scale to many. The overhead becomes compounded when you're doing the same operation over and over again due to GC and cache misses.

http://www.sebastiansylvan.com/post/why-most-high-level-lang...

I love C#, I think it is a great language but it just doesn't belong at the level where I NEED to code at.

https://msdn.microsoft.com/en-us/library/ms973852.aspx

C is a pain in the ass to do the things that C# is good at. If it works for you across the board then fine but I would stop assuming everyone else is an idiot.

But those people are such a tiny niche as to not be worth worrying about.

I don't disagree with your assessment, but one reason why there's enthusiasm for Rust is that this niche hasn't had any real alternatives (save maybe D?) for years.

I agree. In particular because that tiny niche is the one that builds the core infrastructure where every other userspace platform runs :-)

Reply on news.ycombinator.com