I think they did it wrong by trying to maintain too much control over the drivers. Either that or people and/or their political representatives just aren't that interested in ride-sharing. But I doubt that, because as someone who is currently unable to drive, I know what a valuable lifeline these services can be. Fortunately I don't live in California.
EDIT: Also there's a problem with the way resources get allocated. I think that platforms of this type provide a valuable service, but not necessarily one that should be considered the basis for a billion dollar business. The majority of the revenue should be going to the drivers. But it's hard to get capital for something that has no chance of creating a few more billionaires.
This has been confusing for sure - most of the improvements for the language has been blogged at the Bucklescript website, since the Reason repo was only responsible for the syntax (and syntax has been mostly stable). So there is a ton of momentum hidden from visitors on the Reason site.
Hopefully that issue solved by this rebrand - a language should have a unified website for Syntax, Compiler and Standard Lib, and Blog Updates.
Flow and ReasonML are started by completely different people/teams inside the company. From what I heard, Facebook the organization does not care that much about OSS, and software devs have to work really hard to convince to spend company time to maintain an OSS software.
If there is any battle, I predict will probably be between Flow and Reason inside the Facebook org because of competing solutions.
Ocaml has way more paid development time than SML. MLton guys can't focus on everything, so they've decided final performance is more important than compile time. SML was designed with few ambiguities to the syntax (simpler for students to implement), so theoretical compile times could be very low indeed. If they had Google money behind them, compile times would definitely be better
The other thing is whole-program optimization vs method-at-a-time. A lot of SML devs use New Jersey for fast compiles when developing and MLton when deploying. You can get rid of a ton of stuff in functional languages once you do a whole program compile, but that will always take more time. MLton could really use a second, faster compiler, but I'm just appreciative of all their effort to make the current compiler output fast code.
At work our TS project with a thousand files takes 30mins on CI, incremental save takes at least 20 second. Half of the time makes the machine run out of memory.
>After just three days of self-play training, AlphaGo Zero emphatically defeated the previously published version of AlphaGo - which had itself defeated 18-time world champion Lee Sedol - by 100 games to 0. After 40 days of self training, AlphaGo Zero became even stronger, outperforming the version of AlphaGo known as “Master”, which has defeated the world's best players and world number one Ke Jie.
I wish it was worth a lot to be good at assembly these days. It seems like the huge salaries are for c++ devs. I spent like ten years getting really good at this stuff but nowadays it feels like being really good at trivial pursuit.
Edit: Did not mean to "mock" the OP, just merely trying to showing that you can apply that thought to almost anything in the programming world by replacing the technology/language names.
Except it's a bad analogy. Rails is not the next step up from systems level programming, it's a completely different (and honestly far less difficult) domain. Most of those rails devs could never be good at the hard stuff.
It is worth a lot to be good at assembly these days. It's a big piece of how my team makes a living. As one of my older colleagues puts it: there are fewer relevant jobs, but those jobs pay significantly more money, and you can only hold one job at a time.
Nah, I thought it was a good point. It's easy to forget that we either change or become obsolete. It's one thing to know it abstractly, but it's hard to make any lifestyle changes, especially if it involves switching to a job in a completely new domain.
Yes and no. My response to that article is "The more things change, the more they stay the same." There is no steam roller. The fundamentals are not changing. So much touted (even here on HN) as new and innovative are little more than re-hashed versions of what we were already using 5, 10, 20, 30 years ago, just prettier. Sure the syntax is always changing a little, and the frameworks and tools are evolving, but at a fundamental level the job of a programmer is little different now than it was in any of those eras. I have no doubt that a competent programmer from then, if picked up and plopped in front of a MacBook in 2017 could do a little reading up and perform proficiently in most programming jobs today. Probably more proficient because 1. they've seen it all before including the bugs and pitfalls and 2. I'd argue programming is much easier today than it ever has been.
EDIT: I swear I did not read the top comment in the (newly) linked HN discussion of that article before I wrote my response. I agree completely.
I really wonder about this. It seems true to me that it's easier now and anyone who could do it back when it was harder could do it now.
But then, I wonder if it just seems that way to me because I'm a product of "now", which makes me more proficient in how we do things now, which makes it seem easier. It's possible neither is easier, that they are just different, and for everyone, the other seems harder than the one they already know.
I'm not trying to argue that this is the case: I could see it being either way and I sincerely wonder which way it is.
https://retool.com/products/workflows/