We use it in our robotics startup, and I wholeheartedly agree.
As an example, we just rolled out a feature in our cloud offering that allows a user to remotely call a robot to a specified waypoint inside a facility, and show real time updates of the robot's position on its map of the world as it navigates there. We did this with just MQTT, LiveView, Phoenix PubSub, and a very small amount of JS for map controls. The cloud portion of this feature was basically built in 2-3 weeks by one person (minus some pre-existing code for handle displaying raw map PNGs from S3, existing MQTT ingress handling, etc.).
Of course you _can_ do things like this with other languages. However, the core language features are just so good that, for our use cases, it blows the other choices out of the water.
Which version of emqtt are you referring to? We are successfully using 1.11.0 (with AWS IoT Core), which I believe is the "blessed" version for elixir.
I do not remember all the details, but I think it was during the transition from MQTT 3.1 to 5.0. We only use 3.1 and the 5.0 code was not yet finished, emqtt had a hard coded a dependency with an old lib, which we wanted to upgrade. There were no hex package, it was pulled from github. And then the repo on github disappeared (or maybe moved?)
I will have a look at this new package, it looks promising
Ah, yes - we are pulling from the tag on GH. However, I believe the hard dependency on the older version of gun was fixed recently. IIRC, that was what prevented a proper package at the latest version from being on hex.
I was able to update to the latest tag of emqtt on GH (1.14.4), which was not previously possible. I don't believe there are any blockers now to a package on hex.pm, so hopefully this is made available soon.
Aside from the flow technique mentioned below, I think it is pretty common.
If I'm acting as the non-flying pilot, my job is to talk to ATC, set radios, load flight plans and instrument approaches, etc. As an example (slight variation), if ATC gives us a flight level change, I would dial in the final altitude on the altitude pre-select. Typically, I'd repeat the clearance back to ATC, put my hand on the dial, change it and leave my hand on it until the flying pilot says "I see FL230".
I sometimes use the point technique before changing something, or after while repeating "I see ..." or "I did ...". It's really effective at making sure you don't do things mindlessly.
The safety value proposition of the max is kind of hard to sell after two planes crashed. It was already the most successful plane ever in terms of avoiding retraining right?
All that unlocked safety value didn't count for much.
Accelerate-go is definitely used in twin pistons and turboprops. For example, in the DA-42, V1 is specified as 75 kts. In the King Air 350, V1 is typically around 100 kts.
I do stand corrected on the King Air 350 (and it's likely that the P180, Dash-8, ATR-42 will also be similar and come with balanced field restrictions). Thank you for that correction.
Accelerate-go calculations do not necessarily mean that engine failures before rotation are to be taken aloft. My 58P has accelerate-go charts published (they're not pretty at heavy weights on high/hot days). Nevertheless, any engine failure with the nosewheel on the ground is an abort/RTO.
The DA-42 I can't find any reference for V1 below Vr and to take an engine failure prior to Vr aloft. That was looking in the QRH and checklists for the aircraft. I see both specified at 75 knots and the checklist response for engine failure on the roll is only the rejected takeoff instructions.
Parking downtown is bad, but I'd be curious what cities you are comparing it to with respect to traffic. I grew up in Chicago and lived in the Bay Area for a few years, and those are both far worse. A lot of the newer tech jobs are fairly close to downtown, the strip or the east end (both my wife and I are able to walk to work almost every day).
I understand your position, but I think these companies do exist here. I know, because I've been at a few of them (Avere Systems and Bossa Nova Robotics, for example). I think our biggest challenge is getting sufficient capital in the region. The airport situation has been a serious impediment - great airport, few direct flights to the west coast - but that is changing.
As an example, we just rolled out a feature in our cloud offering that allows a user to remotely call a robot to a specified waypoint inside a facility, and show real time updates of the robot's position on its map of the world as it navigates there. We did this with just MQTT, LiveView, Phoenix PubSub, and a very small amount of JS for map controls. The cloud portion of this feature was basically built in 2-3 weeks by one person (minus some pre-existing code for handle displaying raw map PNGs from S3, existing MQTT ingress handling, etc.).
Of course you _can_ do things like this with other languages. However, the core language features are just so good that, for our use cases, it blows the other choices out of the water.