We have the core team to provide overall oversight over all of these teams to ensure things are coherent.

It’s not the best language ever, but it is better at this point than similar languages such as Python or Ruby (good async, good type system, good module system, no decades-long versioning crisis).

The last part of your comment hints that your objections to Rust’s governance may be more political than language design related.

I checked the code of conduct and it didn't seem too political to me, internet forums have had those kinds of rules for decades. What it is, though, is an example of an administrative artifact, too many of which will suck energy away as top level people spend more and more of their time not thinking about the end product.

My question is: are there any compiler which predate Roslyn in this aspect? Anders Heijlsberg said in a video once, that this is modern compiler architecture (compared to the outdated Dragon and Tiger) but did not mention that the Roslyn team invented it.

Another earlier example of successful incremental technology was the Java compiler in Eclipse.

I'm sure there are academic efforts as well, but don't know as much about these.

Note that “incremental parsing” is a nice to have, but is not required for IDEs. What is required are lazy name resolution and lazy type inference.

Well, I think you need incremental compilation of you want to a achieve the performance in the ms range an editor needs.

A few exceptions are that async/await was not finished, but that is not for lack of trying (from what I gather), so this is excusable. The 2018 roadmap did correctly indicate what would be worked on throughout most of 2018, even if some things took longer than expected.

I think a roadmap is only a failure if it gets ignored and none of the stuff mentioned in the roadmap gets worked on at all. I've been at some dysfunctional startups like this, for a time the company tries to rally the developers, a roadmap is made, people feel good, the next week the CEO decides to go in a completely different direction and then things are back to being dysfunctional, and nobody ever thinks about the roadmap again.

It does seem like "macros 2.0" might have fallen through the cracks? As far as I know they were never finished and I haven't heard much about their progress.

We shipped the biggest part, which is "procedural macros," which shipped in 1.30. https://blog.rust-lang.org/2018/10/25/Rust-1.30.0.html#proce...

As I said below, we didn't ship hygiene for them, so there's more work to be done. There's also future work around "macros by example 2.0", but this item on the roadmap was mostly talking about proc macros.

So what other languages features are coming? Or could Rust enjoy a stable period of little to no changes for a few years. After all Rust is modern enough in almost all cases. Unlike other languages still trying to get features in within their own constrain.

People are working on it, it's just that its pure development work, nothing worthy of being announced yet.

Out of the stuff called out there, everything other than async/await shipped, most in total, some in part. Custom allocators didn't fully ship, only the global custom allocators did so far. Hygene didn't ship for macros 2.0, but the non-hygenic ones did.

But yes, after that, the big issue is the syntax issues around async/await. Working on it!

As an experienced Rust developer I can usually deal with the borrow checker, but sometimes I'm still annoyed by its limitations or hit them without expecting to hit them. Most of the times this happens it's either because I want to partially access a struct in a closure, or do something that's now allowed by NLL. So this is a big deal.

https://doc.rust-lang.org/edition-guide/rust-2018/ownership-...

https://stackoverflow.com/questions/50251487/what-are-non-le...

http://smallcultfollowing.com/babysteps/blog/2017/03/01/nest...

[1] https://www.amazon.com/Programming-Rust-Fast-Systems-Develop...

[1] https://github.com/toshi-search/Toshi

Nope, well... Maybe next year! I've been eyeing Rust for embedded but until there are major players shipping IDEs that natively support it, it's just a hobby thing.

Embedded and IoT is about to get a lot bigger - if I was them I'd be focusing hard on it to make sure my language had a strong foothold for when there was a new hottness that all the kids start raving about.

https://github.com/rust-lang/rfcs/blob/master/text/2657-road...

Can anyone copy/paste it somewhere else ?

For example, C can often do this. You ask the linker to put a particular function first and to make everything position-independent. There can be some problems with the GNU toolchain stubbornly insisting on making a GOT, but the language is otherwise fully capable.

The canonical example is https://github.com/rust-embedded/cortex-m-rt if you want to get into the guts of how it works. For a more user-focused overview, check out https://github.com/rust-embedded/cortex-m-quickstart, which is a good starting point from which to drill down.

I'm curious what makes you think that? Culturally, I feel like there's been some general backlash to the gratuitous IoT-ification of every aspect of our lives, from a privacy perspective, a fragility perspective, and a "using apps to control everything isn't actually convenient" perspective: https://twitter.com/internetofshit

Those are three RTOSes specifically being designed to run IoT endpoints. I’m working with FreeRTOS and AWS IoT right now, and can tell you Amazon is taking it pretty seriously.

I think 90% of IoT are devices that don’t need to be connected - no doubt. But mine does and sometimes it’s there are pretty awesome use cases for it.

