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
Does it? I’ve seen Ezra Klein talk about his book and he talked about how bureaucracy is frequently a scapegoat for getting things done. Europe is very bureaucratic yet is able to build. The issue he called out is red tape yes but more so litigation by the private citizen. That any individual can stop an apartment being built because it blocks morning light into their flower bed
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.
I guess I was thinking specifically of the swift case where values have exclusive access enforcement. Normally caught by a compiler, they will safely crash if the compiler didn’t catch it. I think the only way to segfault would be by using Unsafe*Pointer types, which are explicitly marked unsafe
And loading times. I think people already forgot how long you had to wait on loading screens or how many faked loading (moving through a brush while the next area loads) there was on PS4
It’s not a prerequisite though. Nor is Hamlet or any of the other works referenced. Very little will be missed if you haven’t read the Odyssey. It’s a book that stands alone on its own. Like anything else, Ulysses is inspired by other works, but you don’t need to catch every single reference or allusion to enjoy a book or movie
I’m confused, that is how it works. If a developer increases their target version to say iOS 18, a user running iOS 16 would be able to download the last app version that supported it, even after factory resets. If the third party developer dropped support for APIs or whatever to break that version, it’d be broken regardless to whether or not you had the app downloaded already.
Where copying is expensive (most Swift collections are backed by classes for COW semantics). Where location stability is necessary (where you need a mutex). Resource allocation. Those are the primary examples that noncopyable types are meant to address.