dmit

(: XQuery comments are marked by mirrored smilie faces, like this. :)

Tired of all the "404 Not Found: /favicon.ico" log messages from your local test server? Fret no more! Just add this minor incantation to your HTML and you're set!

  <link rel="icon" href="data:," />

If "he gives consent", then she isn't a perpetrator. By definition.

If one of the parties gets drunk, they can't give consent. Again, by definition.

Exactly. That's why they're called 'victim' and 'perpetrator'.

If the victim got triple blackout drunk, the only person they'd hurt is themselves. But the rapist, in addition to physical damage, inflicts deep, lasting psychological damage upon their victims. It's not just "regret".

No, it's lack of judgement. Total inability to judge, in fact.

> The perpetrator might reasonably think you're sober enough to make your own decisions. Especially if they are also inebriated.

It doesn't matter what the perpetrator thinks. And especially? Is the perpetrator less guilty of rape depending on his blood alcohol level?

And yet

You get painless sharing of domain types between client and server via serde; you still get native async/await support; you get more powerful data modeling features than even Typescript can provide (although Typescript's union types are definitely much more ergonomic). You get a standard library that's not a joke. You don't have to wait until proposal-temporal gets ratified and implemented in order to have sane date/time handling (recently hit Stage 3 btw, woo!).

Honestly, only ScalaJS can match all of those benefits, as far as I can tell after examining a dozen of languages targeting the web.

So yeah, I'm super curious to hear what problems you encountered with Rust as a web frontend language.

Rob Pike politely declined the patch, commenting "I might prefer to leave it unaddressed for the moment. Proper locale treatment is coming (I hope soon) and this seems like the wrong place to start insinuating special locale handling into the standard library."

Three years later another Go team member commented that "Date localization is definitely still in the planning."

We're in year 8 now. The issue is still open. Rob Pike is still hoping.

That's great, but Twitter already does that by default. Is this about padding between paragraphs (in the CSS sense)?

The language has come a long way since this writeup.

https://docs.rs/fs-err

At some point I just started writing these things in Rust instead. Describe what I want deserialized as a struct. List the fields I want as enum variants. What's that, rustc, the "name" field is optional? Ok, that makes sense, I'll handle this right away. Done. Hey, rustc, how come people talk about fighting you all the time when you're actually the world's greatest pair programmer?

  #![feature(bound_cloned)]
  #![feature(const_float_classify)]
  #![feature(const_fn)]
  #![feature(const_fn_floating_point_arithmetic)]
  #![feature(const_generics)]
  #![feature(const_panic)]
  #![feature(once_cell)]
  #![feature(option_result_contains)]
  #![feature(or_patterns)]
  #![feature(str_split_once)]

or_patterns are pleasant syntax sugar.

bound_cloned, option_result_contains, str_split_once are minor convenience shortcuts for things you can do slightly more verbosely on stable.

The other half are all about const generics and const fns. You can emulate some of them on stable, but the cost far outweighs that of switching to nightly in my case.

(Great article btw! As always.)

Both are general purpose languages, so of course they overlap.

> Good luck rewritting all the big data tools from Java (Elasticsearch, Spark, Kafka, Hadoop, Neo4j, Deeplearning4j, Cassandra, Solr, Arrow, OrientDB)

Cassandra (https://scylladb.com) and Kafka (https://vectorized.io) have already been rewritten once in C++, with massive latency and throughput improvements. No reason why they couldn't get their superior Rust clones in the observable future.

Materialize (https://materialize.com), Noria (https://github.com/mit-pdos/noria), and Sled (https://github.com/spacejam/sled) are just some of the Rust database projects that are aiming at unseating the de facto standard implementations in the space. InfluxDB (https://www.influxdata.com) is now doing major Rust development as well.

The future is almost here. It's just not evenly distributed yet.

Sometimes you need "Wake me up on December 24th at 10:00, regardless of where I am that day", and sometimes you want "The match will start on May 1st at 21:00 British Standard Time, and I want to be alerted about this even if I'm in New Zealand at that moment."

What I meant is a distinction between a `LocalDateTime` (first example, timezone is not relevant) and a `ZonedDateTime` (second example). The latter is very close to `Instant`, which is a point on the UTC timescale, but the subtle difference is that if timezone definitions were to change - as they often do - the `ZonedDateTime` would correctly remap to the actual `Instant` when the event was happening.

I see your concerns about performance, but 1) temporal objects are so small that there are plenty of optimization opportunities for the JS engines to eliminate or greatly reduce allocations.

2) The larger and older your project, and the more people are working on it (including authors of third-party dependencies), the murkier data ownership becomes. With that you are more likely to slip into defensive programming practices. "I have a `Date` object that is someone's birthday, but I need to pass it to multiple functions and then serialize it to storage. But I can't tell for sure what those functions are doing with that value. Should I serialize the date right away and persist that value later? Should I just create copies of the object to pass to the functions?"

But birthdays don't mutate, so now you're worrying about a thing that shouldn't be an issue! In the unlikely case that someone's birthday date is corrected, May 9th doesn't suddenly turn into July 15th. In the real world you don't drag the red circle drawn in marker on a paper calendar with your finger from one cell to another, or white out the day number and write in another one. You cross the old circle off and draw a new one in the right place.

My background is in backend services, hundreds of threads running on dozens of cores. The peace of mind that comes with being able to pass values to async functions and thread pool executors, and knowing that they won't turn into a pumpkin at midnight is a very real thing. There's a performance price to pay, sure, but it's so tiny compared to the wins in development and debugging times. And in the particular case of date/time objects, most things are around 8-16 bytes anyway so it ends up not mattering much.

Tangent: this is the fear that Rust talks about in its value proposition btw. Technically, everything is mutable in Rust. You can flip a bit in an integer that is passed to a function from inside that function if you want. But the difference is that you have control over who gets to do that, and you have visual cues in the code (the `mut` keyword), and you have assurances from the compiler that the rules are followed. One owner at a time. Many can look, but not while a value is modified. Best of both worlds. The end result is that it never bothered me that `Date` is mutable in Rust. Either I'm the owner, or I borrowed the value to look at it, or I borrowed it for mutation and have the guarantees that 1) nobody else is doing the same; and 2) nobody will see in-progress modifications until I'm done.

moment.js: Mutable. Thank you, next.

Luxon: Takes the effort to implement `Interval`, which would be `Range<DateTime>` in any proper language, but somehow avoids providing separate `Date` and `Time` objects.

Day.js: When you kinda like moment.js, but your bundler says it's too fat.

date-fns: The finest of pure, curry-able functions over the minefield that is Javascript's `Date` object.

js-joda: If Javascript didn't have classes already, this project would probably port the entire Java runtime to JS just to replicate them. Likely the most correct handling of date/time stuff available for the browser, but damn, at what cost?

------------

Edit: this turned out way too negative, my bad. All I wanted was a library that offered:

0) Type definitions.

1) Immutable classes of `Date` (year, month, day), `Time` (hour, minute, etc), `DateTime` (the prior two combined), `Instant` (for a certain moment on the global timeline), and `Duration`.

1b) `DateTime` should probably be split into two separate things, one of which is aware of time zones.

2) All the obvious date arithmetic functions - duration between dates, adding/subtracting durations, etc etc.

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.