querulous

the number of doctors on j1 extensions the us is going to lose over this is going to seriously impact us healthcare. it's also not uncommon for doctors to practice on an o1 and they'll be impacted also

the passthrough quality is a real letdown given the marketing. it's like looking at everything through a grimy, unwashed window

i never expected it to be good as a productivity device because my own experience is while screen real estate is nice what really matters is the ergonomics of your work space and wearing a pair of ski goggles is never going to be ergonomic

it's also because they wanted to run it at night with all the casinos (and the sphere) on the route lit up. the miami gp started at 1230pm and the montreal gp at 11am (930am and 8am vegas time, respectively) but the las vegas gp route doesn't look half as good in daylight

the big risk with elixir imo is that it's runtime/vm is still owned by ericsson and there's no alternative. i know things like firefly exist but they aren't mature replacements (to my knowledge)

sometimes it's not your data

that presupposes that france wants to ban the phone. charitably they just want an accurate measurement so they can apply their regulations. the lab has no incentive to find either way

this is 100% it. there's a ratcheting effect in owning housing in canada. that recent study about how 70% of homes in canada are being bought be investors is completely bogus. 70% of homes in canada are being bought by people who already own homes. often this is "investment" properties like rental units but a significant proportion of it is second ("vacation") properties and parents using their own equity to fund children's home purchases

