Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type-Safe Unions in C++ and Rust

genbattle.bitbucket.org

Post reply on HN
Print view View original

71–80 of 140 posts

Re: Type-Safe Unions in C++ and Rust

#71

Post by dbaupp »

bandrami wrote: post #55
Manishearth wrote: post #6

Earlier quoted context omitted.

One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…

the concurrency safety model (Send+Sync), though that might be old too Smalltalk has had that since the early 1980s

Like steveklabnik, I'm extremely curious to hear more about how Smalltalk's concurrency model is just like Rust's. The latter is a fairly flexible model to defend against data races (which seems to be a concept only really formalised in the late 80s) that puts most of the power in the programmer's hands (i.e. no need for compiler-inserted locks on every object, etc.) that comes from a finely balanced combination of the trait system and the manner in which Rust controls mutation.

It would be great to see how other languages have achieved a similar balance, and my impression is that Smalltalk (and like most languages) does not put nearly as much effort into controlling mutability, but maybe I'm wrong. Could you post some links/a description that explores how Smalltalk achieves a similar level of safety?

Re: Type-Safe Unions in C++ and Rust

#72

Post by bluejekyll »

froydnj wrote: post #68
bluejekyll wrote: post #64

Earlier quoted context omitted.

I feel like this point is often made about C++: "in the future we will have that feature too!" If you don't want to wait, want to experiment with something else, learn a new language, etc., Rust is awesome. Obviously the counter argument to this is, "but there's 30+ years of C++ in production", but be honest, who actually wants to work on a 30 year old codebase?

GCC is very close to the 30-year mark (0.9 released 22 March 1987). Linux turned 25 this past year; Firefox (the C++ parts, at least) is very close to 25, depending on what code you want to count. Apache is 20ish years old. Even LLVM, which I think of as a relatively young project, is getting close to 15 years. Maybe (hopefully?) very little code survives from the initial versions, but they've all withstood the test…

:) I'm glad others enjoy doing it. Definitely one of the things I like about Rust at this point is the freshness.

Re: Type-Safe Unions in C++ and Rust

#73

Post by clappski »

bluejekyll wrote: post #64
hellofunk wrote: post #62

Earlier quoted context omitted.

For pattern matching, that's true. And my response is, stay tuned. C++ has a lot more to offer in this area in the future. std::variant is opening a big door for all kinds of new features in the language, and for those who cannot wait, there are pattern matching libraries out there to peak at.

I feel like this point is often made about C++: "in the future we will have that feature too!" If you don't want to wait, want to experiment with something else, learn a new language, etc., Rust is awesome. Obviously the counter argument to this is, "but there's 30+ years of C++ in production", but be honest, who actually wants to work on a 30 year old codebase?

It's not about want, it's about a requirement that they're maintained, expanded.

Re: Type-Safe Unions in C++ and Rust

#74

Post by bluejekyll »

clappski wrote: post #73
bluejekyll wrote: post #64

Earlier quoted context omitted.

I feel like this point is often made about C++: "in the future we will have that feature too!" If you don't want to wait, want to experiment with something else, learn a new language, etc., Rust is awesome. Obviously the counter argument to this is, "but there's 30+ years of C++ in production", but be honest, who actually wants to work on a 30 year old codebase?

It's not about want, it's about a requirement that they're maintained, expanded.

Yes, and perhaps I'm shirking my duty as a developer by wanting to avoid some ugly gnarly code. I will say this, I would be more likely to want to contribute to projects like these if they incorporated Rust as an alternative to C or C++ for their development.

Re: Type-Safe Unions in C++ and Rust

#75

Post by nickpsecurity »

dbaupp wrote: post #71
bandrami wrote: post #55

Earlier quoted context omitted.

the concurrency safety model (Send+Sync), though that might be old too Smalltalk has had that since the early 1980s

Like steveklabnik, I'm extremely curious to hear more about how Smalltalk's concurrency model is just like Rust's. The latter is a fairly flexible model to defend against data races (which seems to be a concept only really formalised in the late 80s) that puts most of the power in the programmer's hands (i.e. no need for compiler-inserted locks on every object, etc.) that comes from a finely balanced combination of t…

"which seems to be a concept only really formalised in the late 80s"

http://brinch-hansen.net/papers/1975a.pdf

http://brinch-hansen.net/papers/

His first, concurrent OS was RC 4000 in 1969. It had many mechanisms in place. He got the key parts of the safety problem figured out by 1972. His language to handle much of it statically at compile-time was done in 1975. His Boss 2 system same year used coroutines + similar concepts to run 100 activities at a time with a proof of deadlock freedom. Finally, he used Concurrent Pascal to implement Solo system which ran its processes safely without using physical, memory protection. These summaries came from "Evolution of Operating Systems" on 2nd link.

So, the stuff was well-established by the mid-70's with operating systems using it in production. Just ignored by mainstream like a lot of good stuff for various reasons. ;)

