jeremychone

I would differ that Rust would not be a better choice than Rust.

Seeing Rust as a system programming language only is missing the bigger picture (IMO).

Well, we are doing just that, building a new venture with Rust because we think it is transformative in our field. Will post our findings in a year or so.

It might be good to decouple the work coding environment vs. the coding activity itself.

Secure the income stream by doing what is expected of you, and use your personal creativity on side projects with a potentially new language (e.g., Rust, ...)

On a personal note, the older I get, the more I code, so it was those work environments that made me doubt.

That is a very good way to look at it.

Now, I am not a C++ dev, but how much effort would it be for a team to pick up C++ 20 if they only had worked with was C++ 11?

I think Axum has the potential to be the top web framework. Not too high, not too low, very well designed and complete, and well maintained with healthy momentum. It has become our web framework for web services and web app backend.

Not sure we will ever see a "rails" like framework in Rust (for the better IMO)

I recommend Axum.

1) Not too high, not too low.

2) Very well componentized (e.g., Tower for middleware)

3) Very well modelized and complete (e.g., middleware, extractor, req/res extension, fallback, req/res mappers, simple and flexible response/error scheme)

4) Part of the Tokio umbrella.

5) Great user momentum and well-maintained.

A little more explicit than the "Rust’s Ugly Syntax"

That is a nice blog post. We have moved from Warp to Axum as well. It's not too high, not too low, and very well componentized. Also, it has good momentum, and its commits "cadence" looks healthy so far.

The "rewrite-it in Rust" is not for all projects, obviously, but for some, it might be a smart move. Time will tell.

It's interesting. The same post was on the Rust Reddit a few days ago, and almost everybody got the point of the article, which is the opposite of what we could infer from the title alone. Many have a good laugh as well.

But somehow, on HN, the article seems to have been taken literally with long threads about "::" v.s. "." and how < > are bad for generics.

Physics over optics, not everything is about cosmetics.

I had the same initial opinion about the '.' Vs. ':' for module separation. Why add weight to make this distinction?

However, after over a year of coding Rust every day, I now really appreciate the distinction. It's an effective way to give a meaningful context point at a very low cost.

I was wrong again! Which has been a consistent pattern with my initial Rust appreciations.

Code aesthetic appreciation is a temporal matter. Something that looks ugly initially might feel natural and sound later. This happened a lot to me while learning Rust.

Rust has to be learned, true, but once the initial learning phase is done, those syntaxes start making sense and become part of the value rather than the cost.

I would recommend putting personal aesthetic preferences aside while learning and reassessing them later.

Also, I hope the article's point was not lost. It took me too long to get it, but I am glad I did before I wrote my first comment on Reddit a few days ago.

Coding in Rust is definitely addicting.

Here is a bevy video tutorial I did: https://youtu.be/j7qHwb7geIM

Source on GitHub.

Been using recut and it is amazing. The fact that this was rewritten in Rust and Tauri is impressive, and I think a very smart move. Once you know Rust, you tend (at least I do) to be very productive. Looking forward to new recut features.

That’s the point of Tauri. UI is html/css/js, and the backend logic is Rust.

Yes, and as you can see, things are not that trivial.

At the high level, you can approach it in two ways.

- WebView to localhost would be the first solution but is inherently not secure (or needs lot of work to make it so, and still)

- Another way is that the app container that bootstrap the webview have a scheme to serialize/deserialize JSON message between the JS environment and the app container (in rust in this case). And that is what Tauri nailed down.

In fact, Tauri also supports localhost, in prod and dev. And where it becomes insanely good is that for dev, you can use localhost and use something like servor to have hot reload when you can UI code, and when its time to pack your app for distribution, it bundles those html assets part of the binary.

Anyway, some Rust marvels are out there, and this is one of them.

(btw, this is for desktop applications, not browser extensions)

What do you mean "native messaging API?"

Tauri offers a very elegant, secure, and effective way for the WebView JS environment to communicate with the Rust backend. It's not a trivial task to do this effectively and securely, let alone with something ergonomically pleasing.

Anyway, what "native messaging API" are you referring to? Perhaps they missed something obvious, but I found that unlikely.

