off-topic 2023-01-18 | Slack Archive

Drew Verlee05:01:05

Thoughts on this new (to me at least) Type script feature? What's the closets equivalent in clojure? Feels like spec validation only it ties into the tooling so it provides only valid options. https://youtu.be/ODZKZ9sGRAE

👍 2

Martynas Maciulevičius09:01:35

Well Clojure can't give you these suggestions. And satisfies Settings is just a clue for the compiler, not for a validator. In Clojure you could have a spec validation during compile time which you wouldn't then run on runtime... which kind of misses the point of spec validation. Fortunately TypeScript has libraries such as https://github.com/colinhacks/zod which act basically as what we have in Clojure's spec (only validation, not value generation). Then these libraries provide validation function AND they provide the types that you can use everywhere. But then you have to use the library's way to define your types. So I'm not sure if you can have this kind of behavior in Clojure as Typescript doesn't perform validation. I can do const a: string = 1 as any; which is really not the code that you'd want to write but if it's any then compiler accepts it and who cares, right? And if it's any then you can do this:

const num = 1;
const myAny = num as any;
const settings = numAny as Settings;
const settingsS = numAny satisfies Settings;

Clojure's Spec is more about actually having your data in the shape that you want. TypeScript's types are more about providing you suggestions and "guardrail driven development" where the actual data can be different even if your types are "ok" for the TS compiler. If you're in a "typed world" then you're "safe" until you aren't. If you're in Clojure's spec world you're not safe until you validate via the spec. You may want to read this comment and the screenshot of mine from long time ago: https://app.slack.com/client/T03RZGPFR/C03RZGPG3/thread/C03RZGPG3-1656762434.854529 My opinion regarding the operator -- not impressed. It's basically nothing. They already had the suggestions and I was simply using Omit<Settings, "a"|"b"> to provide types that are going to have less fields. This isn't revolutionary in any way, it allows for unsafer code because now you don't really know which values are nil and which aren't. It can allow to have ellipsis parameters as in Clojure but then you'd be basically using JS's Object.assign() which again works in a mutable way and you'd be recreating your object like this to provide default values for your settings object:

const defaultSettings: Settings = {}
function execute<S satisfies Settings>(settings: S) {
  const fullSettings: Settings = {...defaultSettings, ...settings}
  return "done"
}

(I didn't test this code but it should mostly be valid)

👍 2

souenzzo12:01:50

Checkout https://www.youtube.com/watch?v=3HxVMGaiZbc (mostly first part, that is about TS and the JS ecosytem)

didibus18:01:48

It be relatively doable for tooling to leverage spec a little. I'm actually surprised it doesn't yet. If you say a function input is :app/user for example, parsing a s/keys for the list of keys isn't super hard.

👍 2

didibus18:01:47

But I think the issue with spec right now is it's kind of verbose to spec a function to say it takes a :app/user in the first place. Spec 2 was supposed to come with defn integration, but I feel Spec 2 might be stuck in the hammock.

👍 2

♾️ 2

enn15:01:41

I’m trying to find a blog post or series of blog posts about JVM performance that I read a few years ago. The framing was that the author was trying to understand why there is such a difference between the reputation that the JVM has among compiler and VM experts (that it is state-of-the-art and fast) and its reputation among ordinary application programmers (that it is slow and heavy). He did some experiments with different large real-world applications (I remember something from Apache) and found that many of the theory about how the JVM would work were not observed in practice--specifically, many of the real applications he tested never reached a “steady state” where the JIT had correctly optimized all of the hotspots. There may have been a concurrency angle and this may have been in the context of Project Loom/virtual threads coming to the JVM. Does this ring a bell with anyone?

👀 4

👍 2

ghadi16:01:18

@enn tratt's work on warmup

eggsyntax16:01:23

@U050ECB92 looks like that's maybe this? https://tratt.net/laurie/blog/2022/more_evidence_for_problems_in_vm_warmup.html

eggsyntax16:01:07

Or I see that there he references a couple of blog posts from 2018, the first of which is https://tratt.net/laurie/blog/2018/why_arent_more_users_more_happy_with_our_vms_part_1.html

enn17:01:55

yes! thanks Ghadi! that’s absolutely it.

enn17:01:14

I have been futilely Googling for weeks trying to find those 2018 blog posts.

2023-01-18

Channels