Earlier quoted context omitted.
If you're impressed with TypeScript, you should definitely check out ReScript (formerly BuckleScript). Its type system is clean and sound, and yet compiles to native JS without overhead. https://rescript-lang.org/docs/manual/latest/introduction
I don't think even ReScript can do this (yet?)
Show HN: A SQL database implemented purely in TypeScript type annotations
171–180 of 196 posts
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#172I’m impressed/fascinated/horrified by the way it parses a string into a type with a variant of template literal syntax—though it looks like the parsing is probably very fragile. I’m curious why that functionality was added to the language. The end result is actually pretty approachable.
> I’m curious why that functionality was added to the language. I think it's because there are a whole bunch of APIs in javascript where there is a function like `.get("foo")` that internally calls a function called `getFoo` or similar. And this functionality allows such functions to be accurately typed. It basically allows strong typing for stringly typed functions (which are pretty common in dynamic languages)
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#173Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#174JavaScript is such a cool language, and I really love it, especially the FP subcommunity, but the AI community for Python is way bigger, I wish there were more options for neural nets, differentiable programming, and data frame type things in JS. The interoperability with WASM is hugely valuable, and so is the ability to easily publish results on the web. It feels like it’s way easier to make an AI system in python,…
I can see javascript slowly expanding from the front-end into the back-end, mostly thanks to projects like TypeScript that appeal to the back-end crowds, but also because of the whole serverless hype which IMO is justified.
Now there still is a strong "cultural divide" between the software and the data-science communities. And when you see how strong the innertia for python's projects is.. Well I guess we won't see this changing anytime soon.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#175Earlier quoted context omitted.
If you're impressed with TypeScript, you should definitely check out ReScript (formerly BuckleScript). Its type system is clean and sound, and yet compiles to native JS without overhead. https://rescript-lang.org/docs/manual/latest/introduction
Just want to add that the genType project can even compile ReScript to Typescript!
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#176Earlier quoted context omitted.
> I’m curious why that functionality was added to the language. I think it's because there are a whole bunch of APIs in javascript where there is a function like `.get("foo")` that internally calls a function called `getFoo` or similar. And this functionality allows such functions to be accurately typed. It basically allows strong typing for stringly typed functions (which are pretty common in dynamic languages)
Stringly typed functions frustrate me to no end. Tooling for programming gets better every year, yet stringly typed code is so resistant to any of those improvements. Pycharm at some point had to add SQL tools in python strings for gods sake. That kind of weird deep special casing is everywhere with strings drive behavior. Why use a class (inspectable) when a dictionary, a function, and an if statement (opaque) will…
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#177This shows how complex TypeSript has become. It may be fun to write complicated Type annotations such as this, but imagine having to read and maintain the code!
https://youtu.be/jmPZztKIFf4 at 49:50.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#178Earlier quoted context omitted.
I'm not entirely sure, but I suspect it's one of these programming "joke" where you take a concept and bring it far enough that it becomes ridiculous. So I'm guessing there's no real practical use case for this, and is a nice flex from the author. It would be nice if that were made dead clear in the Readme, something like "Why? Because it's fun"
generating types from a swagger spec? Graphql? Or any kind of schema? Look up fsharp type providers.
It's more of an experiment of thoughts to generate types that are defined by the result of the SQL query, bending a compiler to a new strange behaviour that happens to be SQL like.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#179I had no idea you could compose string literal types AND infer variables using interpolation syntax in the context of conditional types. I am salivating at the potential use cases for this...
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#180Earlier quoted context omitted.
I'm glad you asked. :-) For a start, number types. I want i32, i64, u32 etc. JavaScript (and therefore TypeScript) only has "number". Yes we now finally have BigInt but it's not ideal for JIT optimisation. Object prototypes is a weird part of JS that we really could do without. If you really want that, use class syntax. The Date object. Need I say more... Little things like Object.keys() should return a (keyof T)[] r…
For new code, I think most JS devs have already switched to using the class syntax. Also FP in JS is alive and well if you want to avoid dealing with prototype chains altogether. I think we can all agree the Date API sucks, but life can still be good if you just give in and include a date library. Also, there's some light at the end of the tunnel with Temporal proposal coming along [1]. Object.keys returning string[]…
Basically AssemblyScript try to fix JS runtime as well. See this: https://twitter.com/AssemblyScript/status/114604718874680934... and https://twitter.com/AssemblyScript/status/114466636945316659...