there's the reflect-metadata package but the type information it exposes is very limited, "object" instead of {a: "foo"} and so on.

I wrote an article about this a while ago: https://codemix.com/opaque-types-in-javascript

I don't think even ReScript can do this (yet?)

given it's just ocaml I don't think it can do this ever, not that it's necessarily a bad thing.

oh let's be clear there's no sensible real world use cases of this thing. it's a demonstration of what TS's type system can do

Art is all about making interesting things that serve no functional purpose, though often they have useful byproducts.

This is a work of art.

One use case of something similar is generating a regular expression matcher at compile time for example. This is what the C++ library https://github.com/hanickadot/compile-time-regular-expressio... does.

There are a lot of uses of compile-time code. One I have been interested in is generating bindings to other languages or generating serialization code, or even generating bytecodes for VMs with specific bytecodes for accessing your native data structures (instead of adding a level of indirection).

it's a bit fragile only due to my laziness, it could be done properly if this were a serious project.

How would it be done if done properly?

same mechanism, just deal with more edge cases. e.g. whitespace isn't really trimmed correctly at the moment, it doesn't handle escaping quotes in strings and so on. I did think about trying to match postgres's grammar but it's a lot of work and probably implementing a PEG first would make it easier.

> The implementation isn't even that horrible

You're making me blush!

The list of integers could be replaced by using tuples and reading their lengths to do basic arithmetic. Might run into recursion limits though.

> The list of integers could be replaced by using tuples and reading their lengths to do basic arithmetic.

Is that anything like church encoding?

https://www.wikiwand.com/en/Church_encoding#/Church_numerals

Not really. In the Typescript type system tuple types are array types where the length is encoded in the type system. Tuple types can be “added” by concatenation to produce a new tuple type:

    type two = [0, 0]
    type three = [0, 0, 0]
    type five = [...two, ...three]
    type TupleToNumber<T extends any[]> = T[“length”]
    const num: TupleToNumber<five> = 5

Am I understanding this correctly that typescript provides a type-level property on tuples called `"length"`?

To clarify, the "tuple" is just an array with fixed length. So ts isn't "providing" the length property, it's simply surfacing the underlying Array#length in JS, which it knows to be a constant.

yep!

hover over the type annotations to see results in the playground, that's the output :)

The errors aren't really errors, just warnings about unused types

I used to be a big fan of the idea of schema.org, but it seems to be used by Google to keep as much traffic as possible on Google properties.

The biggest threat to small sellers is Amazon. schema.org benefits sellers by making it easier to list and sell their goods elsewhere (including Google Shopping). Standards that help combat vertically integrated monopolies seems like something HN readers would be in favor of.

> Standards that help combat vertically integrated monopolies seems like something HN readers would be in favor of.

This. You can pretty much think of schema.org as "The Semantic Web - The Good Parts". It's not a literal description of course (there's plenty of potentially worthwhile 'semantics' that isn't covered there) but it's in the ballpark. And the best part is that sites are incented to be truthful wrt. their machine readable info, because they might get banned/downranked by the major search engines otherwise. So everyone benefits.

It seems like it has the potential to serve just about everyone but the site hosting the data.

For example, recipe sites are overwhelmed with pages and pages of generally poorly written and uninteresting background information designed to make you see as many ads as possible. However, many recipe sites added metadata with complete recipe contents, free of fluff. Sure, Google uses that to read off recipes from the Home, but there's also a python module that does the same and could be linked into a custom recipe book.

In these cases, everyone but the content producer is better off for not having to wade through junk content to find what you're looking for.

Everyone serious about recipes has it you wont rank without it

So it seems Google might have created the problem that they're solving: sites have to be full of reams of mainly useless content to rank, then Google pulls out the useful stuff and displays it in search.

I am still a fan of it, especially when it comes to building an IT driven organization. I take it as an example for pitching a terminology repository whenever possible.

Its a worthwhile goal if you intend to make money, rather than donating free information to Google.