If Rust wants to make it to C-replacement, they should be bringing over backwards to get away from DoItAllYourself IDEs and into commercial products like Keil, IAR, Segger, Attolic, etc. I promise when E+++ or Swifterz or C% or whatever crazy new hotness shows up, Rust will be the hardest hit language to lose its enthusiasts.

https://social.msdn.microsoft.com/Forums/en-US/72ae0354-63eb...

The pearl is the typical set of recomendations of how good C developers are expected to write unsafe secure code.

When you read the marketing materials of Azure Sphere, it is all about security everywhere.

Another proof that while we need safer languages, we also need to improve C's security story, as this will keep on happening anyway.

The cynic in me thinks all these companies are just continuing to push on something people don't want because it's a gold-mine of data collection opportunities. The optimist wonders if IoT will settle down and mature into spaces where it's actually useful, and "90%...are devices that don’t need to be connected". We'll see, I suppose.

No doubt! And the dumbest of IoT products like “connected mattresses” should prove that.

In my own defense, I’m doing a LOT of work to never ask the user for an account or password, never logging personal data, just shipping a nice device that does a helpful thing. But.... there is an obvious temptation to RECORD IT ALL (figure out what to do with it later!), but I’d be a massive hypocrite.

For me it’ll be a selling point that we don’t care who you are just that you have a device and want to do a thing.

For those interested, check out Jorge Aparicio's (japaric) RTFM2 series:

http://blog.japaric.io/rtfm-v2/

(in particular the sections titled "Preemption" and "Critical sections and Threshold")

It’s a big leap from hobbiest to commercial with embedded.

If I was part of the Rust group I’d be directly real resources into real embedded projects. You check Cargo for embedded now and might find a couple unsupported header files for different micros.

It’s going to be a long time at this pace.

It is not obvious to me what more can the Rust team do here; it would seem like the ball is in the vendors court (or whoever counts as "major player"). Plenty of the groundwork has been already accomplished, and the embed-wg continues on their good work but they can't just conjure vendor support out of thin air

Maybe it’s too early for that. Maybe it’s just the right time.

They are doing exactly that if you look at the "Compiler" section of the roadmap[1].

> One project worth calling out in more detail is the RLS 2.0 effort. The existing RLS, while functional, was never deeply integrated into rustc itself. Over the past two years, we have rewritten the back end of rustc to use an incremental and demand-driven infrastructure. To get the IDE experience we truly want, we need to see that work through for the front end of the compiler as well. However, this part of rustc is one of its oldest, and there are significant design questions involved in how best to do that.

> This is where the RLS 2.0 effort comes in. The plan is to build a prototype of the new front-end, thus enabling a truly first-class IDE experience. Wherever possible, we aim to share code between this front-end and rustc by extracting libraries, such as Chalk (for traits), Polonius (for the borrow checker), and a new library focusing on name resolution. Eventually, we will merge this new front-end with the remaining bits of back-end from rustc.

[1] https://github.com/rust-lang/rfcs/blob/master/text/2657-road...

[1] https://github.com/rust-lang/chalk

[2] https://github.com/rust-lang/rust-roadmap-2017/issues/8

There is a documentation team, I am the lead, and I tend to write the posts on the blog. This one was significantly written by Niko as well.

Can you point me to resources so that I can write good documentation.

I don't have a good set of resources for you, sadly. Practice, practice, practice. That's sort of the best I've got right now :/

See https://github.com/rust-lang/rust-bindgen/issues/667

It's well known and long standing problem. Rust the Language allows proper enum, but Rust the Compiler cannot pack enum into single value, as in C.

