Changing orientation affects which parts of the display processor are used. In general, the low power states on GPUs are very capricious.
eg. from personal experience, on older Nvidia cards (1080 Ti), just adding +1Hz to the refresh rate (or using a slightly higher resolution, or 10-bit color, or no DSC etc. etc.) caused it to never enter low power mode, changing power consumption permanently from 10W -> 50W.
AMD GPUs on even the most modern Linux kernels don't enter low power states properly. If you do change the power profile to do it more often, browsers become a laggy mess.
The game originally used a "voxel" engine [1], but the final release switched to affine texture mapping (with a heightmap-based terrain, still).
The voxel-style engines tend to feature a longer draw distance (due to it being cheaper to render, as you can easily use various hacks to eg. halve texture accesses far away).
For a detailed look into the rendering of Magic Carpet, start from Slide 8 of [2].
This doesn't seem particularly hard to SIMD, especially when the CPU architecture has "compress/expand" horizontal instructions. The first byte fully encodes the length, which is not harder than the continuation bits of (U)LEB128. It's a basically a common length-prefixed encoding with an extra subtract added in, so someone has probably figured out an efficient algorithm.
It might be slightly more instructions than some other serial VL (variable-length) integer codec choices, but overall I don't think it's more difficult.
The very efficient SIMD VL codecs tend to stripe (separate) the control and data bits, so they're in a different design space anyway.
It can't be done, because the next bytes are dependent upon the first byte (which only works in limited circumstances, and where you have constant spacing between the values).
ULEB128 works in SIMD because there's only one dependent bit per byte, so you can speculatively decode and then correct later cheaply. Bijou requires you to check the first byte and then branch based on the value using all 8 bits in the decision matrix (to handle branches 0-247, 248, 249, 250, 251, 252, 253, 254, 255). This absolutely DESTROYS any parallelization opportunities.
Not to mention that non-canonical sized ints (3, 5, 6, 7) have abysmal performance compared to unaligned 2, 4, and 8 byte reads on modern processors.
Right, I think we have a slightly different definition of SIMD: You mean byte-parallel, I mean "doable with SIMD instructions". I also didn't imply the performance would be better than other methods...
Even though decoding the lengths must be serial (since's there's no unambiguous way to differentiate a tag and data byte), it's still doable within the wider SIMD registers, so there's some theoretical efficiency gain to be had (depending on the shape of the data).
On a general note, the continuation bit and prefix byte forms are equivalent, you just broadcast the prefix byte and compare against an increasing vector to convert it to a mask. Yeah, there's probably more fiddly SIMD if there are multiple prefixes in the register, but doable (it's just not byte-parallel, you eg. unroll the serial decode loop 8 times or whatever your maximum output byte width is, and mask out).
Simplified:
// Just maps a byte to its position in the register
__m128i idx = _mm_setr_epi8(0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15);
// Broadcast the prefix
__m128i nn = _mm_set1_epi8((char)prefix_byte);
// Get applicable locations: prefix_byte contains the length, if byte_pos < len, the corresponding byte will be set
__m128i m = _mm_cmpgt_epi8(nn, idx);
// If you *really* want a high-bit mask:
m = _mm_and_si128(m, _mm_set1_epi8((char)0x80));
Yeah, sorry, I didn't say that very well. Single value decoding of Bijou values is of course trivial in SIMD, but the performance benefits of SIMD come from deterministic boundaries across a window. ULEB128's continuation bit is fixed position, so it's data independent. One pmovmskb gives you every boundary in the window.
Interleaved Bijou has no such signal (tag and payload bytes both span 0x00–0xFF), so finding the boundaries is a dependent per-value walk with no opportunities for parallelism.
There's still speculation though - if eg. most values are of 1 or 2-byte length, you can speculate that any control-valued byte is actually control. You can even do a compensation pass to try to fix some amount of mis-speculations, and then bomb out if that fails.
With that, it's mostly byte-parallel (though data-dependent as I mentioned).
LLMs have a limited context window - similar to the limited attention span and memory of humans. LLMs also have trouble attending to many constraints at once.
Therefore the best language for agents is likely the one that, on one hand erases all irrelevant details (ie. raises the level of abstraction and does not force focusing on eg. memory management), and on the other hand encodes any domain-relevant details in the code (eg. using advanced type systems, annotations, contracts, spec-like tests eg. property-based).
Human readability is a separate concern and still relevant, but the two mentioned properties actually generally improve on that as well (at least for engineers persistent enough to scale the tower of abstraction).
Based on this, it seems Go is certainly not that "agent endgame" language. It has large amounts of boilerplate, a general lack of safety around concurrency features, a pretty middling static safety story overall with a generally underpowered type system.
I don't think the perfect language exists, yet, but just wildly imagining, it would probably be something like a cross between Scala, Elixir and Lean (or equivalents). Unfortunately none of those languages also have the large training corpus required to make them perform well in all agenting engineering situations (yet).
For any language comparison, one must separate the expressiveness of the language, which limits the long-term possibilities for agents, and the training corpus, which is what mostly gives it the current standing. I think we are still in the phase where the languages are separated by essentially random non-design factors such as the amount of training environments the frontier labs are willing to create for them.
Given that, the syntax does not matter all that much, as long as the base language itself is flexible enough - as a another wild idea, it's also possible that eg. Python could mostly swallow all these features through external tools (eg. the pre-existing type checkers or linters), and if the frontier labs bother to RL on those tools, that would also work (see also: Mojo).
I know Clojure misses the mark for you in some major areas, but having a real, proper REPL for an agent to interact with makes for an extremely strong feedback loop. IMO, a strong candidate for an "agent endgame" language has this.
I love REPL-driven development, and exploratory "programming" via small snippets is likely part of the endgame (the more the agent strays outside its comfort zone, the more it's needed). It also looks like it paradoxically saves context, since piling up many small snippets is still better than trying to fix a one-shot gone horribly wrong.
And yeah, if Clojure had a better static safety story, it would actually rank high, since it's high-abstraction with metaprogramming capabilities, excellent runtime specifications, and has a good "garden path" ie. natural code is good code.
(As a devil's advocate though, REPLs can be replaced with gluing together scripts with ad-hoc state/caching via the file system, which LLMs seem to be pretty good at already...)
So as an addendum, introspectability is also important ie. allowing to discover the state and composition of the system at any moment - though that's partially a language (eg. reflection) and partially a tooling (eg. debuggers) issue.
It sounds almost squarely written by someone without practical experience of REPL-driven development. Specifically with Lisp REPLs. Sure, other languages also have REPLs, but if you dig just a bit deeper, you'd learn that every single step there in R[ead] E[val] P[rint] L[oop] has differences. That makes the entire holistic experience of using the language drastically different. Not universally better for every domain and every case, just different.
Here's one of many practical examples I can give you - my WM on Mac is Yabai, it is hooked up to Hammerspoon, which can be scripted with Lua, which means I can use Fennel, which means I can have Lispy REPL. And from here, it is a bit difficult to explain the difference. The challenge is that the magic is invisible to people who haven't felt it.
The key insight is "the image vs the file". In most languages, your program is a description that gets turned into a running thing. The REPL is bolted on - a convenience wrapper around that same lint/compile/run/restore-the-state cycle. Python, Ruby, Lua, C#, etc. REPLs work that way. You're still fundamentally working with files that produce processes.
In a Lisp, the running system is the environment. There's no gap between "the code" and "the live thing". When I connect to Hammerspoon's Lua runtime via Fennel, I'm not sending scripts to a subprocess - I'm reaching into a living system and reshaping it while it runs.
The missing vocabulary here is "liveness", not "fast feedback" - that's a pale shadow of it. Liveness means the environment has no opinion about what's "done" versus "in progress". Everything is always mid-flight and accessible.
So I can actually reach out in live REPL session to let's say Slack app window and extract the data about every single element in the app, get the content, compare and continuously reiterate, without having to restart anything, without even saving the code - just pure data extraction without compiling, dealing with state changes, etc. I can interactively move the window, resize it, hide, or maximize it - all that programmatically. Imagine DevTools on steroids, only it works for everything, not just web apps.
Learning Lisp and Clojure allowed me to truly experience the genuine joy of programming, because it makes it feel like you're playing a video game. And now, can you even imagine what happens when you open up access to all that awesomeness and grant it to an LLM? Most people have zero idea what it feels and looks like, when you can point an agent to a REPL running in a k8s cluster and it introspects things on the fly, while you let another agent poke through the UI and they work as a team to fix something or develop a new feature.
> if Clojure had a better static safety story, it would actually rank high
This framing reveals an assumption - the primary value of a type system is catching errors early, and that Clojure is just a dynamically typed language that would be improved by adding that. In a Lisp image, "early" and "late" barely exist as meaningful categories. The feedback loop isn't compile-time vs runtime - it's just... now. You evaluate a form and you know immediately. The error is right there, in context, with the live data that caused it.
Static types are, in a real sense, a compensation for the gap I just described - the gap between the description and the running thing. When you can't easily inspect or reshape the live system, you want the compiler to tell you as much as possible before you cross that gap.
Clojure has Spec (which can do things most other type systems would struggle to express), it has instrumentation, it has a rich data inspection story. You said "debugger", Clojure has Flowstorm, which is one of the best debugger experiences I have ever encountered in any language, and I have used more than a few.
> Static types are, in a real sense, a compensation for the gap I just described - the gap between the description and the running thing. When you can't easily inspect or reshape the live system, you want the compiler to tell you as much as possible before you cross that gap.
I think this underrates static typing. For me the biggest value add of a static type system is that while doing a big, breaking-change refactor, I can near-instantly see all the places I need to update callers. Getting the code to work in the place I was actually working on is easy, I was already focused there. Static types pay off by helping me know when my change broke other parts of the system I wasn't even thinking about.
I'm not underrating static typing and I'm not saying static types have no value for refactoring - they absolutely do. But the "I can't refactor safely without types" argument tends to assume a codebase structured the way typed codebases are structured. Idiomatic Clojure has a different shape, and the refactor pain you're describing almost never materializes.
What the static typing camp can't acknowledge is that not all dynamically typed languages are equal. I agree with your sentiment e.g., on Python codebases - it's legit pain, but PLs like Clojure and Elixir are a different story.
Data-orientation flattens the call graph. Most Clojure functions take and return plain maps/vectors/seqs. A "breaking change" to a data shape doesn't ripple through type signatures across the codebase the way it does when every layer has its own nominal type. You change the shape at the edges (parsing, validation via Spec/Malli) and most intermediate code keeps working.
Fewer, more general functions. map, filter, reduce, get-in, update, etc. replace dozens of bespoke typed methods. There's just less surface area to break. But then again, I would say `(map)`, and someone familiar with Javascript's `map()` would have some wrong assumptions.
You really just can't evaluate ANY language by picking a single aspect of it without wholly understanding the holistic picture in practical, battleground scenarios. Yes, Clojure is dynamic, but it doesn't mean it's harder to maintain or to more difficult to build with, or you just can't write robust software in it. It genuinely has qualities that shine in some domains.
My claim wasn't "static types are useless for refactoring" - it was that they're a compensation for the gap between description and running system. Your refactor scenario fits that exactly: you need the compiler to tell you about distant breakage because you can't cheaply ask the live system "who calls this, and does it still make sense?"
In a live image, that question is answerable directly. find-usages, instrument the function, exercise the path, watch what flows through. The "places I wasn't thinking about" announce themselves the moment they're touched, with real data in hand - not as a list of locations I now have to go read and reason about cold.
Your intuition is not right, I have plenty of experience with REPL-driven development, even having used all the tools you have mentioned in your post. (and Clojure Spec is exactly the runtime specification part I was referring to in my comment...)
Logically, it's more the other way around - REPLs are in that sense a compensation for static types, since nothing forbids having a REPL and static types (see: eg. Julia. OCaml, Haskell, Scala etc. have REPLs too, but they are closed-world).
There's a fundamental trade-off though, with the open- vs closed-world assumption - if your types and (generic) methods are open world, then certain kinds of errors are just not analyzable. (this is a more general mathematical truth, also occurring in eg. description logics and the Semantic Web)
As you hinted, REPLs also don't work well for eg. large pipelines farmed out to clusters of machines, or anything that requires a high degree of static assurance, eg. control software - you either must statically analyze for all errors for it to even be legal, or the cost of having to "live fix" an error is much larger than preventing it in the first place (or just impractical for clusters).
Sure, a degree of live patching and experimenting is desirable (namedrop JPL as Lispers do), but that's a somewhat orthogonal concern.
A Lisp-style REPL combines introspection and live patching for both code and data. This can be achieved in many heterogenous ways besides a REPL, though. It's just not a nice, curated and holistic experience. But agents don't really care about that. LLMs don't get magic feelings. They can easily work around minor annoyances and a lack of ergonomics (assuming it doesn't burn context).
(Since LLMs tend to leave junk behind and slowly corrupt everything over time, a persistent image is also not necessarily a good thing. Reproducibility is also harder.)
The Unix philosophy "everything is a file" can ultimately also be viewed as image-based programming. [1] The system is the image.
As long as you have a way to address (via files, namespaced symbols, UUIDs, URLs, numbers etc.) the code, the execution state (ie. the stack frames) and memory (ie. the heap of objects), it has the same effect.
The problem with most software is that its internals are not addressable. I don't think one has to use eg. Lisp to fix that though. I do acknowledge that most static languages fail here.
These are not what are commonly called tagged unions. It's actually closer to an untagged union.
The C# union does not store any discriminator. Just look at the implementation - it's a single `object?` field.
The discriminative part is handled by run-time type information, which is stored in the object itself, not the union - which is why the C# built-in implementation requires boxing.
Also, you can use the same class/record type ("discriminator") in several different unions - again, a feature which ADTs/sum-types/tagged unions in most functional languages do not have.
You can even store one single object (ie. identical by reference equality) in several different union values at the same time, theoretically, which in combination with mutability is... uhh, certainly not common functional/mathematical semantics.
String literals are structural types which are way more expressive than regular (Haskell) ADTs, which are nominal types.
In TS in particular, in combination with other features (mapped types), they are equivalent to row polymorphism + whatever Haskell/GHC features enable type families to specialize on constant literal arguments (or you can use atomic types, but that's not structural / open-world)... so pretty advanced.
This is valid TS/Python:
type ABC = "A" |"B" | "C"
type AB = "A" | "B"
const x: AB = "A";
const y: ABC = x;
The equivalent Haskell requires using several extensions.
I know. I literally gave the example of a Python Literal in the post you're replying to. TS too. :)
My overall point is that Haskell's type system is sufficiently expressive (you may not have "A" | "B" | "C", but you do have A | B | C) that there's no obvious remaining use case for string literals, unless you're thinking of typing input by way of expected literals instead of actually parsing it, which is... a choice. :P
By Haskell's type system do you mean with all the GHC extensions?
Because TypeScript has structural sub-typing, while standard Haskell (eg. `A | B | C`) has neither subtyping nor structural typing, which both are very useful features for safe "integration/glue" type of programs.
(String) literals form a fundamental part of the TS "row polymorphism" (record types) and eg. tuple union type implementation.
You can type a non-empty array that starts with zero...
> By Haskell's type system do you mean with all the GHC extensions?
No? What extensions does `A | B | C` require?
> Haskell has neither subtyping nor structural typing
Is subtyping back in? Good news for Java and C++.
Re structural typing, I would ask what behaviour you're after, specifically. For example, this is a valid, typed Haskell function for any two values that can be added, including any user-defined ones:
adder a b = a + b
If by structural typing you mean silently coercing types that the compiler deems structurally equivalent, then no, but I don't think many people writing Haskell would consider that desirable. A `Person` may have an age (40) and a `Wine` may have an age (2005), but you're not going to get sensible results if you start adding those two together, and your compiler should probably stop you.
Structural typing is the sort of thing that is very valuable if you're bolting a type system onto a language with a cornucopia of untyped structs, like JS objects. It is comparatively much less valuable if you're working in a typed ecosystem to begin with, since you're not liable to have loose untyped structs floating around that require coercion.
> "integration/glue" type of programs
It does sound a lot like you're using string literals in lieu of parsing foreign input, which strikes me as a pretty bad idea. Particularly in a language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways, and cause behaviour far removed from what any static analysis of the TS source would suggest.
> You can type a non-empty array that starts with zero
Can you please name me any possible actual use for this? Especially given the type doesn't even exist at runtime and will never be enforced on input data, so this is a once-off check for comptime constants?
OCaml and Scala, both also famously strongly typed functional languages, also have structural typing (OCaml even has many different kinds at many different levels!). Mainstream, Go is based on structural (interface) typing.
The Person/Wine example is a pointless strawman. That's not what structural typing is generally used for.
The entire comment is basically making up strawmans...
I didn't give practical examples to save space, obviously, it was just to disambiguate what I meant.
TypeScript has several runtime-safe advanced validators based on its type system (most well-known being Zod), capable of enforcing types similar to what I provided.
To conclude, these type system features were added by multiple experienced language designers for a reason, to languages that already had functional ADTs, so going "huh but what are these even useful for?!" to me sounds a bit clueless (or argumentative), so I don't see a productive continuation to this discussion.
Haha, I knew you'd bring up Go. I even considered pre-emptively dropping Rust and Zig as counterexamples. I think most people who favour static typing consider the duck-typed interfaces of Go to be a mistake. Personally, I consider all of Go to be a mistake.
> these type system features were added by multiple experienced language designers for a reason
Oooh, an appeal to authority, where that authority isn't even named. I'll have you know a famous queen told me you're wrong on this, also for "a reason".
> TypeScript has several runtime-safe advanced validators based on its type system (most well-known being Zod), capable of enforcing types similar to what I provided.
Right, so TS typing is so amazing it requires runtime parser libraries from NPM, and Haskell is less sophisticated because it's not stringly typed.
You realise the entire, complete, exhaustive runtime schema for your zero-first non-empty integer array example looks like this in Haskell, right?
sch (0:_) = True
sch _ = False
That's a complete function that somehow manages to work without pulling in NPM dependencies. The best JavaScript minds of our generation remain baffled.
> The Person/Wine example is a pointless strawman
> I didn't give practical examples to save space, obviously, it was just to disambiguate what I meant.
So when you use illustrative examples, it is to "disambiguate what you meant" (huh?), and when I do it, they're "pointless strawmen". A little hypocritical, no?
> a bit ignorant
Honestly, I don't think you know what you're talking about at all. You clearly hadn't even read my comment when you started replying with Python and TS examples... that were already in my comment.
It also really sounds like you're using string literals to type input without properly parsing it, which is just a terrible idea. Haskell's type system is designed precisely to protect you from this sort of mistake. [0] No, you're not always going to get what you expect. No, your JS program will never let you know that's the case. No, a sane type system does not require mainlining runtime parser libraries from the biohazardous oceans of NPM. A schema in Haskell is going to be significantly shorter and sounder than anything in Zod, and you don't need a library for it.
As I said above, TS' type system makes sense for a type system bolted onto a dynamic language post facto. TS needs to more tightly link (even mildly conflate) values and types, since it needs to do a lot of clever narrowing to figure out what mad ball of JS it is dealing with at any given time. Haskell does not operate under any such constraint.
> I don't see a productive continuation to this discussion.
Phew. Timesaver.
Of course the irony of all this is that I use TS daily, and Haskell quite rarely.
Yeah, you're just continuing to take whatever was written argumentatively/maliciously as predicted.
Does not seem like this:
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
> Personally, I consider all of Go to be a mistake.
You also consider Scala and OCaml to be mistakes? Because all of what I've mentioned also works in a very similar way in Scala.
> an appeal to authority
No, I didn't appeal to authority. It's the opposite - it's statistics. Multiple experienced language designers don't add features later for nothing. For a similar process, see eg. closures getting added to every mainstream language.
> complete, exhaustive runtime schema
Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.
> A little hypocritical, no?
No, they aren't comparable since I wasn't using the examples as supports for an argument of whether X is better than Y. Strawmen involve argumentation.
> read my comment... examples... that were already in my comment
I read it in detail, the problem is you didn't really read my comment in detail, which illustrated both the subtyping and structural typing aspects (albeit trivially, yes), which yours didn't.
> You're also fairly clearly using string literals to type input without properly parsing it
Okay then, the arrogance of this is pretty astounding... You seem to know what I'm doing better than I am!
To be clear, I'm not doing any of that. And I've written Haskell way before I wrote any TypeScript.
Everything I said to you prior to my last message was fairly gentle. I'm not sure what response you were expecting to what you wrote at that point, which was to accuse me of disingenuous strawman arguments and ignorance. Perhaps you yourself would have benefited from a rule refresher?
> You seem to know what I'm doing better than I am
Apparently so! Trust me, it gives me no pleasure, and I'd rather I didn't.
> Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.
My dear friend, this is almost completely incoherent.
I wish to strictly type myself as a function at this point, whereby your messages are my input, and void is my output. Zod, activate!
I would say, with a striped-shirt and not a glove in my hand, that the person you were fighting with gets the score, and wins by technicality. I suggest you take the bench first and review your comments and reflect with a wet towel on your head.
Having reviewed as instructed, I stand by everything I said here. Let's review the action replay.
I began by noting that TS has literals and set theoretic types, and that this makes sense for a post-facto type system bolted on top of a dynamic language. Jaen showed up to inform me that TS has literals and set theoretic types, implying he hadn't read my post.
I noted that typed string literals are not generally considered desirable within strictly typed environments. "Parse, don't validate", etc. Jaen seemed to follow this up by aggressively trying to prove that TS is somehow "better" than Haskell. His arguments comprised the fact that TS has literals and set theoretic types (again, yes, this was is in my initial post), and a mixture of personal insults and just straight up nonsense (I wasn't the one to bring Zod into a discussion of type systems... ). At that point I did have a little fun with things, since it had become clear Jaen was not a constructive or good faith interlocutor.
Jaen's central misapprehensions seem to be that (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".
As I repeated a number of times above, TS' type system makes sense for a type system bolted onto a dynamic language. It's extremely useful when the underlying language has oodles of untyped structs flying every which way. Conversely, Haskell's type system makes sense within a holistic strictly typed environment. Structural typing would be a gaping hole in Haskell's strict type safety, which is kind of Haskell's whole thing. Neither system is better, each has its use. Different strokes for different folks.
I don't usually put much stock in upvotes, but I do note I seem to have the edge there. Seems that our esteemed panel of armchair referees respectfully dissent from your narrative, nvlled. :)
You seem to be aggressively misreading what I said, stuck in your own "world" and instead of asking for clarifying questions, making unfounded assumptions.
> I began by noting that TS has literals and set theoretic types
Can you please quote me exactly the part of your original comment that implies that literal types are structural and have subtyping? Because that is what I said. If you did imply that, well, excuse me for helping you by clarifying then.
> aggressively trying to prove that TS is somehow "better" than Haskell
Sorry, what? Refer to the first line of this comment. Just saying that some type system features are extensions or harder to use in Haskell says nothing about the superiority of TS. This is completely your imagination.
> I wasn't the one to bring Zod into a discussion of type systems...
Not sure why this is even relevant, but this was a direct reply to: "...language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways"
Zod (just a random library) is a direct counter-example to that. There may be better counter-examples. One just needs a proof of existence - it doesn't have to be good.
I then had to repeat that I am also talking about static types because of: "...exhaustive runtime schema for your zero-first non-empty integer array example...". TS can both enforce that as a type (which you never presented for Haskell) and as a value. (nominally typed solutions quickly run into ergonomic problems like phantom types not being composable across library boundaries - eg. refinement types, which are even safer by nature, are structural!)
In any case, I'd estimate 99% of people using TS don't encounter any type safety issues caused by the design of TS. Haskell has `unsafeCoerce` too, just a bit wordier than in TS.
If wanting to talk about real unsoundness, one would mention something like bivariance (see also: linked comment), but even then almost all of that is entirely irrelevant in most practical software engineering.
> (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".
Huh, what? Again, I'm thinking none of that. Again, you imply you know better what I'm thinking...
> Structural typing would be a gaping hole in Haskell's strict type safety
I mean, yeah, let me just repeat OCaml and Scala here, both also famously type safe languages... Why make an argument when there's two immediate counterexamples that were already mentioned?
> but I do note I seem to have the edge there
This pretty much sums up the difference in attitude, I'm not here to score internet points in an argument.
I just wanted to comment on why the world is not black and white and even technically flawed languages like TS have something to learn from.
Wow, that's pretty cool. Translating (almost) arbitrary floating point programs into weird integer programs while also preserving equivalence under non-strict floating point semantics? Mathematics can be surprisingly wonderful.
eg. from personal experience, on older Nvidia cards (1080 Ti), just adding +1Hz to the refresh rate (or using a slightly higher resolution, or 10-bit color, or no DSC etc. etc.) caused it to never enter low power mode, changing power consumption permanently from 10W -> 50W.
AMD GPUs on even the most modern Linux kernels don't enter low power states properly. If you do change the power profile to do it more often, browsers become a laggy mess.
reply