Re: Type-Safe Unions in C++ and Rust

#76

Post by catnaroek »

Manishearth wrote: post #6
flyx86 wrote: post #3

> but it’s the first language I’ve experimented with that has made them a first-class feature It is a feature of ALGOL68, Pascal, Ada and quite some newer languages: https://en.wikipedia.org/wiki/Tagged_union

One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…

Indeed. Regions are 20 years old. Substructural types are 30 years old. Type inference is 40 years old. Hierarchical module systems fancier than Rust's are at least 30 years old. With the exception of regions, all this stuff is older than I am, myself. But Rust took all these isolated good ideas and made a practical programming language out of it.

Re: Type-Safe Unions in C++ and Rust

#77

Post by sidlls »

bluejekyll wrote: post #69
sidlls wrote: post #67

Earlier quoted context omitted.

I can write reliable code requiring less maintenance in C or C++. What you're engaging in is language zealotry. Rust isn't a panacea.

I think you're reading into the comment too much. Rust by definition, will create a safer variant of whatever similar code you write in C or C++. This isn't really debatable, things like bounds checking on arrays, strongly typed error results, thread safe memory sharing semantics. These will absolutely guarantee that in general you will have safer code in Rust. What I said is that it might take you longer to write it…

Ah, I see now. Thank you for clarifying. Not that I agree entirely, mind, just that your initial comment was clarified.

Re: Type-Safe Unions in C++ and Rust

#78

Post by nickpsecurity »

gpderetta wrote: post #34
rurban wrote: post #33

Earlier quoted context omitted.

Putting them well together in Rust is debatable. Writing proper and safe concurrent code in Rust still looks horrible compared to languages which supports it natively in the type system, e.g. ponylang type capabilities. You still have to manually maintain locks, and it's also much slower. There's a safety model, but it's only best practice, not enforced by the language nor the compiler. So calling it "safe" and "trul…

Having a language-imposed concurrency model would be useless and actively harmful in a system language. Rust provides the building blocks to build whatever safe abstractions are appropriate for the problem and domain at hand, plus a set of out of the box abstractions relatively low level that will be familiar to people coming from other system languages. And of course the means to get rid of any abstraction and safet…

It worked great for Concurrent Pascal and Solo:

http://brinch-hansen.net/papers/

I agree it's better to have mechanisms that can be turned into a proper model. A good default, though, greatly improves consistency and reliability in real-world systems.

Re: Type-Safe Unions in C++ and Rust

#79

Post by alexeiz »

hellofunk wrote: post #12
logicchains wrote: post #9

Note C++2017's std::variant is based upon boost::variant, which has been around since at least 2004 ( http://www.boost.org/doc/libs/1_31_0/doc/html/variant.html , http://www.boost.org/users/history/ ). boost::variant however lacks a nice visit method that takes lambdas, instead requiring the user to create visitor classes. This verbosity may be part of the reason it wasn't adopted in mass, in spite of its advantages…

They are implemented completely differently. The only real similarity is in the name and API. Boost variant suffers from significant performance penalties that the new std::variant does not have.

If you look at http://www.boost.org/doc/libs/1_62_0/doc/html/variant/design..., Boost variant has no performance penalty due to backup storage if any of its bounded type is nothrow default-constructible. In practice, you just need a single nothrow default-constructible type in boost::variant to satisfy that requirement. This can be `int` or `boost::blank`. And that's that - no performance penalty.

Re: Type-Safe Unions in C++ and Rust

#80

Post by dbaupp »

nickpsecurity wrote: post #75
dbaupp wrote: post #71

Earlier quoted context omitted.

Like steveklabnik, I'm extremely curious to hear more about how Smalltalk's concurrency model is just like Rust's. The latter is a fairly flexible model to defend against data races (which seems to be a concept only really formalised in the late 80s) that puts most of the power in the programmer's hands (i.e. no need for compiler-inserted locks on every object, etc.) that comes from a finely balanced combination of t…

"which seems to be a concept only really formalised in the late 80s" http://brinch-hansen.net/papers/1975a.pdf http://brinch-hansen.net/papers/ His first, concurrent OS was RC 4000 in 1969. It had many mechanisms in place. He got the key parts of the safety problem figured out by 1972. His language to handle much of it statically at compile-time was done in 1975. His Boss 2 system same year used coroutines + similar…

I don't have time to read it in full right now, but a quick glance over that paper doesn't show any formalisation of data races, which is specifically what that parenthetical is about, not just general "concurrency safety". Having a detailed description of concept seems important because Rust is fairly precise in what it defends against, possibly giving the programmer more flexibility and power than in a system that attempts to solve many problems (but of course giving them less assistance when writing something that fits within the rules of the more defensive languages). Of course, it's possible that a language "accidentally" solves that problem without it having been formalised, it just seems less likely.
Post reply on HN