schultzer

I was looking at the wrong thing when I searched, this came up: querybrew dot com.

Thank you for clarifying, sounds a lot better then my initial impression!

It’s not clear from the paper or their website how it works, the paper seams to talk about an optimizer where the websites states its AI maybe this is just slop. Hard to determine when skimming it, although seams like a neat idea if it’s a proper engine and not just AI that anyone could copy and paste into a chat with the statistics.

We can do way better then LINQ in an extendable language.

I don’t understand why no one is making SQL a first class citizen in a language, there are tons of languages out there that are extendable, how hard can it be, enough of DSL and generated type-safe application code which is a DSL in reverse order.

Sure, but that is rarely the biggest issues facing a client: top contenders are always queue, pool and decoding. And obviously lack of SQL being a first class in most languages.

While it’s important to focus on the backend itself, why don’t anyone focus on the clients which talk to the databases, it is there most of an applications problem starts also in regards to performance.

What we really need is an atomic_term :)

SQL is great, but what is even better is a SOTA client. https://github.com/elixir-dbvisor/sql the BEAM can give you superpowers that no other platform can, handle massive concurrency with the performance that rivals bare metal and c https://erlangforums.com/t/elixir-dbvisor-sql-needs-a-sota-p...

Couldn’t agree more, I was taking a diplomatic approach as I was linking to my own work!

A lot of people tend to flag Elixir for its size and rightfully so, but the community is trying to punch above it’s weight with SOTA libraries. As an old developer once told me: less is more. https://github.com/elixir-dbvisor/sql

Great to see this, Denmark would do well having an autonomous regiment in the Navy, Airforce and Army.

I disagree, it’s wonderful for writing compilers in as well https://github.com/elixir-dbvisor/sql I would go so far as to say superior to a lot of other languages that do not have advanced pattern matching.

If your language has macros you can get by as well https://github.com/elixir-dbvisor/sql

You can google SQL grammar. But here is the 2025: https://standards.iso.org/iso-iec/9075/-2/ed-6/en/

Just took a quick look, and it seams like the parser is hand written which is great, but you probably want to build a lexer and parser based on the BNF grammar take a look at how I do it here https://github.com/elixir-dbvisor/sql/tree/main/lib and do conformance testing with https://github.com/elliotchance/sqltest

Not really sure what a t string is or if it’s a macro, but feel similar to https://github.com/elixir-dbvisor/sql but less elegant and ergonomic.

Low latency is addictive. And by the time when you think you might need to change you’re probably become such a skilled engineer that you realize that everybody that shit on mnesia does not know what they talk about. :)

mnesia is great, and you can get very far before you would make the jump to anything else. And it can be way faster then any other database. For obvious reasons.

Although it would be great if it spoke SQL, maybe one day it will: https://github.com/elixir-dbvisor/sql since we can already pass it and get the AST.

Elixir compiler is written in Erlang, Erlang can produce very efficient code, the new json library can beat c libraries at decoding / encoding. And you get this with a strongly typed dynamic language, which is a distributed language. It’s really hard to beat the BEAM, if only we had better number crunching, but in so cases you can always write a nif.

One thing that is great about Erlang’s pattern matching is that it makes it extremely approachable for writing, lexer, parser and compilers in it: https://github.com/elixir-dbvisor/sql and with Elixir macros and sigils then you can embed other languages like sql and zig to name a few!

When I first started working in Elixir I loved Ecto and the pipe syntax, but now I want a SQL sigil, that wont care about where I put my where or from clauses.

Why are SQL parsers even concerned with that? Isn’t that why we have RD parser.

What people seam to forget is, that SOC is the future, and an upgrade should be as simple as switching one chip. This also comes with a lot of benefit with locality and performance.

This is interesting, I did write BLAS in Rust https://github.com/schultzer/libblas it's only single threaded at the moment.

I feel people forget to ask a more important question before they start a full rewrite and that is: Where is the hardware trends going and, is dedicated GPU, CUDA etc. even the future.

I feel it would be wasteful to spend a lot of time writing GPU specific code, Its not really maintainable on these scientific project (where only a select few people contribute, usually people that do the research).

Location: Tijuana, Mexico (EU Citizen)

Remote: Yes

Willing to relocate: Yes

Technologies: Elixir/Erlang | Rust | Fortran | JavaScript/TypeScript | Ruby/Rails | Swift | HTML/CSS | MySql/Postgres/MongoDB | Phoenix (Elixir) | VueJS (Javascript) | Webpack | OpenCV | Tesseract | Electron (Javascript) | Ansible (build/deploy/provision) | Docker | BLAS | webRTC | Cloud server/virtual machines (DigitalOcean) | Continous Integration (CircleCI/Travis/Appveyor/Gitlab) | OAuth2 (authorization) | OZ (authentication and authorization) | iOS (Swift)

Résumé/CV: on request

Email: benjamin at schultzer.com

Github: https://github.com/schultzer