Hacker News new | past | comments | ask | show | jobs | submit | brochington's comments login

From the rhai Engine docs: `Currently, Engine is neither Send nor Sync. Use the sync feature to make it Send + Sync.`


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.


Not special. I couldn’t have said it better myself.

I often reach for Rust when Python could do, but it’s a bit bigger than a one page of code program. I also forget I’ve been doing Rust nearly full time since late 2015. And before that 15 years of C and understanding memory, etc. Maybe we’re just a rare breed.


Location: Los Angeles, CA

Remote: Yes, or in person in the LA area

Willing to relocate: No

Technologies: Rust, Javascript/Typescript, React + ecosystem, Node, Postgres, AWS, so much more...

Résumé/CV: https://drive.google.com/file/d/1gGHpw-YKAdGRUHlnPIpeozMIvIF...

Email: brochington@gmail.com

---

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.

Github: https://github.com/brochington

LinkedIn: https://www.linkedin.com/in/broch-stilley-9481789/


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.

0: https://brochington.github.io/ecstatic-doc-site/docs/example...


Fundamentally, UI is nested. The framework has to reflect this and make UI components composable in a bested way or you’ll drive developers crazy.

What I do wonder about is being able to use a data oriented system that does reflect this neat ability. E.g. if the data in an ECS system is viewed as a simplified relational database, what would happen if we replaced it with a simplified graph database?


Isn't a graph of objects a simplified graph database?

Trees are not arbitrary graphs; a tree-based database may have nicer propertied than a web of objects, while allowing to describe nesting in a natural way.


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.


As they say, naming things is one of the two hardest problems in Computer Science :)

Your project is cool and has a cool name!


Haha, thank you, and yours has a great name too!

Both our projects are ML-adjacent. I don't want to cause any confusion, and will start thinking of some alternate names for my project.


Independently of the name collision, your Show HN looks good! and didn't get any attention. If you email me at hn@ycombinator.com, I'll send you a repost invite for it.


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?


I'm thinking of applescript in particular, but voice assistants in abstract.

Applescript is sold as a natural english like language, but it's really not. At least it's well documented.

Voice assistants are more like your product. Ask it a question, get something. But you have to ask them to do things in very particular ways or you don't get what you want. And there's usually zero documentation.

As an interface to SQL, your product is going to have to let me specify pretty specific relations, and that's going to take pretty specific words, IMHO. Think about how a user would ask for an inner join vs a left join vs a cross join.

Some ORMs have a pretty similar issue, where you learn an entirely different way to formulate queries, that ultimately get turned into SQL, but I'd rather work to understand SQL than to understand an abstraction over SQL (unless it gives a singificant benefit).


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.


I wonder, does it help if the user understands which relationships are 1-to-N and which are N-to-N. In order to state commands fairly clearly, and respond to requests from the system for clarification and disambiguation. I would think that this kind of info (1-to-N, N-to-N) could be grokked in a straightforward way by a user with domain knowledge.


Not yet specifically for this; It is an excellent point.

If I may, was there any particular phrases that you remember that were "too much"?

It would be great to talk more about your experience, if you are open. Just let me know and I can DM you.


Given that I was not in the group, I can't provide any great detail. It sounded like people entered extremely vague sentence fragments.


Ah, copy that. Not enough input is, well, not enough. Appreciate the clarification.


The Symantec link is fascinating, thank you for that!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: