Having so many students involved in Rust was huge. Definitely the most rewarding thing about working on Rust was seeing students get involved, grow, then turn that experience into a career, while seeding the industry with Rust talent.
Reddit also uses commonmark, plus some GitHub flavored markdown extensions, via the comrak library, plus some custom extensions. So Reddit markdown should mostly look like GitHub.
Reddit seems to use two different Markdown engines. I use old.reddit.com, and I've noticed that some users that use new Reddit post code in ``` blocks. That doesn't work on old Reddit where you need to put four spaces in front of every line for it to render as code, so it just looks messy. I'm guessing their WYSIWYG editor uses the ``` version.
I went looking for some examples and found these two. The first [0] is someone that tried to post a ``` block, but it's not rendering properly on old Reddit. It does render ok as a code block on new Reddit in a private window.
The second [1] is somebody that posted a ``` block but also indented all lines with four spaces. That renders as a code block with ``` lines before and after it on old Reddit, and as extra indented code on new Reddit.
If you use RES you can look at the raw Markdown code for each comment using the source link.
Maybe you´re thinking of inline code which use a single ` before and after the code content?
The old Reddit formatting wiki page doesn't mention ``` now I look, there's a note on new Reddit about sticking to spaces for compatability: https://www.reddit.com/wiki/markdown Would be nice if they fixed it indeed.
That version of Rust also did async I/O in the runtime. Async I/O has always been part of Rust. The model changed because there was too much overhead doing it the more ergonomic way and it got booted out of the runtime.
Just remembering this deck and thought it might be interesting to this audience. This is the very first public documentation about Rust (Servo is not actually defined in this deck...), Graydon's slides from the Mozilla Summit 2010, dated 2010/07/07.
As far as I can tell, beyond this talk, there wasn't a formal "announcement" about Rust's initial open-sourcing (if somebody knows otherwise please link). It was mentioned the next day on LtU: http://lambda-the-ultimate.org/node/4009
I can't speak for PingCAP in general, but I know that many of PingCAP's Rust projects are part of the TiKV org [1], which is explicitly trying to become more community-oriented as part of their move into the CNCF (I work for PingCAP on TiKV). This message won't reach far, but if somebody finds themselves having difficulties contributing to TiKV or communicating with TiKV maintainers, and they speak up on the TiKV slack, somebody will definitely take notice and try to help.
Not knowing the specifics of your experience, it might help to consider that most of PingCAP are Chinese, and some communicate in English better than others. In public forums like the issue tracker, they write in English to include the global software development community, but for some it is quite challenging.
I'm hopeful that the PingCAP process will improve and their projects will become easier to contribute to.
This project and its predecessor are so cool. I've been glad to see their continued progress.
It's probably not wise to post this, since I never talk about it publicly, he might not like it, and this thread should be about GrapheneOS, not Rust or myself. But with the mention of his Rust involvement and the history of CopperheadOS, I feel compelled at the moment to add some context and give him props.
He is an exceptionally skilled developer.
Some of his contributions to Rust were crucial. Of particular note, he re-designed Rust iterators to their current form. But he added to Rust so much more, both with his ideas and code.
And from what I recall he was in high school at the time. Amazing.
I happened to be the Rust team lead during much of his time contributing to the project, and a good deal of the blame for his departure belongs to me. It was a difficult learning experience for everyone.
It is totally fair to say that Rust would not be what it is today, both technically and socially, without him.
I was happy to see him rebound with CopperheadOS, and again here with GrapheneOS.
I remember him as a very Torvalds-like person, for better or worse.
I wanted him to stay a little more around the Rust 1.0 era because I thought as many warts as possible should have been fixed before the backward compatibility guarantee was made, but he left too early.
Didn't know about the CopperheadOS incident, too bad such a situation happened to him. Good to see it's kinda resolved now.
I'm not really up to speed on what the Rust team is thinking, but basically no. These are not the kinds of things the Rust team would do to improve ergonomics. Correctness is forefront in Rust. The only thing I can think of like this op that has seriously been considered is automatic cloning for trivial types like `Rc`.
The Rust team thinks really hard about correctness before making any decisions and isn't going to add any ridiculous footguns to the language unless there's some organizational catastrophe that puts monkeys in charge of decision making.
* `?` can propagate values/short circuit control flow, but it also contains a hidden type conversion. The target needs to be a known type for it to compile.
* A proposed `catch` construct will include implicit type conversion for its result value.
Some things that came up in the past but met resistance:
* Removing project structure from in-code to being defined by the filesystem.
* Hiding `Result` types in signatures with special syntax.
* Dropping immutable by default, though this was pre-1.0.
Also, `Rc` and `Arc` are good examples for this. They do seem trivial, but having them auto-clone would mean:
* Every newcomer who writes `fn foo(val: Arc<Bar>) {}` instead of `fn foo(val: &Arc<Bar>) {}` or `fn foo(val: &Bar) {}` will get an implicit atomic increment/decrement at every function call.
* It also makes it a lot harder to reason about code if you want to use a clone-on-mutation-unless-not-shared strategy.
I think RC examples are very good, but in the case of special syntax for Result, isn’t that a case where the two options are semantically the same, you just are wary of the less verbose/loud option (I have withoutboats’ post in mind here)?