Tauri is very well designed, from an app model to its component parts (wry, tao). In short, it’s a platform that allows writing Rust as the backend and use of the OS webview. So light and fast.

I think and hope that many new desktop apps, even from the new big player, will be done in Tauri. I plan to use it for some of our future apps.

I know mobile is a whole other beast, but I hope Tauri can also crack this one up. That would be amazing.

Tauri rocks!

I think you have a good point, Rust might be too much for them (at least for now).

I am not a Go developer, I just looked at it from afar, but I understand that the GoRoutine was the cornerstone of high concurrency performance.

In Rust, you have the async/await/future model. You can combine with MPSC (multiple producer single consumer) to have similar message-passing patterns or use traditional Mutex to access shared data. Although the async/await was not designed from the start, the Rust ecosystem has embraced this new concurrency model, which works very well. Tokio seems to be the major future executor crate available that most libraries gravitate around.

So, at zero cost abstraction, all of that allows taking advantage of NIO OS capabilities fully, with extremely efficient async/await/future design choice and implementations (there are some good reading out there about the design decision).

For example, I made a quick video on how to do a "blocking" Redis Stream Read over NIO, which shows concurrency with one thread.

Rust to Redis with Async/Await - https://youtu.be/uD5hBVHwyDM

cool stuff. I need to learn Solana one of these days. Still confused with the whole thing.

Here are some random points, but you have more context at the end, so make the decision that fells right to you.

- I heard a lot of npm dependencies nightmare, but somehow, we do not hit that much. Once in a while (a couple of months at most), we get some weird errors, delete node_modules, and are back at it. IMO, TypeScript is a must for any code > 10K LOC (and I use it even with 100 LOC).

- NodeJS/TS's benefit is that it is the same language for the backend and frontend, allowing students to focus on the patterns rather than learning another language.

- However, I love Rust, and I think it is an excellent fit for cloud/web backend. We are moving our NodeJS/TS backend services (web service & job service) to Rust, at least for new ones. Still working on the blueprint, it is quite an effort, and the big question is how long it takes for a whole team to learn Rust well.

- If the university understands the pros/cons of Rust and want to "invest" in it, it might be a good idea to have a Rust backend. However, if they have no clue what it is, it might be too early for them.

- IMO, Rust will become more mainstream in the years to come, especially for backend services. It might take 5 to 10 years, but I hope and think it will get there.

Those are not recommendations, just thoughts, as this is a very contextual decision.

Best of luck, I am sure you will do well, you seem to have all of the right questions.

I would say definitely yes. While Rust asks the developer to worry about things they don't in other "memory managed" languages, its ergonomic and expressiveness add to the productivity. Once you get used to Rust, it becomes a net positive from a productivity side; at least this has been our experience, and you get a much more efficient and robust codebase.

However, here are the following caveats: - If you have a client or employer project to do now, and you are not yet familiar with Rust, do it with your language of expertise. Rust has to be learned before starting a new real project with it. - The real challenge is the cost to train an entire team on it. - Obviously, universal languages do not exist, so if you do AI, especially modeling, use Python (for now), web stuff use JS/TS, mobile stuff, Kotlin | Swift | Dart/Flutter. You can do some Rust on mobile and even web with WASM, but those are very niche use cases.

Actually, once you get used to Rust, what you “loose” on one side of the productivity (ownership/lifetime/dispatch) you gain on the other side with the ergonomics (enum, matches, expression, …). So our experience, is that at the end, you still a net positive on the productivity side plus the other benefits.

We started to rewrite some of our smaller js/TS utilities, ~3k LOC, and surprisingly Rust was 10% to 20% smaller. Not that it a relevant metric, but still, we were expecting the opposite.

The missing part compared to other languages is specialization, but other patterns can be used. Still, would be nice if they add a good sound specialization construct (min_specialization seems to come short so far)

The biggest challenge is to train a full team on Rust.

I thought they rejected them because electron used private apis. Is that resolved?

Looks interesting but difficult to get the details from just the slides.

Also, not sure why Azure Arc still gets mentioned. I would have expected something more cloud independent.

Our approach, for now, is to use Kubernetes Postgres for dev, test, and even stage, but cloud Postgres for prod. We have one db.yaml that in production just become an endpoint so that all of the services do not even have to know if it is an internal or external Postgres.

