To chime in on the pity party; ordered a Ford Mustang Mach E at the start of April 2021. Original estimate was 3 months to delivery. Currently the delivery estimate is 10 months, but no one seems to be able to tell if that's real or not.
At current pace, ford will produce around 64k ME annually when they reach a year of full production. That is about 1/5th of Tesla's 2020 US production.
Meanwhile Tesla's Texas model Y factory is about to open and add another 500k to their annual capacity.
If demand is similar for both cars, I think you will be driving a Tesla sooner.
Mach E manufacturing is a joke. They recall all cars produced until summer because roof fell off. Right now they stop sales because of seat-bells. They have door opening issues all the time(check youtube).
Ford's overall EV production in their only Mexico plant in 2021 will be ~40k. While Tesla added Giga Berlin in Giga Texas in January, that pushes their production capacity to 2 millions/year. 2022 probably will be 1.4-1.5m tough.
Buying EV from Ford nowadays is like buying a car from a small startup. Even Rivian and Lucid will beat them in 1-2 years lol
The problem with form they don't make money on these EV's for them it's an experiment you're paying for. They makes production artificially low since they don't know what to do with EV's. Electric F150 planned volume is also a joke.
Span | Firmware, Backend, Mobile, Mechanical, Electrical, More! | SF Bay Area HQ | Full Time (visa welcome), Interns | https://www.span.io/careers
Span is reinventing the electrical grid to move us towards a distributed future. That means powerful edge compute and real time controllers integrated into buildings that can intelligently manage the flow of energy between connected systems. We don’t have time to ineffectually fumble at half-measures over the next decade, so instead Span is fast-forwarding to the grid of 2050. Distributed energy is a critical tool in solving the climate crisis and Span is a key part of the grid-wide overhaul that necessarily comes with it.
We are currently shipping the second iteration of our original product, the Span electrical panel in volume and generating revenue (in addition to multiple funding rounds). There is a significant amount of work left to realize the full potential of that product, and we are working on new and exciting things which have not yet been revealed.
If you're interested in working on an important problem with kind, smart people Span is the place to be! We are hiring across all engineering disciplines (and many other domains as well!) to work on current and future products. Check out the jobs page at the top for the full suite of openings. Happy to answer more detailed questions with specific information about certain roles here as well.
Keyword bingo: Rust, firmware, c, embedded Linux (Yocto), real time operating system (FreeRTOS), hardware, electronics
It's not exactly the same thing, but there's an app that does AR overlays of PCBAs [1] to help with debug. I haven't used it, but it's a pretty neat idea.
Linux required an MMU at inception[1] and currently requires an MMU. Instead you have μClinux[2] which although it is integrated with the mainline kernel since 2.x, it lacks some important features, like it has neither fork() nor autogrow stacks[3].
I finally bit the bullet and replaced the battery in mine. It wasn't my favorite process, but it seems to have turned out fine. Used a hand rolled bead of Sugru [1] to re-seal it. Not sure I'll ever be able to try again, but at least now it works again.
Not sure what they were referring to, but there are airlines like JSX [1] which are sort of a "semi-private" experience. My experience is limited, but flying JSX was a breath of fresh air. Security was a questionnaire and a short bag search (no scanner, no TSA, no XRay) and took about 30 seconds. Staff hand-wrote my seat/flight info on a paper ticket. Went from arrival to seated in plane in ~15 minutes more than once. Plus unlimited drinks onboard.
You sometimes have two Options that must both be Some to have any effect, but other reasons prevent you from making an Option of a tuple of those two fields. Eg think of deserializing a JSON that contains optional username and password strings, but you need both if you are to use them to authenticate to some remote.
In that case, you currently have to write code like:
if let (Some(username), Some(password)) = (username, password) {
/* both are set */
}
else {
/* at least one is not set */
}
With zip this can be written as `if let Some((username, password)) = username.zip(password) {` In this case it doesn't look like a big difference, but it does allow you to chain other Option combinators more easily if you were doing that instead of writing if-let / match. Using combinators is the "railroad-style programming" that kevinastone was talking about. For example, you can more easily write:
let (username, password) = username.zip(password).ok_or("one or more required parameters is missing")?;
You could of course still do this without .zip(), but it would be clunkier:
let (username, password) = username.and_then(|username| password.map(|password| (username, password))).ok_or("one or more required parameters is missing")?;
The zip form does lose the information of which of the two original Options was None, so if you do need that information (say the error message needs to specify which parameter is missing) you'd still use the non-zip form with a match.
The zip solution however requires any reviewer to look up on what it actually does, whereas the "if let" is more of a language fundamental and known to most reviewers.
Therefore I would actually prefer the long/verbose form without the zip.
It's just the opposite. zip is a normal function written in normal code, so if the reviewer doesn't know what it does then they can just click through to the definition in their IDE. Whereas "if let" is some kind of special language construct that a reviewer has to look up through some special alternative channel if they don't understand it.
If I'm doing a code review I don't have an idea. I only see text (yeah - limitation of the tooling, but reality). I can search for the functions, but it's a hassle and I want to limit having to do it to as much as possible. It's even not super easy in Rust, since some functions are defined on (extension) traits and you don't exactly know where to search for them if you don't have the IDE support and are not already an expert.
"if let" is certainly a special construct - but it's also one that Rust authors and reviewers will typically encounter rather fast since a lot of error handling and Option unwrapping uses it. Knowing the majority of library functions will imho take longer.
Understanding - or looking up - library functions is something you're always going to have to do during code review (it's well worth getting IDE integration set up). zip is a very standard and well-known function (I used it yesterday, in a non-Rust codebase); it may well end up being better-known than "if let". Learning what a library function does is certainly never harder than learning what a keyword does and it's often easier (apart from anything else, you know that a library function follows the normal rules for functions, so if you can see how its output is used then you can often tell what it does. Whereas you can't rely on that kind of reasoning with language keywords).
