Libraries like runtypes, zod, et al. market themselves as validation libraries, but they function as parsing libraries in the sense this article means: with them you "parse" untyped POJOs at the I/O boundary and get typed values (or a raised exception) out the other end.
Typescript language features like branded types, private constructors can make it so those values can only be constructed through the parse method.
They're really not much different, in terms of type safety*, from something like Serde.
*: they are of course different in other important ways -- like that Serde can flexibly work with all kinds of serialized formats.
I understand completely, and the library is intentionally unopinionated in that regard. We simply ensure that the value passed matches the provided schema and ruleset and refine the type in-place.
In certain cases (like validating that an input is ISO8601 format), we refine the input type to a branded type (we have a Iso8601 branded type). At runtime it's just a string, but at compile time TypeScript treats it as a distinct type that can only be obtained through validation. But, it is still not transforming or parsing the data in the way that the blog post intends, which is by design.
Libraries like these are meant for runtime validation. I agree though. I prefer to use the compiler itself (tsc --noEmit) than recreating the validation logic.
It doesn't compete with static type system, it complements it. Static type system in typescript can't do anything with unknown/any values that are crossing i/o boundary - they require runtime assertion to bring them into statically typed, safer world.
Highly recommend the Dr. Stone anime if you're interested in a story with the premise of starting civilization from scratch but armed with the sum total of modern human knowledge about science and engineering.
Also, if you want even further back precedent for this kind of plot device, I highly recommend reading a Connecticut Yankee in King Arthur's court by Mark Twain.
I second this. It's the only show I've seen making a semi-realistic attempt at this (ignoring the absurdity of the initial petrification in the first place and Dr. Stone having superhuman knowledge of all human inventions)
I'd also recommend the Destiny's Crucible series - the basic premise is that a chemist from our world is transported to another planet of humans at a much lower technological level, and some moderately standard isekai hijinks ensue.
I read five of the books, and really enjoyed them; if you like the "competence porn" genre of novels, this is a pretty good one.
See... now, I love that type of show/comic/book/etc. And now that I have a name for it, I want to search for more. But I very much do _not_ want to search for that term. Lol
I watch this with my daughter and we love it. I love shows with "narration", talking about the context/details of things, and Dr Stone really nails that (I know the main character isn't really a narrator.. but it accomplishes the same thing).
I also wrote my solution in Rust. I was pleased that my approach gave me an opportunity to write a linked list and get the chance to apply some rarely used learning[0].
My solution doesn't use SIMD, but is actually takes about the same amount of time as the the solution in the article, given the same number of cores, though an glaring weakness of my approach is that it can only scale up to 7 cores as written.
Rough outline of how mine works:
- Set current best GCD to 1.
- Search through all valid board configurations.
- Bail out from the search early if the current partially generated board couldn't have a GCD greater than the current maximum found, e.g. if we've only generated two rows of the board, and the GCD of those two rows are already less than the max.
- Update the current best GCD as you find higher ones.
- Share the current best GCD value across multiple threads. That way the longer the program runs, the earlier and earlier the searches will start bailing out.
- Don't always read from the shared variable to avoid contention. Instead, each thread has its own copy of the last value it read which we compare with first before copying and caching the shared value.
- Another interesting property of this approach is that it can be used to validate the correct solution even faster than it takes to find it. Instead of initially setting the max GCD to 1, set it to `solution - 1`. That way branches in our search will bail even sooner from the beginning. This leads to the program running about 20% more quickly.
Out of Dropbox's long history of acquisitions, very few of the products from said acquisitions have survived. Did this factor into your decision to join Dropbox and if so how did you weigh that risk?
I was recently trying out Node's newish test runner [1] but wanted better error reporting and was grateful that Node provided an API that let me use any TAP-compatible error reporter. I did find unfortunately that most error reporters I tried seemed to have problems, the most common one was not reporting whether or not a test was skipped, which was a deal-breaker. In the end I settled for tap-mocha-reporter [2] since it worked well enough. I did have to end up patching it to not print extraneous new lines, I suspect an artifact of it using YAML for its internal representation. I do wish there was an error reporter that mimicked exactly the format of Jest, as it's what I'm most used to.
I don't know if its aim is necessarily to model anything you can do in JS. At the moment, TypeScript has zero understanding of prototypal inheritance and there hasn't been any visible progress in that direction.
These are the usual questions I seek answers to first when seeing a new programming language:
- What does writing asynchronous code look like
- Will it have any novel or less mainstream features, e.g.
- Algebraic effects [1]
- Contexts/Capabilities [2]
- Linear types [3]
- Is the type system sound and does it support/need type casts
- Does the language support interfaces/traits/protocols
- How rich are generics, e.g.
- Explicit variance annotations on type parameters
- Lower or upper bound constraints on type parameters
- Higher-kinded types
- Is structural vs nominal subtyping more prevalent
- Does it have algebraic data types? Generalized algebraic data types?
Note Moonbit is a language/platform for industrial usage(not an academic language), I contributed to OCaml so that I am familiar with the good/bad parts of a type system.
Its aim is to build fast and run fast, and generate the tiny Wasm output.
Type system is sound, you can take it as Rust(- some features hinder fast compilation) with GC and an emphasis on
data oriented programming, so we have ADT, generics, interface and ad-hoc polymorphism. We also plan to make the pattern match more expressive with
first class pattern support.
The async story is constrained by the WASM runtime, we will evolve with the
Wasm proposal.
I thought the raison d’être for Rust was not having a GC. If this is a garbage collected language, and requires a runtime for such, isn’t this more like Go or any JVM language?
Arguably the raison d’être for Rust is memory safe systems programming, and opt-in GC you implement as / if needed is just a consequence of that… if you’re not targeting the very small subset of systems that _cannot_ benefit from automated GC then that’s a great choice, but for everyone else it’s just complex boilerplate. This is aimed at an evolving runtime spec that already incorporates opt-in GC.
In other words if it’s Rust’s broader features but explicitly meant to write programs for a runtime that already includes opt-in GC, then it’s not doing what JVM languages or Go are doing, so there’s space for it.
For situations where you can afford a GC, Rust but with GC would be an excellent language, due to the ways macros are done, traits work, how errors are handled, tools like cargo, docs.rs, testing and doctests, self-contained binaries with additional ability to compile extra assets into them, high quality language server (rust-analyzer), and the quality of the ecosystem.
As it is now, though, regrettably Rust imposes on you the penalty of dealing with borrowing and ownership even when there is no reason to pay for that. Its not too bad in most cases but one can't help but imagine a Rust-but-with-GC world :)
I built https://github.com/mmastrac/keepcalm/ to specifically give "permission" to use ref-counting to make your life easier. For a webserver, references don't make any sense and really don't add anything measurable from a performance perspective.
That’s awesome. I do think someone smarter than me needs to write a “Pragmatic Rust” book, or something. The complexities around references and lifetimes put a lot of people off but really aren’t necessary a lot of the time.
If you want some of the ergonomics and DX of Rust, but in a GC'd language, OCaml (the language also used to implement early Rust compilers) might be more the path to be taken. Great tooling, handlings errors in sensible ways, and pattern matching, allows you to move business logic faster and focus on shaping data rather than transforming the bytes of them.
They're just talking about the type system. Yes the type system in Rust serves it's GC-free goals but you could copy paste the type system and build other languages with different goals.
We're thinking about review experiences! We're developers too, and we're keenly interested in how to make code more reviewable, how to help developers _make_ code more reviewable, and alternative interfaces to the notion of changesets.
