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

Rust in QEMU Roadmap

lore.kernel.org

Post reply on HN
Print view View original

151–160 of 184 posts

Re: Rust in QEMU Roadmap

#151

Post by IshKebab »

Neywiny wrote: post #140
IshKebab wrote: post #125

Earlier quoted context omitted.

I don't think he literally means templates and classes. Rust has equivalents that do the things you want templates and classes for (generics and structs/traits respectively). I completely agree with his point about reimplementing C++ badly in C. GNOME does this too in their libraries. He will be much happier with Rust.

Hmmm I think I actually really want classes. Something that combines data and methods together without more function pointers. Template vs generic I don't care about

Rust structs do bind data and methods together.

Re: Rust in QEMU Roadmap

#152

Post by qalmakka »

bobajeff wrote: post #43
qalmakka wrote: post #26

Earlier quoted context omitted.

C++, especially before C++11, was a total mess. Even today, it's super easy to shoot yourself in the foot and you literally can't learn the entirety of the language due to how massive it is. This still doesn't justify doing the absurdity of macro magic and garbage I've seen people pumping out in C over the years though. IMHO if you deliberately use C it's because you want to keep things simple. Sometimes C++ will ine…

The GObject system for all it's faults serves a purpose. Similar to COM in Windows it allows mapping of higher level languages to libraries. Without it there wouldn't be all the bindings we have to Python, JavaScript, Vala and Rust today. I wouldn't say it was poorly thought out so much as mismatched with it's user's typical uses and expectations.

Yeah but it made literally zero sense to write GObject in C. They've reimplemented inheritance and the like with macro BS while the GNU project literally had both a C++ and Objective-C compiler - Objective-C warts and all was a perfect fit for GObject.

Re: Rust in QEMU Roadmap

#153

Post by lloeki »

ThePhysicist wrote: post #25
masklinn wrote: post #22

Earlier quoted context omitted.

> I'm not a rust user but if it lets me use classes and templates, I'll switch over Yer not switching any time soon then. Rust does have methods but not classes (QOM’s inheritance is specifically called as an issue in TFA) and it uses Haskell-style generics rather than C++-style templates.

I mean it has polymorphism via v-tables and composition via traits, that's enough object-orientation for me. Inheritance is a core principle of OOP but in practice most C++ class hierarchies are relatively flat (there are exceptions like Qt, which I think uses inheritance in a good way), in practice most of that can be mimicked with embedding and composition well enough to work. Not sure if you want to call that obje…

> Inheritance is a core principle of OOP

Of Simula (& descendants) proto-OOP objects, not as it was envisioned by the one who coined the term.

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

> I didn't like the way Simula I or Simula 67 did inheritance (though I thought Nygaard and Dahl were just tremendous thinkers and designers). So I decided to leave out inheritance as a built-in feature until I understood it better.

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP.

Fun that this was mentioned too:

>> it uses Haskell-style generics

> polymorphism via v-tables and composition via traits, that's enough object-orientation for me

For which Alan Kay had this to say:

> My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful. The term "polymorphism" was imposed much later (I think by Peter Wegner) and it isn't quite valid, since it really comes from the nomenclature of functions, and I wanted quite a bit more than functions. I made up a term "genericity" for dealing with generic behaviors in a quasi-algebraic form.

In a way it's fascinating to see how C++ has shaped (dare I say warped) the collective vision of how to do OOP.

For example, as a Rubyist, which was heavily influenced by Smalltalk, it is fascinating how hard it can be to explain how fundamentally different message vs call are, and what's the whole point of modules, mostly because the other viewpoint is so warped as to cognitively reject that it can be any different from the C++ model.

Re: Rust in QEMU Roadmap

#154

Post by flohofwoe »

david-gpu wrote: post #143
o11c wrote: post #55

Earlier quoted context omitted.

