My favorite is the Chad Wittgenstein usage. — Where you add an em-dash after periods to slow down the reader. —— Sometimes a double em-dash to keep your reader on their toes.
This doesn’t really make sense. Apps were pretty popular immediately after decades of web usage. There are many reasons to prefer an app. Even on desktop; if I’m using a service enough throughout the day, I want a native app, not a website.
She’s been in her position for less than 6 months. All of the problems were under Phil, so I don’t understand what you mean by course correcting her own actions
I can’t think of a worse announcement for your road to 1.0. Who cares? Without localization or accessibility support, it doesn’t make sense to call your UI framework production ready with a 1.0 version. I think limiting what third-party contributors can bridge from browser APIs killed Elm’s momentum for anything but toy projects. It now seems more like a sandbox for Evan to play around with compiler ideas than something meant for production use.
Is it really different from that short time ago? It feels like this has been the normal for much longer than 5 years. I do remember there being fewer restarts to update, but I feel like that was way back in the snow leopard days.
As to why, I assumed it’s because security fixes are in basically every update these days. And it’s easier to change core systems with a restart than live
Maybe there’s a git trick I don’t know, but I’ve found making small branches off each other painful. I run into trouble when I update an earlier branch and all the dependent branches get out of sync with it. When those earlier branches get rebased into master it becomes a pain to update my in-progress branches as well
As someone who used phabricator and mercurial, using GitHub and git again feels like going back to the stone ages. Hopefully this and jujutsu can recreate stacked-diff flow of phabricator.
It’s not just nice for monorepos. It makes both reviewing and working on long-running feature projects so much nicer. It encourages smaller PRs or diffs so that reviews are quick and easy to do in between builds (whereas long pull requests take a big chunk of time).
Right but recursion is only a smaller part of why the optimization is important. It means tail-called functions still build on the stack and long function chains—as is common with fp—can overflow
I am also surprised, but not because I believe Meta to care about the ethics of the whole thing. After all their privacy scandals, I’d assume they’d have policies in place to prevent something that can so easily be leaked. But here we are
The subject of the function coloring article was callback APIs in Node, so an argument you need to pass to your IO functions is very much in the spirit of colored functions and has the same limitations.
I think this article does an alright job selling ro over RxGo, but doesn’t really explain why using a reactive library is better than plain go. The channel/goroutine example is fine, as they say, but they hand wave how this will fall apart in a more complex project. Conversely, their reactive example is mapping and filtering an 4 item array and handwave how the simplicity will remain no matter the size of the codebase.
I’ve worked in a few complex projects that adopted reactive styles and I don’t think they made things simpler. It was just as easy to couple components with reactive programming as it was without.
I joined the sapling/subversion company this year, but haven’t had the chance to use jj. But given its resemblance I must say sapling has been great. Much more intuitive than git, and I find commit stacks much easier to follow than branches. I do wonder how it will work without the level of support of Meta, since you won’t have the same commit stack review UI (basically a series of pull requests being reviewed at the same time). So something like what this author is working on is needed.
What he calls import highlighting is something I only find reliably setup in Xcode, but is probably one of the most useful things to highlight for me. To be able to tell at a glance whether I’m looking at a library function or an internal was very useful. Probably doesn’t matter for languages that enforce calling with the module (eg, module::foo()), but in C/Objective-C and Swift it’s annoying when it’s missing.