Example:

  #[repr(C)]
  #[repr(i32)]
  #[derive(Debug)]
  #[allow(dead_code)]
  enum E {
    A,
    B,
    C,
    Unlabeled(i32),
  }

  fn main() {
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((0,0)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((1,1)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((2,2)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((3,3)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((3,55)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((55,55)) };
        println!("v = {:?}", v)
    }
  }

  v = A
  v = B
  v = C
  v = Unlabeled(3)
  v = Unlabeled(55)
  v = A

I can. This is a long tradition here. If someone criticizes something loved by people with little knowledge (aka fangirls and fanboys) then they downvote it.

The truth doesn't matter, the hurt feelings do. And it's downvoted without any explanation.

I had this many times, I'm thinking about not posting at all. It's not worth it. There is no discussion, just downvotes.

I'm sure this will be downvoted too :)

Also, this doesn't have anything to do with Windows support that I can see.

It went from "rebase and I'll merge" to not a single word anymore about how it might be merged.

The Windows support thing is this: rustup/curl doesn't use Windows' own certificate store. Where employers put the TLS certificate for their intercepting proxies.

curl itself has the -k option, so the user can override the check (much, much easier than preparing a certificate bundle for curl – and since the employer intercepts and decrypts the traffic anyway, there is no security issue).

rustup calls curl without that flag. The pull request was to teach rustup to call curl with -k.

(I know that it doesn't solve the whole problem, because cargo itself needs to support it, as well)

If you must use an older rustup, set `$env:RUSTUP_USE_REQWEST` (or `$env:RUSTUP_USE_HYPER` for an even older rustup) to `1`

I must say, this is a rather dramatized way to frame the discussion in the linked PR, which, indeed, hasn't been closed and is still ongoing.

For security, my normal software development environment is off the internet. I can mirror a web site, but https would be trouble.

You can fully build and develop Rust projects offline; this is a hard requirement of things like Debian and Firefox, for example.

Doing things that way helps you too. Mirrors, including caches, are easy to set up.

Installing via apt will not work for Windows users.

I am a Windows user, I know that. That's why i said "if" :)

But I still think someone "official" should have weighed in and reined in the "what about security?" people.

That was pure ignorance. The security angle has been discussed, and "I don't know much about it, so let's kill it" is a really bad precedent.

> "I don't know much about it, so let's kill it" is a really bad precedent.

I would agree, but a "completely ignore security" flag is something to be cautious about.

I feel the opposite. Where user safety is concerned, if a problem is not understood the solution should not be implemented.

In an example where it's "disable security feature X", and the developers don't know the implication, would you really want them to just say "well whatever, I don't understand the implications, but let's push forward" ?

It's not fine to use security as the big hammer that cannot be argued with, and then – nothing happens. At least not publically. Note that there wasn't even a word where it might be discussed.

I actually went looking for Rust development mailing lists, but found no discussion.

Rust doesn't quite have a team for this yet (there's a security WG slowly spinning up though) which probably explains why it's kinda stalled.

Ultimately there's no obligation here for the team to do the legwork for this PR anyway. It's blocked on something, and while that's resolvable you can't blame the team for not pushing on it.

(I did just ping someone knowledgeable in security matters about this, let's see what they say)

Here's a time [1] when someone mentioned rustup in context with TLS (it's release notes for 0.1.9). It's not that there's no forum to discuss these things.

If the discussion is missing, it's likely because it hasn't mattered enough for anyone to bring up yet. Rust is much more bazaar than cathedral. A GH issue like "my company's MITM proxy breaks rustup" doesn't mean that the Rust dev team drops what they're doing and rallys to solve this problem. Even if it comes with a PR, it doesn't mean that Rust should be forced to either accept the PR or shift resources to make the PR satisfactory.

> It's not fine to use security as the big hammer that cannot be argued with

People place an enormous amount of trust in their compiler and the tools ecosystem that surrounds it. It's extremely wise to be hesitant to permit an opt-out for a security feature.

Here's the real crux of the matter: if one wants a feature in your favorite open source project, they kinda have to be willing to hustle a bit. Nag some design owners about what is unsatisfactory about your proposed approach and what other design options might work instead. For all of the examples that you might find in other languages' ecosystems that already support this kind of a feature, you should be thankful that someone before you came across the problem and doggedly pursued a solution. But it's not a systemic problem that Rust doesn't have a solution yet: just another feature-in-development in the queue.

> and then – nothing happens

This is remarkably common among open source projects. Code contributions wither on the vine because it can sometimes be a lot more work than someone's interested in to push it upstream. IMO Rust is actually better than the average open source project in this regard (meaning fewer orphaned patches).

[1] https://internals.rust-lang.org/t/beta-testing-rustup-rs/331...

I think the issue is that no one had the expertise to clear it up. So how do you move forward?

Someone has to get called in and there's no process for that. Or the person pushing the feature needs to explain the security implications of the feature.

Maybe some sort of 'requires security triage' tag could get applied to issues like this, and the rust security wg or whoever is qualified ot make these calls could review.

Ultimately, my opinion is that if you're making a PR with security implications, and there are people saying "I'm uncomfortable and don't understand the security implications", it's on you to explain them.

Otherwise progress should not continue.

IMO those corporate environments are reaping what they sow. We shouldn't be so quick to disable TLS. Who would be to blame if those corporate environments found rustup as an attack channel for getting trojans? My guess is that rust would be a convenient scapegoat in that case.

Also, I believe that some of them may create intercept exceptions for 'legitimate' software distribution channels (like pip/npm/etc). Maybe they just need one for crates.io.

Because it's signed by a company certificate in the certificate store.

also, there are now alternative crate registering.