6,769 karma · joined February 21, 2011
To answer your particular hypothetical question: I can't say for certain, but I sure hope that yes, it would bother me to disinvite that person in that situation. But I don't see how your post relates to the topic at hand.
There's a GDC talk out there about the complexities of audio in Overwatch, a competitive game. Not only do you have invaluable audio cues coming from 12 players at the same time, but also all of their combined abilities and general sound effects, like countdown timers and such.
One of the bigger problems talked about was that in a competitive game you can't just scale the loudness of an opponent's footsteps by the direct distance between them and you. You need to take into account level geometry, and so the game has to raycast in order to determine how loud any single sound effect should sound to every active player in the game.
Edit (link): https://www.youtube.com/watch?v=zF_jcrTCMsA
> Of course, when <...>, you would never consider <...>
Presented without comment.
If, on the other hand, I myself were disinvited in such a manner, my first thought would be to reassess my recent behavior rather than suing the house owner.
Redex's library selection is anemic compared to Crates.io, and so is Pursuit's. There are a couple of gems in both, but for any given use case it's just as likely you will have to write your own code than find a workable solution in the package manager.
More importantly, Rust has orders of magnitude higher bus factor than Purescript and ReasonML combined. Phil Freeman has long since left his project, and so will eventually Hongbo Zhang, at which point Reason will follow PS's slow downward spiral into open source limbo.
Believe it or not, I actually put a bit of thought into this. And I do firmly believe that Rust is by far the best ML-like language for the web available to the public right now. Perhaps I should finally write that blog post I keep putting off.
Rust is the first mainstream language that looks at this code and says "Hold on, are you the only one modifying `a.name`?" And the intimidating part is not the question. The question is not for you. The intimidating part is that the Rust compiler asks itself the question, and it always knows the correct answer.
What the Rust compiler is looking at is the same thing the senior programmers are looking at during code reviews at your company. The people who know who should own which data. In C, once you `malloc` a struct someone has to know to `free` it. That's the rule. You acquire a resource? You're in charge of releasing it. Or at least passing the responsibility of freeing it over to someone else.
Rustc is the ultimate code reviewer. Yes, it's super pedantic, but also, hey, it can take any amount of insults you can throw at it and still thrive. If you run out of things to call it and the code still doesn't compile, guess what, the problem is probably on your side.
I repeat, Rustc is the perfect code reviewer you could ask for. And it's available 24/7. Compilation speeds are not very fast? Ok. Compare them to code review times from your peers when using a lesser language. 10 seconds for an incremental compile doesn't seem so bad when the alternative is to get instant feedback and a comment 16 hours later that you missed an edge case.
Sorry for the big post. Thanks if you read the whole thing; kudos if you scrolled straight down. Be kind, work hard, and good things will happen.
There is no axis on which JavaScript (with or without Typescript) is a higher-level language than Rust in 2020. Rust offers a richer standard library, much MUCH more powerful facilities for modeling data, state-of-the-art (de)serialization that's one crate import and a one-liner annotation away.
I don't know who came up with asm.js, but that person definitely knew. JavaScript's destiny is to be a building block. Yes, it feels nice to write plain JS without importing any libraries. It's nice knowing the difference between `Array#slice` and `Array#splice` without looking it up on MDN. But it felt just as nice for ASM coders in the 80s to bypass a C compiler, and look where we are now.
In what world is Rust a lower level language compared to JavaScript at this point?
It's a pretty neat use of the feature, although I'd still gladly let go of it if it means that the other 20 apps I regularly use don't get to rummage through my clipboard for no good reason.
1) Sign up for Fastmail.
2) Sync all mail from GMail account to Fastmail (via the Fastmail web UI; you grant FM access to your GMail data through OAuth - once sync is complete you can revoke this access).
3) Set up an auto-forward rule in GMail for all incoming mail to go to your Fastmail address.
4) Set up a rule in Fastmail to put all incoming mail sent to your GMail address into a separate folder (or labeled with a special label if you're signed up for Fastmail's label beta). Any time you get email in that folder, that's a task for you to either unsubscribe or update the corresponding account to your new email address.
I'm currently in month #10 of migration. Most commonly used accounts were updated during the first couple of weeks. But be careful that the tail of services that are still configured to use your old email address tends to be long, and in my experience those are some of the more important emails that you don't want to miss. The ones that are only sent once every couple years.
Also, it really helps if you've been using GMail with a personal domain name (e.g. through Google Apps). In this case migrating is a matter of pointing the MX DNS records to Fastmail's servers. Bonus points: Fastmail allows wildcard recipients, so if you prefer to have unique addresses for each service you sign up for, you don't even need to set up a separate xyz@example.com alias. Just register with <whatever>@example.com and you'll get all email delivered to that address in your inbox, and you'll be able to specify it as the sender's address if you decide to reply to some of those mails. Having a separate email address for each web service also makes looking up who leaked what on haveibeenpwned.com more fun.
Yes, OCaml is older! Yes, OCaml circa 2015 is a useful language! But also, yes, OCaml has gained multiple useful features since 2015! In part because its development is driver by many, many people. And no, BuckleScript doesn't have some of those features as of May 2020! And it's not an indictment of Reason, but it is also a true statement that Reason/BS are lagging behind compared to what OCaml has to offer!
2015 OCaml was an excellent language. 2020 OCaml is exquisite.
But surely you'll agree that "fast development, fast running, fully type safe programming" has been achieved years ago, and any incremental improvements coming from the BS project are just that - incremental.
Like I said, I know the tradeoffs between JSOO and Reason. And lack of features from the past 2~3 years of OCaml development is one of them.
And Re: 2) I have no doubt that Mr. Zhang knows what he's doing. I was just noting how even after the prodigious amount of work he has put into BS over the years, it is still falling behind JSOO which has the benefit of being more tightly bound to the parent OCaml project. I know about the different tradeoffs JSOO and BS have made. All I meant to say is that one super-productive person is apparently (and understandably) not able to keep up with upstream (i.e. Inria + Jane Street + many others) in this case. And then we have the ReasonML project that has seen even less activity recently. If ReasonML in its current state is considered a finished product that requires minimal maintenance, I couldn't think of a better endorsement, to be honest.
1) You called the 0.8 release "huge" in the release notes, even though it adds 11 new functions, removes 2, and updates 2 compared to 0.7, released a year prior. Is there something else about 0.8 that makes it larger than the sum of the API changes?
2) BuckleScript has seemingly been a one-man show for ~3 years. It is lagging noticeably behind the progress of the main OCaml project (including jsoo). ReasonML has a couple prominent contributors, but the overall (public) activity is dwarfed by Hongbo Zhang's work on BS. Is this because the ReasonML project is considered to be in a stable state, sufficient for production work?
Excuse me, hope? Evacuation was not necessary because there was hope that things weren't as bad as they have turned out to be?
And honestly, as someone who has heard a billion Russian jokes about "volunteers" in the USSR, every time you use that word is jarring to me. I'd share the anecdotes with you, but I suspect you already know most of them.
That would be strange, because the series didn't show them die. And one of the epilogue screens said: "It has been widely reported that the three divers who drained the bubbler tanks died as a result of their heroic actions. In fact, all three survived after hospitalization. Two are still alive today."
But while I'm here... Minecraft is a quintessential roguelike game. You arrive, naked and alone, on a hostile world. You then build yourself up by the skin of whatever. You mine and farm and build, and you acquire food and clothes for yourself. The only rule Minecraft broke is the one that says you can't code a financially viable game in Java.
(I guess there's no ascension, but at that point you've built heaven on earth anyway, so there's no reason to leave.)
> As to why we need those rules in the first place? Because we want to make good games.
I'm sorry, but super no. No game designer has ever feared that they would end up with a good toy, or a great activity, rather than making bank on Steam.
> All categorizations are wrong. No maps are completely accurate.
That's right! "All models are wrong, but some are useful." I was merely wondering what the use of the model presented by GP was.
Please explain the usefulness of a taxonomy that has "game", "activity", "event", and "toy" as discrete entities.
Are Stripe co-founders paid by the word, or did that message get through about two dozen lawyers before being posted?