comparaison Probableur a typeaux?
[deleted]
Safety: A comparaison between Rust, C++ and Go
81–90 of 188 posts
Re: Safety: A comparaison between Rust, C++ and Go
#82 This would be a better article if the UB in the C++ example wasn't blindingly obvious-- no C++ programmer worth a damn would ever write this.
Re: Safety: A comparaison between Rust, C++ and Go
#83Earlier quoted context omitted.
> They are remarkably similar, just with different defaults. I'm going to lead with this, because I think it's most important: Culturally there's a world of difference. Safety is a part of Rust's culture . "Culture eats strategy for breakfast". Take sorting. In C++ the default sort is unstable, while in Rust the default sort is stable, that's just those defaults you mentioned (each has both kinds), although the choic…
The sibling says that C++ has the wrong defaults, full stop. Well in Rust the default `HashMap` uses a cryptographic hash, and you see it everywhere , it's the de facto community "default". In C++ the community "default" is `absl::flat_hash_map`/`folly::F14`, which use SIMD to compare a whole stripe of key-prefixes simultaneously. I want different defaults for different programs, but the idea that it's esoteric to ev…
Why do you think that a language with better details would prevent you from opting in to whatever non-default behavior you need?
Having the "right" defaults is better for everyone. Folks who don't know or care get a good, safe default with no undefined behavior or unexpected danger, and folks who know better can opt into something that fits their needs explicitly.
Seems ideal to me.
Re: Safety: A comparaison between Rust, C++ and Go
#84Earlier quoted context omitted.
> They are remarkably similar, just with different defaults. I'm going to lead with this, because I think it's most important: Culturally there's a world of difference. Safety is a part of Rust's culture . "Culture eats strategy for breakfast". Take sorting. In C++ the default sort is unstable, while in Rust the default sort is stable, that's just those defaults you mentioned (each has both kinds), although the choic…
The sibling says that C++ has the wrong defaults, full stop. Well in Rust the default `HashMap` uses a cryptographic hash, and you see it everywhere , it's the de facto community "default". In C++ the community "default" is `absl::flat_hash_map`/`folly::F14`, which use SIMD to compare a whole stripe of key-prefixes simultaneously. I want different defaults for different programs, but the idea that it's esoteric to ev…
> In C++ the community "default" is `absl::flat_hash_map`/`folly::F14`, which use SIMD to compare a whole stripe of key-prefixes simultaneously.
Just to be clear, the Rust HashMap does the same thing.
Re: Safety: A comparaison between Rust, C++ and Go
#85Earlier quoted context omitted.
I think memory safety is the killer feature of rust, and has become so because people see the real world problem it's solving, more than through evangelicalism. We'll see in a few years when more "heavy shit" has been written/rewritten in rust. My prediction is that they will have significantly fewer memory safety issues than comparable c++ "heavy shit".
> We'll see in a few years when more "heavy shit" has been written/rewritten in rust. I'd really like to see that. Would be cool to see a completely new Linux user space written in Rust. Not necessarily a rewrite of existing software, new ideas would be great. I tested Linux system calls and they worked very well even though they needed experimental inline assembly functionality to work. With system call support, any…
Slowly there's more and more implementations emerging of Linux userland utils in Rust.
It's taking a while.
Re: Safety: A comparaison between Rust, C++ and Go
#86Earlier quoted context omitted.
>Why do people say things like: "It's better not to dilute the message"? >Better for who? Better for everyone. When talking about a new thing, it would be really silly to emphasize how nice the logo is, how nice the package it comes in is, look at the awesome tape the box is closed with etc. If I turn the product off it even turns off! Look at the nice rounded corners of the device! It even can do async! Just like Ja…
I mean "message" how you want, HN is hosted in a free country. But N=1 for you: as a serious polyglot user of Rust who knows it well and uses it all the time: this shit is a huge turnoff. It's a programming language. On a long enough timeline all the motivated hackers will end up knowing many programming languages well, they all have pros and cons. Trying to boil important engineering decisions down to a tweet so tha…
Rust is a programming language. It’s the right tool for the job of programming. It happens to have a lot of features that make it a very good programming language.
I think you’re wrong about the language and community, though. It’s killer feature is it’s safety, be it memory, data race, or type. These are the reasons I was interested in learning the language. The fact that the tools make that easier is why I was able to struggle through the new concepts and actually be able to build useful things with it.
If the fact that people enjoy something as a general community turns you off, that’s not the community’s problem.
Re: Safety: A comparaison between Rust, C++ and Go
#87Earlier quoted context omitted.
I think memory safety is the killer feature of rust, and has become so because people see the real world problem it's solving, more than through evangelicalism. We'll see in a few years when more "heavy shit" has been written/rewritten in rust. My prediction is that they will have significantly fewer memory safety issues than comparable c++ "heavy shit".
From where I sit the killer feature of Rust is that a bunch of amazingly cool software is written in it, especially in the terminal. I'm a big terminal guy, and I can't think off the top of my head of anything I use constantly that isn't written in Rust. `rg`, `fzf`, `zoxide`, `bat`, `viddy`, the list goes on and on, I fucking love the shit people are writing in Rust. And I think that should be the killer feature of…
Terminal programs are one area where Rust's strengths seem to align (very good CLI libraries/parsing, error management, and concurrency) and weaknesses are less relevant (async, GUIs), which might be why it seems to be gaining traction in that area.
Re: Safety: A comparaison between Rust, C++ and Go
#88Earlier quoted context omitted.
>a crashed program is a crashed program whether I dereferenced a null pointer or was poking around in a slice with multi-byte Unicode characters in it Most of the biggest advances in software engineering are because of increased modularity. One of the best traditional ways to increase modularity is the ability to define and call functions. But any isolation between these "function" modules is only possible if you can…
Rust's thread safety only applies to the special case of those threads accessing in process data segments. Rust's type system can do very little to help when those threads are accessing the same record on a database without transactions, OS IPC on shared memory, manipulating files without locks, handling hardware signals, handling duplicate RPC calls,... Yeah but that ultimately requires an unsafe block, kind of true…
This is a point that you constantly bring up in these threads, do you think most developers believe that data race safety should extend beyond the bounds of the process?
One thing that Rust’s type system does allow you to do is define a consistent manner in which to access external systems, even add types that will mimic the same safety. Is it perfect? Will it protect you from a different process working against the DB? Will it enforce things in the other process? No. But will it give you higher level semantics to be able to construct a better model for operating against that external system? Yes.
Re: Safety: A comparaison between Rust, C++ and Go
#89Earlier quoted context omitted.
>The bad C++ code is in the very first line of the "make_appender" definition: capturing the closure's environment by reference is nonsense: It is equivalent to returning a reference to an argument. If it is so bad, it should (in the sense of how things would be in an ideal world) not compile. >It is not, then, a closure at all. It is a closure because all variables are closed-over and there are no free variables in…
"Doctor, it hurts when I do that!"
Pain is a strong warning that prevents [further] trauma. This analogy defeats its own purpose.
Re: Safety: A comparaison between Rust, C++ and Go
#90Earlier quoted context omitted.
>Why do people say things like: "It's better not to dilute the message"? >Better for who? Better for everyone. When talking about a new thing, it would be really silly to emphasize how nice the logo is, how nice the package it comes in is, look at the awesome tape the box is closed with etc. If I turn the product off it even turns off! Look at the nice rounded corners of the device! It even can do async! Just like Ja…
I mean "message" how you want, HN is hosted in a free country. But N=1 for you: as a serious polyglot user of Rust who knows it well and uses it all the time: this shit is a huge turnoff. It's a programming language. On a long enough timeline all the motivated hackers will end up knowing many programming languages well, they all have pros and cons. Trying to boil important engineering decisions down to a tweet so tha…
I think you have a point. Rust is primarily focused on being a systems language, and memory safety is the killer feature it brings to the table in that domain. But we know that Rust is being used in areas where its qualities as a systems language are less important.
Why, for example, would a Python developer pick up Rust? Probably because of the really strict typing addressing a major pain point for most Python developers and the trait system being somewhat analogous to Protocols, which any Python developer who has chafed with the dynamic typing is almost certainly already familiar with. With good library support for interfacing between the two, it's a more natural coupling than most people would think on the face of it.
That said, while I don't think a Python developer reaches for Rust because of memory safety, I do think it's still an important factor as it provides the guard rails that make it so someone who has primarily used a GC language and not had to concern themselves as much with managing memory can start using Rust knowing that the compiler is not going to let them accidentally shoot them in the foot when it comes to memory management.