You've just succumbed to the X/Y problem. If you "intend to make money", then that is your goal—not the measure of your traffic, and not your ability to stick it the man or whomever you consider to be your competitor. The parent commenter is right; there is no intrinsic value in the measures that you keep invoking. The unrelenting focus on those auxiliary details—to the exclusion of the real goal—is the basis of Goodhart's law.

Yes. This seems very transparently a way for google to hijack customers trying to get to your site for shipping status.

The error is in believing that people are "trying to get to your site". Be real. What people are trying to do is "get their shipping status".

If you want to say that eliminating steps and allowing people to get what they want without having to go through your site means that you lose the opportunity to push other sales on them or something, then okay, fine, make that argument. But be honest about it, and don't try to frame things as if your foremost concern is for what the people want, instead of what it really is—which is trying to optimize for conditions that are best for you, the party that the people are otherwise made to deal with.

I think the danger is that it's "control creep", Google collect so much information that no one needs your website.

Then Google offer a way for people to buy your products simply. Then they prioritise your competitors that use Google's offering because it's simpler for the user. Then you have to use Google to sell your products too. Then the price goes up or you get removed from the listings for some arbritary reason with no support.

Yes, they want shipping status. I don't dispute that. But maybe I have adjacent info that's helpful, like return instructions, or what to do if there's damage, shipping status for other active orders, or "how to configure" info, etc. And Google will take it farther and shift future potential sales to places that they can monetize. Taking away all of the customer interactions from businesses affects their revenue and ability to deliver good service. Google is choking off small businesses. The asymmetric relationship isn't sustainable. Google benefits a lot from scraping all this info and returns little.

>> Yes. This seems very transparently a way for google to hijack customers trying to get to your site for shipping status.

> If you want to say that eliminating steps and allowing people to get what they want without having to go through your site means that you lose the opportunity to push other sales on them or something, then okay, fine, make that argument. But be honest about it, and don't try to frame things as if your foremost concern is for what the people want, instead of what it really is—which is trying to optimize for conditions that are best for you, the party that the people are otherwise made to deal with.

If we're going to be honest, we have to frame this as Google trying to grab an opportunity to push other sales on users, not as a them trying to get people what they want faster.

And while we're being honest, we also have to acknowledge that Google is already extraordinarily powerful (as shown by the assumption that "eliminating steps" means "eliminating non-Google interactions"), and giving them this kind of data only makes them more so.

Agreed. I removed all of the micro data from the sites I manage for this reason.

Schema doesn't seem to have any benefit to anyone but Google.

I am going to respectfully disagree with you. Sure, Google and other corporate backers of schema.org are acting in their own self interests. However, having machine readable metadata is a rising tide that floats all boats. I fail to see how small businesses are prevented from using metadata.

There is a lot of valid criticism of large tech companies like G and FB. However, it is up to us as individuals to control our own use of technologies, limit ourselves in our interaction and data sharing. Off topic, but I am a happy customer of freedom.to that lets me place what are effectively parental controls on my own use of social media and other digital time wasters.

Digital media is dehumanizing unless used very sparingly. I use G and FB services but in a very controlled way for what I think is my own benefit, not theirs.

> I fail to see how small businesses are prevented from using metadata

Your answer misses the point, which is that microdata and co profit Google first and foremost who are extracting information from 3rd parties and displaying that information on their own website or crunching them for various purposes without giving back web traffic or a cent.

Implementing micro data on public facing websites isn't cost free.

> Your answer misses the point

Sorry, but the claim was this:

> Schema doesn't seem to have any benefit to anyone but Google

If that's not "the point", then the comment shouldn't have suggested that it was.

> Sorry, but the claim was this:

> > Schema doesn't seem to have any benefit to anyone but Google

I think the key word is "seem" here. Hypothetically, microdata could help other companies - but I don't know of any that use it.

If I have an e-commerce website that sells personalised hats and I add the shipping info microdata to it, who is going to use that other than google?

