Hacker News Reader

> The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one.

Programs written in Rust are empirically safer than programs written in C or C++.

> The higher the freedom, the better the results delivered by a sensible/knowledgeable person.

If that were true, then C and C++ code would be safer and more secure than programs written in memory-safe languages. Obviously, that's not the case.

> seriously doubt that developers with real-world experience can like or even accept most of what this language represents.

Lots of developers with real-world experience, including me, use Rust all the time without any more problems than they would have in any other language.

> > The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one

> Programs written in Rust are empirically safer than programs written in C or C++.

But Rust defines safety as being safe from the kinds of errors that the Rust compiler is capable of making one safe from (buffer overflows, race conditions, undefined behaviour, etc).

If one if distracted by trying to satisfy the borrow checker, they might overlook a logical error. People have limited concentration, patience and perseverance and usually have to work to deadlines.

Rust is great for writing high-performance code, or code that needs to be parallelised within a single process. However if performance is not a concern then a statically typed language with a GC is usually a better choice.

> If one if distracted by trying to satisfy the borrow checker

That distraction goes away with experience. Once you "get" how to structure ownership in the program in a borrow-checker friendly way, it stops being a problem.

Similarly, if you are used to dynamically typed languages, you may find static typing a distraction that tests your patience. But OTOH if you think in types and use design patterns for them, they become a tool to improve code reliability, not an obstacle.

In this case, safer == memory safety (which is not a Rust-specific thing), not general forms of correctness, and the comparison in the original comment is to C and C++, not statically typed languages with a GC.

Unless it has been edited, the original comment doesn't say memory safety, it says "so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one". The reply to that comment then interprets safety as memory safety and compares to C and C++. This is kind of my point.

Rust defines safety as memory safety, but unfortunately memory safety is only the tip of the iceberg when it comes to safety. Logic errors are just as pernicious.

Programmers have a natural bias towards solving problems with technical solutions, but for me, Rust's memory safety is achieved at the cost of a high productivity penalty and a moderate readability penalty. Both of these reduce my ability to understand and manually verify the code.

Whereas languages that achieve memory safety via a GC, allow me to focus my mental energy on writing correct code, not on memory management.

> Whereas languages that achieve memory safety via a GC, allow me to focus my mental energy on writing correct code, not on memory management.

Ownership type systems are supposed to rule out synchronization errors (say, data races), which is something you may want regardless of how memory is managed. Say, the research on ownership types that came out of MIT in early '00s worked with a subset of Java (see OOPSLA'02 "Ownership Types for Safe Programming: Preventing Data Races and Deadlocks").

> If one if distracted by trying to satisfy the borrow checker, they might overlook a logical error.

I see it the other way around. I let the compiler deal with the borrow and type checkers and to tell me what I missed, while I focus on the logic of the code.

> Rust is great for writing high-performance code

Some high-performance code is CPU bound. To approach advertised FLOPS figure on any modern CPU, you must manually write SIMD code (typically SSE, AVX, and/or NEON). It’s only in Rust nightly, and is very limited. Without SIMD, you’ll only use a small fraction of CPU’s computational power.

The only programming languages great for high-performance code are C and Fortran. C++ is also OK because C compatibility.

> and is very limited

You might be thinking of the `simd` crate, in which case, you're right. But we are getting closer and closer to exposing a large set of vendor intrinsics: https://github.com/rust-lang-nursery/stdsimd --- You can use it today on Rust nightly. This includes runtime CPU feature detection!