> Related to this, the IsA trait allows typesafe compile-time checked casts. Unlike in C code, casting to a superclass can be written in such a way that the compiler will complain if the destination type is not a superclass, and with zero runtime cost. This is unfair to C. With a little work when defining all classes (or non-leaf classes if you're willing for a hairier implementation), you can do this there too. Ther…

As a recovering language lawyer, I need to point out that what you are describing is not portable behavior because it is writing to one member of a union and reading from a different member, if I understood you correctly. Will it work on most tool chains? Yes. But when it doesn't, it is going to be fun .

AFAIK this is legal in C but not in C++, e.g. type punning via union is explicitly allowed in C (one of many subtle differences between actual C and the C subset of C++).

Re: Rust in QEMU Roadmap

#155

Post by david-gpu »

flohofwoe wrote: post #154
david-gpu wrote: post #143

Earlier quoted context omitted.

As a recovering language lawyer, I need to point out that what you are describing is not portable behavior because it is writing to one member of a union and reading from a different member, if I understood you correctly. Will it work on most tool chains? Yes. But when it doesn't, it is going to be fun .

AFAIK this is legal in C but not in C++, e.g. type punning via union is explicitly allowed in C (one of many subtle differences between actual C and the C subset of C++).

Looking at the ISO 9899:2018 spec, a few sections appear to be relevant.

This one I wasn't familiar with, and I believe it absolves the comment I initially replied to in this thread.

> 6.5.2.3.6 states:

> One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the completed type of the union is visible

Outside of that special case, the general semantics of unions are specified as follows. I think that means you are right?

> 6.2.6.1.7 states

> When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values

Re: Rust in QEMU Roadmap

#156

Post by School-Cotton »

bluGill wrote: post #101
melon_tusk wrote: post #98

Earlier quoted context omitted.

"as productive as Ruby or Python" So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python. I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, n…

In C++ I have learned the patterns and so I rarely need to worry about lifetime - everything is either on the stack or a unique_ptr. Even when I need to take a pointer I know I don't own it but my project has clear lifetime rules and so I normally won't run into issues. The above is not perfect. I do sometimes mess up, but it is rare, and that is C++ so I don't get tools/the language helping me.

Ok, but wouldn’t it be nice to have a language that checks all that automatically? (And is much nicer than C++ in most other ways too.)

Re: Rust in QEMU Roadmap

#157

Post by School-Cotton »

jdefr89 wrote: post #104
jodrellblank wrote: post #65

Earlier quoted context omitted.

> "The current trend of rewriting everything in Rust is out of control and misguided... EDIT: lcamtuf does a great job explaining my perspective on Rust push https://lcamtuf.substack.com/p/a-reactionary-take-on-memory- ... " The current trend is people rewriting Unix command line utilities in Rust, as a hobby. Nobody is rewriting Adobe PhotoShop or Oracle in Rust. Can you name some projects which you class as "out of…

Alright so I exaggerated a bit for sure. But I am seeing way too much “Rust in the silver bullet” nonsense…

Rust is obviously not a silver bullet that solves all problems and no experienced rust user is claiming it is.

Re: Rust in QEMU Roadmap

#158

Post by flohofwoe »

david-gpu wrote: post #155
flohofwoe wrote: post #154

Earlier quoted context omitted.

AFAIK this is legal in C but not in C++, e.g. type punning via union is explicitly allowed in C (one of many subtle differences between actual C and the C subset of C++).

Looking at the ISO 9899:2018 spec, a few sections appear to be relevant. This one I wasn't familiar with, and I believe it absolves the comment I initially replied to in this thread. > 6.5.2.3.6 states: > One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these…

There is also a footnote:

99) If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.

...it all makes sense until that last sentence, maybe that's for really weird bit casts like trying to reinterpret an integer as float. FWIW the only place I used union type punning was in an Z80 emulator for the 16-bit register pairs, but that's no longer necessary, since modern compilers will optimize two consequitive byte reads into a single word read:

https://www.godbolt.org/z/or7Woc4TP

Re: Rust in QEMU Roadmap

#159

Post by bluGill »

School-Cotton wrote: post #156
bluGill wrote: post #101

Earlier quoted context omitted.

In C++ I have learned the patterns and so I rarely need to worry about lifetime - everything is either on the stack or a unique_ptr. Even when I need to take a pointer I know I don't own it but my project has clear lifetime rules and so I normally won't run into issues. The above is not perfect. I do sometimes mess up, but it is rare, and that is C++ so I don't get tools/the language helping me.

Ok, but wouldn’t it be nice to have a language that checks all that automatically? (And is much nicer than C++ in most other ways too.)

I've long been intrigued by rust for their claims on those lines. But I can't justify a billion dollars and many years to rewrite our current c++. that means anything would need to understand c++ types so I can call existing functions that need a vector or implement a virtual function on an existing interface.

We are actually looking at a different option: break up our processes and use IPC. There are architecture reasons to do this, but that means the IPC is something we can define and so some of those processes would be all new code that could then be written in rust. Others of them would be small enough that it is feasable to rewrite in rust without blowing the schedule/budget. However that still leave the vast majority of our code as C++ for the foreseeable future.

Re: Rust in QEMU Roadmap

#160

Post by bluGill »

School-Cotton wrote: post #118
bluGill wrote: post #99

Earlier quoted context omitted.

You are confusing best practice for what is done all too often. Unsafe should be small blocks, but I've seen people put unsafe on everything even though it isn't needed thus making it hard to find where it is needed. I'm not a rust programmer, but I'm lead to believe that those people then do things that need unsafe - but a safe option not only exists but would have been easier to write.

For very low-level stuff (e.g. embedded) you might need a lot of unsafe. For the vast majority of software it’s extremely rare. I worked full time for five years on a Rust project ( https://github.com/MaterializeInc/materialize ) and anecdotally, unsafe code was much less than 1% of the codebase.

I don't have direct experience, but from what I can gather between others, and my general embedded experience, unsafe in the worse case of embedded would still be just a small percentage of all code. (a device driver which would need unsafe to deal with hardware still has a lot of code that doesn't deal with hardware)

There is some rust code out there that is more than 50% unsafe though.

Post reply on HN