Live data from Hacker News

Show HN: A SQL database implemented purely in TypeScript type annotations

github.com

171–180 of 196 posts

Re: Show HN: A SQL database implemented purely in TypeScript type annotations

#171
post #57
post #56

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?)

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

Re: Show HN: A SQL database implemented purely in TypeScript type annotations

#172

I’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)

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 do?

Re: Show HN: A SQL database implemented purely in TypeScript type annotations

#174

JavaScript 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 think these are two different languages for two different jobs.

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

#175
post #56

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

Just want to add that the genType project can even compile ReScript to Typescript!

don't get your hope too high it's just the intersection between the two, advanced typescript types are lost.

Re: Show HN: A SQL database implemented purely in TypeScript type annotations

#176

Earlier 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…

I think they implemented a generic nested language framework (whose real name eludes me).

Re: Show HN: A SQL database implemented purely in TypeScript type annotations

#177

This 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!

From ts conf talks, only a minority of people actually write most of the complex types. Those are mainly library authors and such, I presume.

https://youtu.be/jmPZztKIFf4 at 49:50.

Re: Show HN: A SQL database implemented purely in TypeScript type annotations

#178
post #169

Earlier 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.

As far as I understand (and I might be wrong so please correct me), this can't be used to generate anything. Of course all the technologies you've listed are useful and brilliant but this isn't what I'm seeing.

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

#179
post #10

I 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...

Typescript was created to bring static types in dynamic language, like JS. Now they made the static types more dynamic. What's next?)

Re: Show HN: A SQL database implemented purely in TypeScript type annotations

#180
post #52
post #32

Earlier 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[]…

> I don't think AssemblyScript will be the answer for you, as the goals of that language seem to be entirely different from "fixing" old JS cruft. Apart from the i32, i64 stuff I guess.

Basically AssemblyScript try to fix JS runtime as well. See this: https://twitter.com/AssemblyScript/status/114604718874680934... and https://twitter.com/AssemblyScript/status/114466636945316659...

Post reply on HN