Duckduckgo has a shopping tab too (although, it's not as functional and comprehensive as googles, in my experience). If there's adoption of the schemas, I'd guess all the shopling crawler sites will use the data.

If you expect to show up generally favorably in a shopping comparison, having shipping data available would seem to be useful, since people may not want to purchase without an idea of when they'd get the items.

Of course, if you don't get purchases through those channels now, adding shipping data probably won't help.

> who is going to use that other than google?

Uh... the human on the other end that Google is relaying the information to...

I don't think anyone would disagree with the statement "if you rely on Google to obtain all your users, you need to do everything you can to help Google"

However, we're in a comment thread that went

> > Schema doesn't seem to have any benefit to anyone but Google.

> I fail to see how small businesses are prevented from using metadata.

The only use case I can think of for small businesses is scraping your rivals and seeing what they're getting up to.

Helps keep Linked Data somewhat relevant, at least.

Works for recipes and products - which schema did you remove?

This is a missed opportunity to make JSX more than solely about UI and I'm pretty disappointed about it.

JSX is really a way to describe a hierarchy of deferred function calls independent of their callers. This could be tremendously useful in a number of different contexts, not just UI. What would a state machine look like if the states could be described in JSX? What would rx.js look like if this mechanism was available?

The current tooling makes experimenting with possible alternate use cases pretty awkward, and so basically no one is doing work in this area.

I believe that these changes, particularly the `jsx` and `jsxs` auto import, will make it even harder to separate JSX as a concept from React and React-like libraries. It'll make it harder to standardise JSX, which is frustrating as it's the most supported ECMAScript syntax extension by a long way.

My modest proposal is that a JSX element desugars to a call to a block scoped identifier called `jsx`, so I can do something like this:

    import { jsx } from 'react';
    import { elementCreator } from 'somelib';

    const someFunction = () => {
      const { jsx } = elementCreator();

      return <iAmNotAReactElement />;
    };

    const MyReactComponent = () => <div>cool</div>;

Taking this alternative approach would give developers a widely supported syntax extension that could allow for some really innovative solutions. The current path is going to do the opposite.

I understand that there are perf optimisations that React can do if they control all of this. But I feel like they're looking at this too narrowly, from only the perspective of UI. They have the power to open up a lot more opportunities.

TBH this sounds like it should be a new transform, not in the default one.

Speaking for myself, I rather this be an alternative so I can get the best perf on my React apps, but have the option to switch to this when experimenting with using JSX for other things. This is an interesting concept, you should build it (:

Writing an alternative babel plugin to do the transform this way would be pretty trivial, but doing so for TypeScript is not (officially) possible. TS is going to choose one and it's going to be the one React uses.

Also the decision to split React's createElement() into jsx() and jsxs() means that to maintain compatibility all libs would have to do the same, and provide both functions, all because of an implementation quirk in React.

JSX should be a standalone thing. It's not intrinsically React, and shouldn't bend to React's needs alone.

Out of curiosity, why do you prefer JSX to nesting functions? I understand that for HTML you want to meet developers where they are, but that doesn't necessarily apply to other use cases...

JSX is a tree of deferred function calls. It's nothing to do with HTML, despite them looking similar. Normal function calls are not equivalent

Well, yeah. Can't you defer normal functions?

It can be done if you write your code like this:

    function MyThing() {
      return (
        el(A, {value: 123}, [
          el(B, {value: 456, foo: true}, [
            el(C, {awesome: true}),
            el(D, {awful: false})
          ])
        ])
      );
    }

but there's a reason people prefer JSX syntax

What's motivating your hostility in this thread?

There are people who are designing nice native compiled languages with a proper knowledge of PL design and implementation, for example:

    Zig
    Odin
    Nim
    Crystal

And then there is V author, who claimed highly improbable and sometimes CS-defying features, and got popular and also got donations.

If you say rust crowd is overenthusiastic and cult-ish, you haven't seen those teenagers on vlang discord. All this while not having 1% of technically talented people in Rust community (which I often dislike for too much enthusiasm).

When Andrew Kelly (creator of zig, I know him only on this site and zig project, no affiliation) criticized V of hype, and he got downvoted / criticized here for being politically incorrect.