iPhone 13 mini (and ex-SE) user here, this phone looks great!
I like the minimal and solid looking design. I think the real keyboard is an interesting and welcoming compromise for its width. If the built quality is on point, I'd see no issue with the price.
Full Android also means there's no restriction in the apps I'd need. GrapheneOS on it would be great.
I appreciate the minimal color options - I have this thing where all my technical devices running software should be in all black, and any colorful details would just bother me a bit (looking at "playful" design choices like the lime green switch on the Fairphone 6).
Quick nitpick at their marketing team: "compact by design, made for one hand." can't possibly be true with a real keyboard on a phone.
The other iPhone mini user here, and agree that this phone looks nice. It looks like the keycaps form a capacitive touchscreen or something, so you can actually swipe to type over the keycaps. Marketing videos show using it to scroll the screen. But, seems like it could work for one-handed use.
I might pick one of these up in the de-Googled variant and keep my iPhone around for all the "attestation required to view your bank balance" apps that I have.
I think you should always include the iPhone SE in those numbers. It had similar dimensions, was cheaper and even more minimal. If it weren't for the SE, I would have picked a Mini right away.
> But then would it make sense to make every function async?
No, that doesn't make sense at all! You're being too reductionist...
I/O has its place in every real world program, and the true limitation (or what you call a "problem") are the single-threaded runtimes of JavaScript. It's not a question of whether you should mark your functions async or not, as if it's an issue of consistency in the call-tree of your program. The true question should rather be whether your functions are I/O-bound (and would actually block the single-threaded event loop) or are solely compute-bound.
You're forgetting the fact that async/await in JavaScript was a historical design choice to prevent the callback-hell that came with single-threaded concurrency. So if you'd want to get back to that callback-hell (and convert async functions back to "some-form-of" sync), you still can[0]:
// some dummy async function that doesn't really do any I/O
async function add(
a: number,
b: number,
): Promise<number> {
return a + b;
}
// convert async function back to sync to enjoy callback-hell again
function addUnpromisified(
a: number,
b: number,
cb: ((result: number | null, reason: any) => any),
): void {
add(a, b)
.then((result) => { cb(result, null); })
.catch((reason) => { cb(null, reason); });
}
You can think of async/await as an evolution of generators[1], as every await yields control back to the event loop. I'd actually encourage you to write some of your programs' behavior with generators if you've never done that before. Generator functions will yield control back to the caller, which is an interesting way to design programs when the caller is you instead of the event loop.
It's in Python, but David Beazley still has one of the best explanations on that topic, and shows the how and why you'd want to design an event loop live on stage[2].
personally i disagree, at least in a pragmatic approach to js's design. also your example doesn't make much of a valid point i feel: the promises are still async on the microtask queue. you seem to be showing syntax, not semantics.
> the promises are still async on the microtask queue. you seem to be showing syntax, not semantics
Well, GP doesn't want to get rid of concurrency, do they? They are talking about syntactic preferences when they want to "make every function async". I just showed them a way to make every function "some-form-of" sync, so they'll know how to change every function according to their preferences, either async or sync.
Multiple things can be true at the same time... do you think the seller doesn't want a closely surveilled world with no exits?
Besides, money keeps businesses in the economy afloat, it's an artificial good with (more or less) constant value. Money's a systematic means to an end and rarely an end goal, its purpose is the transportation of value, and not the communication of value.
It's hard to see how you wouldn't at least be okay with that outcome if you were actively making it happen. But maybe this is just explaining why I'll never have that much money.
I love this analogy. It’s hardly a crime to kick my lawnmower until it starts to come apart. Vandalism at best. If you want to entirely dehumanize these people, at least go all the way.
That was a reference to a Bryan Cantril speech, and it's more about the lawnmower's ability to gravely harm your person without having any intent or feeling beyond doing what a lawnmower does.
I feel like your definition of Art is too simplistic and incomplete. At least since Joseph Beuys we know that "anything can be Art", and it's just a matter of how an "expression of an idea" is used to lift something up to the status of being Art. Crafts, as practices, are not excluded from that potential.
While some artists turn the labor-intensive aspects of crafting into a part of their expression (including any angles on tradition and social-economic factors), like Ai Weiweis[0] installation Sunflower Seeds[1] in the Tate Modern in London, others might focus on the community aspect of crafting as part of their media, like how Thomas Hirschhorns[2] installation Musée précaire Albinet[3][4][5] close to Paris takes crafting as a means to "be present and produce something together on location", as "agreement", as part of a community in a public space, and as inclusion of anybody beyond differences in the understanding of Art. AFAICR he could even get the Mona Lisa from the Louvre for a few days to exhibit it there.
Besides, I think it's safe to say that any work in the field of Performing Arts is based on an analysis of their craft.
It's a matter of running a for-loop. You'd get faster response times (no query→index translation), but the storage requirements for the indexes would be larger.
"We never use AI. For anything." becomes a much weaker statement when you exclude dependencies. Your whole app could just be a thin wrapper around some third party dependency which leans heavily on AI.
It makes the manifested statements become more realistic, sure, as I doubt any dogmatic approach could even exist for long. But I don't think this warrants anybody to bring out the pitchforks and scream "HYPOCRISY!", though...
This whole thing is a matter of choice, and we shouldn't necessarily conflate the role we take when we consume/use a dependency/tool with the role of crafting own things. I, for one, can apply agency solely on things that offer me means to change them.
A lot of desires that require computation might not be so "logical" in nature, at least not in the automation kind of things.
I use a lot of computing for entertainment purposes and leisure activities, like reading news/ebooks, watching shows/movies, listening to music, gaming, clothing/furniture shopping, going into all kinds of rabbit holes etc. The HN link from GP was such an example.
How could any automation through other physical input help there? Sure, there is vector similarity and recommendation engines, but how could any sensor interpret my aesthetics and my desires to belong/grasp/play/participate?
That sounds exactly like the empty sci-fi promises that current AI companies are betting on.
"I use a lot of computing for entertainment purposes and leisure activities"
Couldn't agree more. And phones with a touchscreen have been optimised on this axis (ppi, stereo speakers, fps, oled, latency, etc.)
Examples of logic that you want to last for years: devices you set up for your parents to notify you when they get up in the morning. Or that their air quality and temperature is ok.
By logic, I mean source code that determines the behaviour of the device.
I like the minimal and solid looking design. I think the real keyboard is an interesting and welcoming compromise for its width. If the built quality is on point, I'd see no issue with the price.
Full Android also means there's no restriction in the apps I'd need. GrapheneOS on it would be great.
I appreciate the minimal color options - I have this thing where all my technical devices running software should be in all black, and any colorful details would just bother me a bit (looking at "playful" design choices like the lime green switch on the Fairphone 6).
Quick nitpick at their marketing team: "compact by design, made for one hand." can't possibly be true with a real keyboard on a phone.
reply