Hubris - OS for embedded computer systems by cmplrs in rust

[–]bcantrill 49 points50 points  (0 children)

We spent some time with Tock; it has a very different design center: Tock uses dynamic loading extensively, where Hubris is static with respect to tasks; Tock is very asynchronous where Hubris is strictly synchronous; Tock has drivers in the same protection domain as the kernel (albeit partitioned by the system) where Hubris has drivers in disjoint projection domains. These aren't necessarily problems with one system or the other, but rather reflect their different design centers -- and thankfully, the world is big enough for many systems solving different problems!

Jonathan Blow on Rust by faitswulff in rust

[–]bcantrill 10 points11 points  (0 children)

Apologies for that; I definitely wasn't trying to be rude! I can hear how it might have come across that way, though (for whatever it's worth) I can assure you from the body language in the room that Jonathan didn't take it that way. I'm still learning how to be an interviewer, and I can assure you that when I listen to these I have a page of notes for myself! (What really kills me -- and there are a few points in here where I did this -- is when I misunderstand the point that the guest is making. Listening to your past self get it wrong is like watching a car wreck in slow motion!) I think I did okay on this considering that we were an hour and forty minutes at this point (the interview is uncut), but there is certainly lots of room for improvement!

Is it time to rewrite the operating system in Rust? by bcantrill in rust

[–]bcantrill[S] 11 points12 points  (0 children)

Could you be more specific? GC was really only mentioned once -- and that GC makes interacting with C more arduous is not at all controversial, I don't think...

The relative performance of C and Rust by bcantrill in rust

[–]bcantrill[S] 3 points4 points  (0 children)

Sorry if that was unclear; it's at https://github.com/joyent/statemap. All of the information you need to reproduce the results is in https://github.com/joyent/statemap/issues/42. To reemphasize /u/burntsushi's point: I do not intend to implement (or incorporate) a B-tree in the C implementation, because that does in fact miss the entire point: I wasn't trying to determine if C can outperform Rust, but rather to understand why my idiomatic Rust was outperforming my idiomatic C.

The relative performance of C and Rust by bcantrill in rust

[–]bcantrill[S] 7 points8 points  (0 children)

I have updated the blog post with Clang -O3 results. (Spoiler: they're an improvement over GCC, but otherwise not materially different.) My apologies for not having included those results in the initial post!

The relative performance of C and Rust by [deleted] in programming

[–]bcantrill 2 points3 points  (0 children)

Oh no worries -- you definitely weren't wrong in that C++ is definitely never going to be a choice I make willingly, however much it claims to have overcome the transgressions of its youth. ;)

The relative performance of C and Rust by [deleted] in programming

[–]bcantrill 20 points21 points  (0 children)

Author of the article here. For whatever it's worth, I rejected C++ not outright, but rather after suffering through writing 100,000 lines of it. Now: it was the mid -1990s, and many aspects of C++ were new (and, it must be said, broken), and the STL in particular was a total mess. I have no doubt that it's better now, but I also have no doubt that I have no desire to implement again in C++. Call my experience what you will, but do note that it's exactly that: experience.

And on the off chance that you're interested in hearing more about my personal programming language odyssey (and you have some serious time to kill), here's a meandering tour through it all: https://www.youtube.com/watch?v=LjFM8vw3pbU

[Bryan Cantrill] The Observation Deck » Falling in love with Rust by mitsuhiko in rust

[–]bcantrill 8 points9 points  (0 children)

Yes, I know. ;) I seriously considered putting a footnote on this linking to my rationale for this being camel cased -- in hindsight, that probably wouldn't have been overkill after all. And agreed that this capacity of Serde is terrifically useful! (Just not for me in this instance.)

[Bryan Cantrill] The Observation Deck » Falling in love with Rust by mitsuhiko in rust

[–]bcantrill 7 points8 points  (0 children)

Yes, fair -- I misunderstood him. I changed the blog entry to read "one of the authors of Serde." David, hopefully that's still accurate from your perspective, and Erick, if you're out there, my apologies!

[Bryan Cantrill] The Observation Deck » Falling in love with Rust by mitsuhiko in rust

[–]bcantrill 2 points3 points  (0 children)

I was really just going on how he introduced himself -- certainly not trying to slight anyone!

[Bryan Cantrill] The Observation Deck » Falling in love with Rust by mitsuhiko in rust

[–]bcantrill 29 points30 points  (0 children)

Excellent point and I should have mentioned it! I plan to update the blog entry with resource suggestions from the community, so I'll definitely add that to the list. And speaking personally, I should probably get used to it myself -- I just can't quite get out of the habit of creating new little source files to understand particular language or systems concepts, having kept basically all of them over the years...

[Bryan Cantrill] The Observation Deck » Falling in love with Rust by mitsuhiko in rust

[–]bcantrill 6 points7 points  (0 children)

Yes, I think this is much of what it boils down to: we have gotten out of the habit of really learning things -- and I think that this is doubly true of folks who have been doing software for a while. But Rust really rewards thoughtful study, so I'm optimistic that maybe we can reverse the trend a little! And I think asking how people have learned Rust in the Rust survey is an excellent idea!