ripgrep is an example of a program that is written in Rust, is CPU bound and uses explicit SIMD in various places to speed up text search. (It hasn't moved to stdsimd yet and is still using the `simd` crate and the old platform intrinsics system exposed by rustc. But ripgrep will move to stdsimd soonish.)

Very good.

Finally, someone in Rust community realized we don’t want higher-level abstractions, we just want whatever the hell our hardware can do. If that thing will go stable, I will consider Rust for a next project (BTW, doing CAD/CAM stuff for Windows).

Feature detection is no big deal, it’s just a couple of lines in C.

But I’m curious how well that thing gonna work in practice? In C++ we have low-level control over memory layout allowing to place these SIMD vector values in STL containers with correct alignment. We have function pointers with vectorcall calling convention that enable implementing CPU-dependent routines very efficiently. The compiler inlines a lot of that SIMD code. Maybe you know how much of that applies to rust + stdsimd?

> Finally, someone in Rust community realized we don’t want higher-level abstractions, we just want whatever the hell our hardware can do. If that thing will go stable, I will consider Rust for a next project (BTW, doing CAD/CAM stuff for Windows).

That's great, but please consider that this is an unfair characterization. stdsimd has been in the works since 2016, and many people have been involved. It's not like nobody "realized" we needed to expose vendor intrinsics before then, but it just hadn't been worked on. It's a ton of work.

> Feature detection is no big deal, it’s just a couple of lines in C.

It's only a few lines in Rust as well. But this is spoken like someone who uses it instead of someone who was involved in making it available. :-) It's not just about querying the CPU, but enabling functions to compile with specific target and also reasoning through Rust's safety story there, which is non-trivial.

> But I’m curious how well that thing gonna work in practice? In C++ we have low-level control over memory layout allowing to place these SIMD vector values in STL containers with correct alignment. We have function pointers with vectorcall calling convention that enable implementing CPU-dependent routines very efficiently. The compiler inlines a lot of that SIMD code. Maybe you know how much of that applies to rust + stdsimd?

I don't see any reason why any of that would be a problem with Rust. Inlining is just as important to Rust as it is to C++, and so is control over memory layout. You should try it out and give feedback. :-) Now would be the time!

> It's not like nobody "realized" we needed to expose vendor intrinsics before then, but it just hadn't been worked on.

It had been... in 2015. :)

Errm, d'oh, sorry! :-( I had vendor intrinsics stuck in my head, but now that I say that, I of course now remember the platform intrinsic stuff.

One response I received to that argument was “not many projects need to multiply a lot of single-precision floating point matrices”.

Later additions, SSE2, SSE 4.1, SSSE3, add double-precision floating point, and 8-16-32-64 bit integers support. Some of them come with unsigned and saturated versions (the latter clips to min/max when overflown).

In C++, I use these for performance-critical functions doing integer computations, bit manipulation, image processing (saturated integer math is especially useful for the latter). While it adds some complexity to the code esp. when it benefits from SSE 4.1 or SSSE3 instructions (I must implement SSE2-only workarounds for older CPUs), the performance improvement IMO justifies that.

> Rust is great for writing high-performance code, or code that needs to be parallelised within a single process. However if performance is not a concern then a statically typed language with a GC is usually a better choice.

Are there Rust programmers who disagree with that?

It depends on context.

I don't think many would disagree that it would be easier, but better is very broad. Better in what way? For what purpose?

For example, if you already know Rust, then "easier" may (or may not, depending on what sense of easy you mean!) not be a compelling argument.

Rust is certainly not the best tool for every single task, but it also has broader applicability than "I can't possibly accept a GC."

I use Rust for all sorts of things that don't need to be high performance, because I know Rust very well. But I don't think it's the ideal choice for most of those tasks--although I will say that I wish more languages had (for example) the same approach to namespacing that Rust takes, or as nice of a package manager, those are things that could coexist with a very different language. I imagine most Rust programmers would agree...

I don't see too many job offers for Rust developers, I see plenty for C and C++ though.

The youth of the language should be a reasonable predictor of that difference, alone.

It may indeed turn out that the way Rust's learning curve is front-loaded will prevent it from breaking into the mainstream, but that's a separate issue from developers deciding it's unsuitable for work after they learn it.

With the exception of swift - which has the distinct advantage of being one of two languages you can write programs in for the most popular (? probably true since Android's market share is scattered across many models) piece of consumer hardware in the world - I can't think of a language of similar age to or younger than rust with as many job ads.

You see plenty for C/C++ because they've existed forever, have a huge amount of code written in them, and a huge number of programmers who already know them. Just like with Cobal you will almost certainly see plenty for C/C++ many years into the future. That doesn't really say much about Rust.

You have successfuly uncovered that Rust is a fundamentally different programming language, instead of a variation of the same. I feel that having learned Rust, any new language similar to Rust would have way lower learning curve. It is quite similar to the jump required from imperative to a funtional language. We may be missing a good name for a paradigm the Rust falls into.

Achieving Rust's safety in C took separation logic with the best tool probably being VCC from Microsoft. I encourage anyone that thinks the borrow checker is unnecessarily hard or alternative languages would be easy to try doing an existing Rust library or app in VCC with separation logic. Also, if applicable, ensure it passes soubd, static analysis to be free of any defects Rust's design would stop in that library that C doesnt.

Then you'll appreciate the work languages like Cyclone and then Rust save you. There's other models published and in development that might make the next one a bit easier. Yet, separation logic is the proper comparison to borrow checker and most programmers didnt try to learn it.

Have a look at Idris, ATS, Liquid Haskell, F* or Cyclone, then maybe you will appreciate Rust from another angle.

Esoteric programming language :)

> The higher the freedom, the better the results delivered by a sensible/knowledgeable person.

