If you're a hobbyist, yeah, you should heavily value "ease of learning." If you're a professional, the learning curve is worth it if the tool's every day leverage is very high once you're ramped up. Too many developers don't put those 3-4 months in, in part due to the over-emphasis on "ease of learning" in our discussions/evaluations of things.

I was a part of a very large go project (https://news.ycombinator.com/item?id=11282948) and go-based company infra generally some years ago, and go is emblematic of the classic tool that is amazing at ease of learning, and quite mediocre at "ease of use" as time goes on.

I personally end up resenting those tools because I feel tricked or condescended to. (This is a little silly, but emotions are silly.)

I'd wager this is also why Rust is a perennial "most loved" winner in the surveys: it gets better as your relationship with it deepens, and it keeps its promises. Developers highly value integrity over trickery, and hard-earned but deep value feels like integrity and wins in the long run. (other examples: VIM, *nix, git)

Comments URL: https://news.ycombinator.com/item?id=41230396

Points: 58

# Comments: 13

Plug notice: this is my company.

SiteGuide (https://siteguide.ai/) was the first to do vector embeddings with Convex, built by integrating Convex + Pinecone. This combination has been an increasingly common pattern over the last few months. So we put a template project to demonstrate how this is usually done:

https://github.com/ianmacartney/embeddings-in-convex

We're strongly considering building in vector search a little further down the road, but this is the recommended approach for now.

Fair enough. The goal of the post wasn't necessarily to comprehensively describe the product–so the specifics of what we provide are found elsewhere in our docs, etc.

> Really, the big thing that I see here is the transaction retry logic,

These transactions run as embedded functions inside Convex in a runtime where it is impossible to have side effects.

Agree this is a necessary part of the change. Convex is working on our OSS strategy this year. Thanks for the feedback!

It's not new "in the world", but often new to our users, who understand it less intuitively than pessimistic locking.

Unless they're using Haskell or probably other very exotic environments with strict understanding of mutability and so on, they know Mutexes but not STM or other OCC patterns. So we lean heavily on explaining it. Not because it is original, but because it is unfamiliar.

Haskell: IO -> STM -> (pure)

Convex: (The browser / Convex Actions / other effectful environments) -> Mutations -> queries

All the same benefits re: retry and memoization.

Steal steal from Haskell, so many great ideas there.

SQL is the C ABI of querying for sure. BI tools will never adapt to use Convex directly, and nor should they.

So... yes, Convex actually had a prototype SQL adapter for the read side of things back in the early few months when we were figuring things out. Convex's read semantics are very compatible with SQL.

We've kept this adapter on ice in part because of point #3 in the article -- we don't want to overpromise things which are a bad idea.

Meaning, if we exposed SQL on the thing as-is, this would presumably be for more analytical type queries involving patterns normal Convex queries can't express. Right now that would be a Bad Idea because your website would slow down just like every other database system allows you to.

So the current recommended practice is use our Airbyte Egress connector (https://airbyte.com/connectors/convex) and get yourself into an offline Clickhouse/MySQL/Snowflake whatever and jam SQL over there to your heart's content. That's basically what we do.

We may one day abstract this away by embedding some sort of mirrored column store sql thing (maybe DuckDB based? who knows) so you can do your analytical work without impact on your OLTP or integrating 3 more systems. But the team hasn't invested in that yet and probably won't for some time.

But no, not necessarily exclusively TypeScript. For example, the existence of the Python client library is due to developer demand. Some users had ML jobs that are triggered by Convex applications or reported outcomes into Convex.

The embedded functions are always TypeScript. The experience is pretty smooth in other languages as well-but the degree of this is largely dependent on how easily the type systems map from e.g. Python to TypeScript and how our client library can infer things in a way that feels native or requires little of your involvement.

> It may actually be fine to just require everything to be typescript, but the idea that you'd require your application be written in the same language as your data store, and thus implement a different data store for each language you might want to write an app in (and not share between languages)... would formerly be thought of as pretty ridiculous?

The vision is definitely aspirational, and is reflecting on the fact that JS/TS is becoming overwhelmingly the most popular language for projects. With things like React Native, for many teams even mobile apps are taken care of all on one language.

There will obviously always be apps written in other languages, and in those cases, a bit more type mapping will be necessary, because (for now) Convex functions are always side-effect free, automatically cached JS/TS running in a very particular runtime. But we'll work on making that translation as smooth as possible in our client libraries.

We have a Python client library out now ( https://pypi.org/project/convex/ ) and a Rust one coming soon, just to keep us honest in this respect.

> I guess we'll see if Convex can get popular enough to spawn lots of "what I wish I knew about convex a year ago" and "Goodbye Convex, hello Postgresql" posts...

Well, that's the dream, isn't it?

Another interesting bit of work in this space is LINQ on the microsoft side of things. And even list comprehensions end up having a scanning/summing language kind of feel to them that would be interesting to see translated into a new database query language.

At 8:30p: Last big glass of water. Put phone on charger in non-bedroom and don’t touch until 7a. Keep the lights low and warm. Do low stimulation activities like reading fiction or watching semi-boring TV or chatting with your family. Lay down when you can’t keep your eyes open anymore.

Big change for me. The phone especially is poison for evening tranquillity.

Hi Shawn. I don't remember you bringing this up when we spoke in person recently, but it's a great question.

In our opinion, the very best way to evaluate yourself as a backend developer is how directly you solve problems for frontend developers. We believe in the merit of customer obsession, and the customers are not buying queues. They're buying the product as they see it: its surfaces, workflows and experience. And that's what the frontend developers, PMs, and designers are creating.

Historically, all these backend technologies that only interoperate with each other are only useful so long as they make product creation and improvement easier, more reliable, etc. We strongly believe as soon as you don't need them anymore, you should toss them out. They're complex and not proprietary to your product.

Convex (and serverless in general) is just the next step in providing more powerful abstractions that allow companies to double down on frontend engineering (work that adds product value) instead of reimplementing the same backend/devops plumbing the users never see (work that, at best, merely sustain product value).

So, given that we recognize this need, I respectfully disagree that we're not well equipped to solve these problems for frontend developers! Most of our team's recent our work has been designing synchronization and storage platforms to enable product development, including work on web, desktop, and mobile libraries/SDKs. We feel like we have both a lot of empathy and experience for this space, and we're very proud of our early product and the enthusiasm from the web dev community.

Convex is a rapidly growing startup aiming to change the way the web is built. Specifically, we're creating a Global State Management platform--a new way to build apps without backends, databases, VPCs, kubernetes, etc.

Featured recently here: https://www.forbes.com/sites/kenrickcai/2022/04/27/convex-se...

More background on the vision: https://a16z.com/2022/04/27/investing-in-convex/ https://blog.convex.dev/unfulfilled-functional-ideals/

We're looking for people passionate about developer platforms, web development, mobile development, distributed systems and databases--all the pieces necessary to create a holistic replacement for the backends of years past.

Our stack is TypeScript + Rust. The Convex team has been building critical systems in Rust for nearly 10 years:

https://www.wired.com/2016/03/epic-story-dropboxs-exodus-ama... https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...

...so if you're passionate about learning in depth how to take Rust into production, join up!

Feel free to either reply to me or apply directly on https://convex.dev/jobs

Or, if you just want a beta key to learn more about what Convex is first, let me know. I'll hand those out too.