Promises/async/await seem very different than Ruby's (and Rails') metaprogramming to me. I'd need an example of a cryptic stack trace to know exactly what you're referring to--half the problem is because of the overuse of anonymous functions that bork the trace. There's an easy solution to that (and it makes the resulting code easier to test as well).
the fact that there is a long chapter in a book series written on the edge cases of javascript[0] leads me to believe that it's not generally well understood either.
JS uses an event-loop (which is really just a variation of a message/event queue that we've been using for GUI based applications for decades now). If you understand this, asynchronous code in JS is pretty easy to understand.
async/await is pure sugar on top of promises (it's literally just wrapping the rest of the function in a .then() for you, and coercing the return value of your function to always be a promise)
IMO that's an explicitly different issue than a comparison between Promises/async/await and Ruby's metaprogramming, though.
Not to mention that part of the issue with Promises is the various polyfills invented before broad acceptance, which is a separate can of worms, and a different type of complexity than the (relatively) heavy use of metaprogramming in Ruby (relative to JS).
Couldn't disagree more, but I think you're taking the term "magic" too literally.
There is a ton of magic in Rails. It consists primarily of magic. I've been doing Rails since <1yr of introduction (Ruby for longer than that, and Lisp for longer than either). I'm very familiar with metaprogramming. Metaprogramming fits the canonical definition of magic in this context.
Ruby, and Rails, also makes it very easy, and seductive, to add more magic. This is powerful, but dangerous. Like Lisp macros. Understanding the magic is not just a matter of "understanding the conventions" and reading the docs.
DI/IoC is a separate thing from the ecosystem; the benefits are just as strong in JS or Ruby--it's just that in JS/Ruby some of the benefits aren't as noticeable because of language malleability and openness.
> Python already exists as a dynamically-typed server language.
Ruby isn't new; it's only slightly younger than Python, and brought things to the table. Rails and Django are roughly the same age (and Django started off more as a CMS). That Python exists isn't an argument against Ruby. Lots of other languages exist, each with their own cost/benefit tradeoffs.
> [...] writing server-side web stuff in JS does make sense given it's what you're using in the client.
I don't understand the argument. Matching client/server language is a different goal than matching task/language, and the task isn't the only driving factor.
There's some crossover in that the language is the same, which means you could standardize on JS developers, but the ecosystems are not the same, and the required overall skillset is different. In wee shops the tradeoff may be worth it, but at scale, the benefit is oversold.
Etc. It's either happening, or would like to happen, all over.
Why? You can't understand what you can't measure. From city planning to business locations to traffic signals to targeted law enforcement to... If you don't know where people are you can't do anything except guess what should be done.
Of those three? Python. Why? Lots of stuff built in or well-known.
But it's almost entirely irrelevant: reasonable companies will either (a) expect you to code in the language they're hiring for or something at least used within the company, or (b) not care (within reasonable bounds, e.g., don't do your interview in Piet).
Trivial hacking is probably unlikely. Vehicles generally use CAN bus, but whether or not the camera data is available on the bus... I have my doubts, but if it's there, that'd be pretty cool. My guess would be there's a dedicated image channel off the main bus--but that's just a guess. I'd be interested in knowing if it's on the general network. It is peer-to-peer so in theory it can be deterministic, so maybe it is.
Yes, it's definitely not running over CAN as CAN doesn't provide enough bandwidth for cameras. Usually the cameras are connected using LVDS or in newer cars, ethernet.
I don't know why not; IIRC FireWire was LVDS (4+m), and LVDS doesn't specify ("care about") distance, just loss between driver and receiver. I vaguely recall lossless transmissions between 10-30m, which is more than enough for a vehicle.
> [...] women need to know what works and what doesn't.
I think men and women need to not treat people as sex objects regardless of how they dress. Saying that "women need to know 'what works'" is precisely victim-blaming, because it puts the onus on women, not men, to be responsible for men's behavior.
(Any genders above can be replaced with any other gender classification; it's irrelevant to the point.)