it also advertises news, music and apple tv (and probably all their services, those are just the ones i've noticed)

it's not as mysterious as it sounds. every data structure (including modules and anonymous functions) has a binary serialization and every erlang vm is also an rpc server that can receive arbitrary data -- including whole programs -- and execute them. your vm of course needs to know about the remote vms to do so but that's where the rudimentary clustering mechanism in erlang comes into play

fwiw this is from 2018 and i would say the conclusion from those who were around pinterest at this time and shortly after would not be nearly as positive

how does the type system handle `receive` in erlang/elixir? does it just require every `receive` clause have a catchall case (meaning every `receive` is any -> T) or does it only guarantee type checking in the absence of external messages?

the smartphone killer app was that it fit in your pocket and was useable almost everywhere you were

the current generation of vr headsets aren't useable for extended periods. too heavy, too hot and too clunky

losing peripheral vision is a bigger annoyance than i expected also

many table games and all sports betting i know of take a commission (the rake). they are definitely not zero sum

orders of magnitude more expensive than kafka tho. not feasible at scale

i don't think it's as nefarious as that

the issue is that startup founders might have a lot of implied wealth based on the equity they hold and money raised but a "mainstream" bank is going to look at that equity, assess it as non-liquid and highly speculative and reject any loan applications

svb was more likely to extend personal loans to startup founders because -- in theory at least -- they better understood startup finance and they were incentivized to provide good service to prospective customers of their more business focused activities

you know what is more stressful than having too much work? not understanding the work you do have

it works fine and there's someone happy to do it for free. why would anyone try to compete with it?

the nuance you are missing is that individual contributors are responsible for their own work and judged based on that. they are not responsible for the work of others. managers are of course responsible for the work of those they supervise

their entire ad backend is in a state of crisis. i have friends who were on the monetization (read: ads) teams at twitter and every single one of them has been asked/ordered to return to work if they want to collect their severance

their entire ad platform is basically unuseable at present

he had very capable partners/lieutenants at spacex and tesla (shotwell and straubel, respectively). elon's undeniably great at cheerleading and fundraising but it's unclear how much credit he deserves for the technical accomplishments of spacex and tesla. at paypal he was run out almost immediately upon becoming ceo and at twitter he's surrounded himself with non entities like jason calcanis and alex spiro

you need a ton of people to run an ad platform modern advertisers will actually use. and a ton of ad sales people to convince them to use it. twitter the product is pretty simple. twitter the business is not

they don't. you ask the team to come to a consensus on their own and if they don't just pick someone to make the decision and then pick someone else the next time you have to pick

managers thinking they know better than their reports is the source of basically all team dysfunction in tech

yeah but if you fire 5500 there's little hope that the 2k you keep are the right 2k. nor are they likely to stick around to see things through

the mechanism isn't important. what apple restricts is access to any kind of cross app identifier like the idfa unless the user explicitly opts in. sketchier platforms use device fingerprinting but apple also forbids that under it's terms

the only way to do cross app tracking in ios without the user opting in and without violating apple policy is via explicitly associating accounts across apps either via oauth or some kind of account linking

this is exactly how air travel works though. if your incoming flight is delayed you get delayed regardless of what the schedule says. setting a deadline does nothing to address the lack of a plane. the plane arrives when the plane arrives

i don't disagree with you that writing concurrent and parallel programs in erlang/elixir is nicer than in nodejs or go or java. erlang picked a nice set of primitives and elixir extended that with some very good apis. i don't even disagree that language idioms influence software architecture and that elixir and erlang are particularly strong here -- particularly considering otp. however, i just don't think elixir/erlang's concurrency/parallelism story is as important now as it was when erlang was first getting attention for it

at that time the concurrency story in most languages was terrible. non blocking i/o was rare. truly parallel programming was esoteric. that's not the case today though. i am not a huge fan of go but it's undeniable that it has a strong concurrency story AND a strong parallelism story. java has nio and better libraries for concurrent and parallel than it did 10 years ago. even nodejs (which was always the equal of erlang when it came to non blocking i/o) has a very straightforward and fairly efficient worker api for doing parallel computation. languages like rust and swift and julia were born with compelling concurrency and parallelism features

elixir still beats out ruby and python (although python is getting close) but people using ruby and python today largely don't care about these things. they know the limitations and they accept them. if they didn't they have a wealth of languages to pick from

elixir/erlang no longer occupy a unique niche. the other languages have caught up and offer "good enough" libraries and apis. they also bring much to the table that erlang/elixir don't. elixir may lead in concurrent programming but users choose languages that lead in community, ecosystem, compatibility, commercial appeal, etc. for elixir to compete with go, node, java, python it needs (or needed) to offer more

(i say all this as someone who really wishes erlang had 'won'. it's by far my favorite language when you consider solely the syntax and semantics of the code itself. pattern matching should be ubiquitous in modern languages. data should be immutable, full stop. i'd rather write a foldl than a for loop. it didn't win though and the erlang vm is roughly identical today to the erlang vm i was using in 2012 (this isn't to say it hasn't seen improvement but the improvement has been incremental and modest). the ecosystem moves at a glacial pace compared to that of node or go or even a relatively unpopular language like rust or julia)

elixir's strength is really the dev experience, agreed. i think if the community had leaned harder into that aspect and less on the 'whole new paradigm' aspect of the language it would have been more successful. people want to do the same thing they are doing now but in a more pleasant way. very few people want a revolution

elixir is (was?) very parochial. for a long time it didn't fit neatly in the same shaped box as comparable applications written in ruby or python or java or whatever. part of this was technical (it's a compiled language without any of the effort c or java got in packaging and distribution so operations were complicated when compared to mainstream languages) and part of this was cultural (the infamous 'you don't need x if you use elixir' testimonials) but it combined to scare people who weren't interested in being elixir enthusiasts away. there was definitely a sort of stepford wives vibe around the community where people who just wanted to know how to use elixir to read some data from kafka or redis or deploy an http api or whatever were met with scolding and admonishment for not embracing elixir and eschewing everything they knew. things are definitely better now but i think the damage was done. elixir has a reputation now for being an outsider language

i also think elixir was hurt early by overselling of erlang and the erlang vm. a lot of the "groundbreaking" technology in the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now (albeit via libraries or extensions sometimes and not natively). elixir's implementation is quite crude in comparison to some of it's competitors. the same goes for the "seamless distribution" that erlang/elixir proponents talk up. it's just a fully peered tcp mesh and a very simple binary encoding with a tiny rpc framework on top. it's something you could replicate in any language in a weekend (but you probably wouldn't bother. it's not very useful in a modern context). the promise very rarely delivered and people went back to more familiar languages

i think elixir had a brief window to get popular when go was still in it's infancy and nodejs was all written callback style pre async/await and java.util.concurrent was considered arcane knowledge but it failed to get a big enough community that could sustain it once go and nodejs and java got almost as good at concurrency as it was and didn't expect you to forget half of everything you knew about building and operating software. without a clear technical advantage people preferred the familiar