Over the past 2 years I've been writing Rust services for my own startup. Some were straightforward CRUD, some advanced language parsing and ML services. Some thoughts:
- Rust tends to push you to make good decisions. In my case, one of these good decisions was to ditch an ORM (which has always slowed me down) and instead write Postgres queries directly via SQLx. The compile time checks against an actual DB helped my speed dramatically
- Free performance can be a really big help when you are trying to figure out an API or algorithm. It's really helpful to know that my unoptimized code won't tank the server, and also helps me save costs on the cloud.
- "It doesn't compile, or it doesn't break" is kinda a mantra for Rust, and really helps me focus on problems at hand, instead of hunting down bugs.
> You will have a hard time hiring Rust developers.
I've found that there is a drastic difference between hiring devs willing to learn Rust, and devs that want to work with you because you are using Rust. The bar of those devs that seek out a Rust position tends to be very high.
> We made a huge mistake early on by adopting Actix as the web framework for our service...(To be fair, this was a few years ago and maybe things have improved by now.)
Actix-web has gone through some version-churn, but it's never been "buggy" in my experience. The experience multiple years ago is vastly different than today, but even my older services written years ago with Actix-web are still running fine.
> Libraries and documentation are immature.
Perhaps in years past, but I've always found the docs for Rust and its libraries to be very good. Folks write entire books on elements of Rust, and the standardization of the display of crate docs keeps things consistent.
> Rust makes roughing out new features very hard.
The "json!" macro can come in handy here. Also Github Copilot is a godsend for this.
> What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again.
Hours? These type of corrections are spoonfed to you via errors at compile, or via the IDE. I've never had to spend hours on this. Everyone of these changes could be a bug, and having a typesafe language is a huge help here.
I recognize I might be in the minority, but I've really enjoyed using Rust for services for my startup. It's helped me move fast, but maybe I'm a special case. I'm curious to hear other's experiences.
Senior/Staff Frontend/Fullstack engineer with a decade of experience working for both startups as well as large corporations.
I enjoy working on complex UI applications, such as in browser PDF rendering engines, and intricate dashboards. I also very much enjoy working with other engineers in a leadership role, and helping to mentor and grow teams.
I've been fortunate enough to have written Rust professionally for the past three years both in the frontend (via Wasm), and backend. This is by no means a hard requirement though, as I'm also very comfortable with Javascript/Typescript, React, Node, Postgres, AWS, and many other technologies.
I would love to see some exploration of the ECS pattern being used for web development. A couple years ago I wrote an experiment[0] using ECS with Web Components to make a simple calculator, and... it was actually pretty nice. ECS does a great job of flattening nested structures, and would be really curious if this would improve things like prop drilling in React.
Just a note to say that even though the name "Sematic" is the same, this is not the same open source project as mine that I posted to Show HN about a week ago here: https://news.ycombinator.com/item?id=32364193.
Ah, sorry, I should clarify that when I say "talk", I didn't mean it in the literal sense. I've only worked on text as a source, though Speech-to-text shouldn't be too hard to integrate if it was needed.
I like your insight about using... let's call them "key phrases"...to help guide the query. Perhaps having a way to map a key phrase with a specific query, maybe one that is parameterized, would be useful. thank you.
> Having used various things that claim to be natural language, I find that to use them effectively, I end up needing to learn their particular structured language.
This makes sense. Are there any specific examples of products that you have used that you had to do this?
> ...selecting lists with plural nouns and individual records with singular nouns...
Yes, this is for sure a failure case. I believe I have some means to work around this, fwiw.
> if I'm going to learn a structured language anyway, I would usually prefer to learn the underlying language, and not an imperfect abstraction.
I feel like I get what you are saying here, but some more concrete examples would help. Is there a "structured language" you are referring to?
English->SQL is very much a thing, and has a good amount of research going into it. It does have a few weaknesses though:
1. It is ML based, and the best results I have seen put it at about 90% accurate. This might be "good enough", but not perfect. Verification and error correction is needed.
2. Knowledge of the schema needs to be passed in as part of the feature, or have the model explicitly trained to the target schema.
3. Going to a different DB requires a retraining of the model, due to slight differences in SQL dialects.
4. ML takes either a lot of time (speed) or money (GPUs). This is more a general ML problem, but does affect English -> SQL.
I am no expert in English -> SQL, or in ML in general, so somebody correct me if I'm wrong on the above points. These are just what I've seen or experienced in my research.
Ah, yes, Maybe I should clarify who my intended user would be. I agree that if you are technical, you are probably better off using other query methods. I'm always surprised what folks are on here, so was hoping a few would find this question.
> There might be a lot of people here who have, say, that upper-level manager who keeps asking for reports for which the HN person has to figure out how to get the data.
This is 100% the use case I was thinking.
> One caveat, though: I wouldn't want to hand anyone - even a professional - write access with this kind of a tool.
Agree! Not sure how this ever would be safe enough for edits.
> That comment doesn't make a ton of sense to me. Are services not valuable? Stripe and Twilio seem like really helpful services and that seems...OK to me?
Services are totally valuable! I think with Stripe and Twilio they both solve a problem a Business/PM/Owner has. The conversations go something like this in my head:
PM: I want to be able to send SMS messages to my customers.
Dev: Uh, I don't know anything about telecom...
Twilio: I do! I'm way cheaper than a dev working this problem. Just use me.
For NLU, I'm not sure I've been able to find PMs that are wanting to "understand the plain english of our users". But I know there is a decent amount of NLP usage. Do PM's just not know that they can ask for these NLP? Or do they just not need it? I'm not sure. I feel a little bit like I'm missing a piece of the puzzle.
> Personally I get excited when I hear about an ease-of-use wrapper around regex. But for a DB, in place of that regular messy query stuff with the prospect of things like multiple LEFT JOINS? That's a big deal.
A regex wrapper is an interesting idea. Maybe I'll try it out. I agree that a text to db wrapper could be a good idea, if it works really well.
> The average person's energy pool for trying different sentences, even considering some expected failure rate, is so much deeper than the resources available for trying and failing with different SQL statements.
Great point!
> It sounds really cool. Good luck, hope it works out for you.
1990's huh, wow. I totally believe it. It almost feels like a solved problem, but when I tried to find an API that parsed text to a degree that was usable by an average dev, nothing came up. Many NLP/AI/ML tools could define the entities, or VERY general relationships, but never went far enough. I'm curious if the 90's solutions used ML, or if they went straight to text analysis (which is what I'm using).
> Ultimately though, I think the usefulness of these tools breaks down for both complex queries and even simple ones when the data model does not have explicit relationships defined.
Makes sense. Do you think it would help if a developer could define the relationships in the data model ahead of time?
> Trying to map english to formal logic is a fools errand.
I don't disagree, but this would not be a 1-1 mapping, if that matters.
>From my experience, what keeps non-technical people from writing queries isn't SQL, it's stuff like joins.
I've met very few non-technical folks willing to brave learning any part of SQL. In my case joins would be an implementation detail, mostly handled by the product, but possibly with an escape hatch for technical folks.