Another interesting use of Kubernetes Postgres would be for some transient but bigger than memory store that needs to be queryable for a certain amount of time. It's probably a very niche use-case, but the deployment could be dramatically more straightforward since HA is not performance bound.

My guess, and I hope I am wrong, is that it might be a world of pain for backend/cloud developers.

Virtualization gives us Linux ARM docker images, which is nice, but not the same as running the same Linux docker images that run on the cloud. (while ARM in the cloud can be an option, it is a whole different topic)

The developers will have to find and develop with the ARM equivalent docker image of their production x86 ones, which will make the local dev and production environment unnecessarily more distant.

The good news is that the Docker ecosystem has a relatively broad ARM architecture support, but still, this will be a significant difference with prod environments.

First, the use of 'innerHTML' is just for the sake of examples and mvdom does not promote one way or another.

Now on the broader discussion between innerHTML vs appendChild (with or without DocumentFragment). There is no real security issue between using one way or the other, as both get processed by the browser anyway.

The issue was more around performance. innerHTML used to be considered a bad pattern because developers did it in for loops on elements attached to the DOM which unnecessarily added a lot of work on the rendering. However, doing repeating appendChild on a document DOM element will create extra browser work as well.

The key is to that to minimize DOM change of elements that are attached to the document, regardless if it is with appendChild or innerHTML. We found that proper use of innerHTML also can dramatically simplify code with no drawbacks. If you need to do some work on the DOM element before adding it to the document, then you can create a DocumentFragment (still with innerHTML) and then work on the DOM element outside of the document before adding the DocumentFragment to the appropriate document element. As we can see, the issue was not to use or not to use innerHTML but rather when to add a blob of content to the document.

Now mvdom is template agnostic, so, one can even use some templating engine like lit-html and get the same benefits than react rendering but without the overhead (i.e., render/re-render black magic)

Note: While innerHTML should be demystified, .innerText should be avoided at all cost, and .textContent should be used.

First, no language is perfect, and building a real system with growing team(s) is always about making purity vs pragmatism tradeoffs with the main goal of keeping the complexity down as the system scale. The truth is that a system is much more than just the languages it is composed of, and regardless of the purity, exactitude, elegance of a language, sloppy work will always lead to a messy result.

In other words, languages should not be used as a substitute for discipline, good patterns, or scalable best practices, but rather as an enabler of such conducts.

TypeScript favored pragmatism over purity, but it is a very well thought-out, robust, and expressive typing layer on top of JavaScript.

Sure, for the sake of language purity, developers can "bytecode your way" to JavaScript Dart, Java with GWT, ReasonML, Elm, but there is a reason why all of those options, how elegant they might be, have limited traction and relatively short lifespan (at least compared to JS), and that is because they add too much friction points (often unexpected ones) for the sake of language purity, which at the end is a never-ending quest anyway.

TypeScript is a structural typing system which has its differences with commonly known nominal typing systems (which often confused with soundness), and while there are some unsoundness is some specific cases, overall, TypeScript is a very robust and expressive typing system on top of the most pervasive language, JavaScript. Not perfect, but very robust nevertheless and a huge step up from traditional JS. TypeScript combined Modern JS (module, let/const, async/await/promise, arrow function with related scoping, deconstruction, ...) does create a very robust environment to scale code and developers.

We used to all our backend in Java for 20 years (personally comes from Oracle) and we now see nodejs / typescript ecosystem and runtime environment has competitive for big app system. For one of our client, we actually just ported the last of our multi-service system from java to TypeScript, and it got 40% less code and it is better typed than Java. Java's high typing friction and Class-For-Everything purist approach makes good code design more of a contortionism exercise than an intellectual one, and while nowadays most agree that this OO-Obsessed approach was the wrong one, it was considered very pure and "robust" at a time.

Anyway, the short version is what makes a big code base scale is not the purity of any given part (e.g., language) but how the whole can minimize present and future friction points. The less friction, the more velocity. Discipline, best practices, tools, environments, and ecosystem are all part of a whole and one needs to make sure to not over optimize one part on the detriment of the others.