A slightly modified version of standard ReScript's Js.Promise module.
Key differences are:
Promise.result and Promise.wait (which is what I want most of the time in apps)Soundness is on the same level as in the original bindings.
If you want more safety, consider reason-promise.
| // when T is any|unknown, Y is returned, otherwise N | |
| type IsAnyUnknown<T, Y, N> = unknown extends T ? Y : N; | |
| // when T is never, Y is returned, otherwise N | |
| type IsNever<T, Y = true, N = false> = [T] extends [never] ? Y : N; | |
| // when T is a tuple, Y is returned, otherwise N | |
| // valid tuples = [string], [string, boolean], | |
| // invalid tuples = [], string[], (string | number)[] |
Note: Since writing this, I've been pointed to some exciting new research/tooling called Project Cambria https://www.inkandswitch.com/cambria.html I'll likely have to rewrite this article taking that into account. Leaving this up for posterity's sake.
(This series isn't meant to be a primer/tutorial, though we might do something regarding it in the future. For official documentation and starters, see https://developers.cloudflare.com/workers/learning/using-durable-objects.
Further - these are my personal views; I expect to be wrong about a lot of them. Indeed, I'm not paying much attention to presenting these well at the moment, simply writing down thoughts. As such, expect these writeups to change often, particularly as the platform takes shape. I'm also mostly a front end guy, so don't get mad if I get it very wrong. Give me feedback! Always happy to learn and make changes.)
Durable Objects are a fascinating new storage primitive from cloudflare for their workers platform. There's a lot of 'cool'
At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.
What killed Haskell, could kill Rust, too
What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.
Is Haskell dead?
I write a lot, a lot of personal journals in a plain text. They contain a lot of dates and times, many of them should be ideally tracked automatically (like, if I've written "15:00 tomorrow" some software ought to alarm at that time), so they should be written in a consistent manner. So far I've used ISO 8601 date and time format (e.g. 2020-09-05 or 11:30) and a bunch of natural extensions (e.g. tomorrow, last Sun).
And folks, it's verbose or often ambiguous to other plain text! For example I tend to schedule things in a multiple of hours so :00 is not necessary, but a single number 15 would be less recognizable as hours. Many systems will helpfully try to recognize at 15 or 3pm, but how would you know that at 15 is not a part of at 15 km/h or similar? Also my journals are in Korean anyway, and such workarounds tend to not work well crosslingually. How about the intervals like 15:00 thru 18:30? ISO 8601 interval 15:00/18:30 would be particularly problematic because a
| package main | |
| import ( | |
| "context" | |
| "crypto/tls" | |
| "encoding/binary" | |
| "errors" | |
| "io" | |
| "log" | |
| "net/url" |
This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.
I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.
But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.
If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.
| /** | |
| * Find the point(s) where a line segment intersects an ellipse. | |
| * @param x0 The x-axis coordinate of the line's start point. | |
| * @param y0 The y-axis coordinate of the line's start point. | |
| * @param x1 The x-axis coordinate of the line's end point. | |
| * @param y1 The y-axis coordinate of the line's end point. | |
| * @param cx The x-axis (horizontal) coordinate of the ellipse's center. | |
| * @param cy The y-axis (vertical) coordinate of the ellipse's center. | |
| * @param rx The ellipse's major-axis radius. Must be non-negative. |
| import { | |
| React, | |
| } from "https://unpkg.com/es-react"; | |
| declare global { | |
| namespace JSX { | |
| interface IntrinsicElements { | |
| h1: any; | |
| div: any; | |
| h2: any; |
A couple of weeks ago I played (and finished) A Plague Tale, a game by Asobo Studio. I was really captivated by the game, not only by the beautiful graphics but also by the story and the locations in the game. I decided to investigate a bit about the game tech and I was surprised to see it was developed with a custom engine by a relatively small studio. I know there are some companies using custom engines but it's very difficult to find a detailed market study with that kind of information curated and updated. So this article.
Nowadays lots of companies choose engines like Unreal or Unity for their games (or that's what lot of people think) because d