Experience has shown this hypothesis to be false, especially concerning low level systems programming languages and security issues.

Neither of you has said explicitly what you mean by "better" and likely have different measures in mind when saying it here.

Until we have as much code written in Rust as is currently implemented in C, experience hasn't shown anything. The same claims and promises have been made for C++ in relation to vanilla C for ages, and it's just not true. An experienced C coder (which arguably takes longer to achieve) will perform as good as a C++ coder of equal skill level. All they do is trade complexity and convenience for simplicity and flexibility; it's a matter of preference, not life and death.

This working group literally just proved that a significant subset of Rust is safer than any comparable subset of C++. This isn't a matter of opinion. What more proof do you actually want than a formal proof? I seriously wonder what people think the whole point of this paper was.

The main difference that I've seen between C and Rust compiler errors is that, with C, my reaction is "goddamnit, you know what I mean, why can't you just accept it?!", whereas with Rust my reaction is "oh yes, I see how that may cause problems".

I'm sorry you found Rust hard, but it really is a world apart from Perl. I started learning programming using assembly (Motorola 68k), and then went a different professional route (via Java and Javascript).

Rust to me is back to basics. There is a stack, and there is a heap. Many languages mask this from you, but notably C/C++ doesn't, and although it's a notch up in complexity from Perl, the control you get over these aspects lets you write code that is equivalent to C/C++ in performance. Something Perl/Go can do for you under some scenarios, but mostly not.

Granted, not everyone needs/wants to understand or work closer to the system.

And not everyone who needs/wants that is going to prefer Rust's complexity and rigidness to the simplicity and flexibility of C, or the even more complex yet more flexible C++. It's preferences, priorities; not black or white; no one has any right to force anyone to do anything. As long as humans are in the loop we're going to have bugs, what kinds of bugs will depend on priorities.

Rust is a direct contender to C and C++, not to script or GC languages. Please compare apples to apples.

For some languages, that distinction doesn't seem to apply. For example, it seems that the D language can be treated as both a scripting language and a system language, as the speed of compilation + execution can be comparable to that of scripting languages. For evidence of this, take a look at the first D versus Python comparison in this article, note that both scripts have comparable execution times (both finished running in under a second):

http://tech.adroll.com/blog/data/2014/11/17/d-is-for-data-sc...

It should be noted that D has a number of different compilers, offering the user the choice between compilation speed and optimisation.

There are effectively two Ds: one that's garbage collected and one that's manually memory managed and unsafe. I don't think you can really consider them equivalent: there's always a large difference in development friction when you move from a managed environment to an unmanaged one.

> "There are effectively two Ds"

Could you not also say there are effectively two Rusts?

https://doc.rust-lang.org/book/second-edition/ch19-01-unsafe...

"Rust has a second language hiding out inside of it, unsafe Rust, which does not enforce these memory safety guarantees. Unsafe Rust works just like regular Rust does, but it gives you extra superpowers not available in safe Rust code."

By the way, I don't say this as a criticism, I admire what the Rust team are doing, and will be glad to check out the language again in the future.

You can, but there is a big difference: betterC is a subset of D, whereas unsafe Rust is a superset of safe Rust. That is, when you use unsafe, you don't lose any language features. When you drop into betterC, you do lose a bunch of stuff from D.

You don't have to restrict yourself to betterC to use manual memory management. BetterC is mainly targetted at embedded programming and to port components of existing C applications. Malloc vs. GC vs. stdx-allocator is a separate topic, though betterC doesn't link with the GC by default.

Yes, thanks. Last I checked, you still lose features if you use manual memory management, betterC or no. Has this changed recently?

You loose builtin arrays and hashes and need to use a container library instead. Same goes for newing aggegates which can be replaced with smart pointers. Escaping closures (delegates) no longer works, but you can explicitly capture context in a struct.

Those choices for builtin language features date back to the early inspiration from Java, but are increasingly being replaced with library implementations. We've added escape checking to the type system last year, and are currently working on safe aliasing (preventing use-after-free).

So yes, atm. when opting for @nogc you're somewhat at the frontier, and it's mostly a choice if you have time, hard requirements, or am very practised.

Avoiding most (but not all) GC allocations is already widely adopted in D's community though.

Thank you! I'm excited to see this stuff progress, but since I'm not involved with D anymore, it's hard to keep up at times :)

Only for some code it's not apples to apples. For most code GC is not a big deal and the languages just offer different tradeoffs. Perl, for example, has XS for performance critical code, which is essentially C or C++. But the ecosystem is big enough that you don't necessarily need to write any C code yourself.

And all of this is not even relevant to usability issues he tries to discuss.