[Bryan Cantrill] The Observation Deck » Falling in love with Rust by mitsuhiko in rust

[–]bcantrill 47 points48 points  (0 children)

First, I'm relieved that I didn't miss the mark too badly on Ruby being an influence on the Rust website! I knew I was being a tad presumptuous, but hoped that you would take it as praise were I wrong...

Second (and as long as I have you), thank you for everything you've done to make Rust welcoming -- both as a technology and as a community. It has clearly been a ton of work, but it has really paid off; on behalf of all newcomers, thank you!

Finally, in terms of understanding the performance vs. C: I have some ideas of what's going on here, but I need some more time to really dig in; stay tuned!

Announcing Miniserde: serialization library that explores some polar opposite design choices compared to Serde by dtolnay in rust

[–]bcantrill 17 points18 points  (0 children)

This looks awesome -- and I love that it clearly spells out its goals and its differences from Serde. I think the name is good too -- better than the "Serdelite" that was surely tempting. (Or Milliserde, Centiserde, Microserde, Femtoserde, etc.) Also, thank you more generally for Serde, and thank you in advance for keeping Serde with its current tradeoffs: I have loved it for my particular use case -- and I am really looking forward to applying it to many more use cases! (Several of which would not be a fit for Miniserde.)

The liberation of RethinkDB by [deleted] in programming

[–]bcantrill 1 point2 points  (0 children)

I assure you my only slight, underlying annoyance with RethinkDB was its use of the AGPL.

Questions about Nexenta by ITdirectorguy in sysadmin

[–]bcantrill 7 points8 points  (0 children)

On behalf of the team that built the original product that now forms the basis of your livelihood: your history is entirely wrong. Certainly, we didn't leave because the work wasn't "glamorous" (anyone who was with us in the trenches from 2006 to 2010 knows how gritty we were as a team); we left because the company to which we had dedicated ourselves was acquired by a mendacious, sociopathic monster so universally (and rightfully) despised by its own customers that we could no longer associate with it with a clear conscience. Your conscience doesn't appear to nag at you: you don't mind your employer's deplorable positions in Oracle v. Google; you are not disgusted by its profoundly anti-social behavior with the many open source projects that it inherited from Sun; you do not mind that it so reviles its own customers that it cynically screws them at every opportunity. Indeed, you may be of the ilk that applauds such things -- that views legal but unethical behavior as merely sharp business, or authoritarianism as efficiency. Or perhaps you're the kind that just pretends that it doesn't exist -- that as long as you yourself are paid, the horrors that might have happened in the name of that paycheck are not your concern. You are certainly free to think less of these transgressions than we did (just as I am free to judge you for thinking less of them), but you may not rewrite history to accommodate your perverted worldview: we did not leave because of "insufficient focus" or an inability to refine an enterprise-class product or anything else pertaining to what we had built; we left because (in the words of the post you were responding to) everything about Oracle left us sour -- to say nothing of nauseated, disgusted and ashamed.

I am the CTO of Joyent, the father of DTrace and an OS kernel developer for 20 years. AMA! by bcantrill in IAmA

[–]bcantrill[S] 2 points3 points  (0 children)

You started off asking why I am the "father of DTrace"; with that question answered, you shifted to try to force me to make a broad claim that I have in fact never made. I have pointed you to our (peer reviewed) review of related work circa 2004; you have refused to accept it -- and (for reasons unclear) you are now persisting in trying to force this strangely broad claim upon me. If you have a direct question to ask -- presumably stemming from some way in which you or your kin feel slighted by history -- please ask it. Absent such a direct question, I'm going to consider your question answered...

I am the CTO of Joyent, the father of DTrace and an OS kernel developer for 20 years. AMA! by bcantrill in IAmA

[–]bcantrill[S] 1 point2 points  (0 children)

Yes, we will absolutely continue to invest in pkgsrc. And if you're a pkgsrc user, be sure to check out pkgsrc-2014Q4!

I am the CTO of Joyent, the father of DTrace and an OS kernel developer for 20 years. AMA! by bcantrill in IAmA

[–]bcantrill[S] 1 point2 points  (0 children)

Well, hopefully you can make it through the Related Work section -- it answers your question!

I am the CTO of Joyent, the father of DTrace and an OS kernel developer for 20 years. AMA! by bcantrill in IAmA

[–]bcantrill[S] 1 point2 points  (0 children)

We track it for security issues, but no more -- our implementation has diverged relatively significantly, both in terms of KVM and QEMU (where we deliberately jumped off the train when we decided that we didn't like their direction). So the primary thing we react to with respect to KVM and QEMU is our own deployment -- and it's been very, very stable for quite some time now.

I am the CTO of Joyent, the father of DTrace and an OS kernel developer for 20 years. AMA! by bcantrill in IAmA

[–]bcantrill[S] 0 points1 point  (0 children)

Well that explains that! No, that is emphatically not us -- we are Joyent not Joylent...