> .NET had a feature where you could essentially code as if you were writing a form application in C# and it would compile to a web form and wire up JavaScript, HTML and CSS so you never had to learn anything about web technologies.
This is likely referring to ASP .NET Web Forms. While this is theoretically true the reality was more nuanced; you had to know HTML/CSS in order to style your applications and you had to know a wee bit of jQuery to make things happen on the page when you didn't want to trigger a "postback" (their proprietary term for a POST request laden with the requisite ViewState and session magic). The _real_ magic of ASP .NET was implicit state management... you didn't have to know anything about sessions, cookies, HTTP, CSRF, or LocalStorage (which, sadly, was around for some of Web Forms's heyday because many devs clung onto it for much longer than they should have). The whole point of Web Forms was to replicate the WinForms experience in a web context so that devs didn't have to reason so much about client vs server state. Everything was rendered server-side and state was retained via a combination of session and the aforementioned "ViewState", which was basically a massive encrypted form field with the application state that got submitted with every request.
It could probably be argued that Web Forms doesn't even really qualify as web development. I've weaned developers off of WebForms and for most of them it was their first exposure to basic tenets of web development like HTTP verbs (let alone RESTfulness), JSON, vanilla Javascript, sessions, and actual honest-to-God state management.
> .NET had a feature where you could essentially code as if you were writing a form application in C# and it would compile to a web form and wire up JavaScript, HTML and CSS so you never had to learn anything about web technologies.
If memory serves vanilla JSPs were largely stateless but JSF was pretty much the Java version of Web Forms. Obviously it being JVM it required a lot more bootstrapping since it was less opinionated/OSS but the effect was largely identical.
Very true. I did Webforms for a while. It was fine but once I needed things like Ajax things got pretty convoluted. There were callback panels and stuff. Things were super complex and I spent a lot of time fighting the framework. Then I learned about jquery and saw how simple Ajax calls really are. Same for a lot of other things: the Webforms abstractions made things more complex than they really are. And you don’t learn how things really work.
Since then I am very wary of frameworks that provide a lot of abstractions. Easy to get into but after a while there is a risk spending more energy fighting the framework than you would have spent learning the native way.
Happened in my company with Xamarin. Looked good for C# but after a few months everything got scrapped and the devs went native.
>The advantage is that [learning Rust] automatically filters, uh…, script kiddies
>So if you want to hire someone to write Rust for you, it’s pretty safe.
I'd be really sceptical of hiring someone who refers to other developers as "script kiddies". Rust has been getting a lot (well deserved) attention but I hope people aren't learning Rust as a status symbol.
> but I hope people aren't learning Rust as a status symbol.
Of course they do. Lots of learning today seems to be based around "what looks nice to put on my resume?" which is effectively a status symbol, rather than choosing tooling that is actually the best for the job.
Same applies for a ton of stuff as well, not just Rust.
No, that's something else. Choosing languages in order to look better on the resume is not personal development, it is resume-driven development. Learning new languages in order to become a better programmer overall is personal development, or learning languages that fits better with "you as a person". But chasing hype is not "personal development" and that meme needs to die.
Sad and true.
The other side of the equation is people being forced to work under abysmal constraints, because of technical choices made years or even decades ago.
That being said, "Rust on the frontend" sounds pretty ridiculous to me.
I'm sorry for not having read the article before commenting.
From what I've seen, most frontend Rust development is focusing on replacing C/C++/C# frontends, not necessarily for websites or even really desktop applications.
With that being said, I have written a few GTK+ applets in Rust, and I gotta say that it's not as bad as it sounds or looks. The current GTK crate supports Glade, meaning that you don't have to actually write your frontend in Rust, rather building it in a different program, exporting it as glorified XML and binding the intractables to different buttons and fields. A hello world-styled GTK demo is only a few lines, and of course you get a wickedly performant binary out of the process too (mine used 4mb of memory, which could have been further optimized).
As someone with limited experience, how do you deal with animations and such in GTK/Glade? Took a look at the Glade website (https://glade.gnome.org/) and doesn't seem mentioned. In fact, I cannot even find a list of supported features.
(Disclaimer: I have no idea what I'm talking about)
I wouldn't be surprised if you could/had to do something similar to this sprite handling example[1], where instead of updating the sprite's location you update widgets' attributes. This would be a "manual" process, but it should work (if repainting widgets is fast enough).
Animation is handled by the compositor I'm pretty sure. Since different Linux desktops have different performance requirements, some will opt-in to using more fancy animations, whereas less powerful ones will disable them.
For everything else, you'd probably need to use some bespoke activators to achieve the effect you want. Not terribly hard to spin up, but it's definitely less simple than languages designed for frontend development.
> Animation is handled by the compositor I'm pretty sure. Since different Linux desktops have different performance requirements, some will opt-in to using more fancy animations, whereas less powerful ones will disable them.
I... don't understand what this means.
Let's say in GTK/Glade I want a Button that when you click on it, it moves from the bottom-left corner to the top-right corner. How do I archive this in that GUI builder or even with the XML spec?
I haven't done anything like this myself, but you can directly manipulate the location of UI elements in realtime. Failing all else, Rust is at least low enough level to impliment a frame-by-frame redraw... but that would be a very yucky way to do that.
Replacing C# with Rust for front-end sounds equally ridiculous.
C# is much higher level and ergonomic to use for this, the tooling alone is lightyears ahead for the job - compile times/debugging for GUI iteration alone.
I can understand using rust for front-end to slap some simple gui on top of some complex lib and allows a lot of reuse (although I would still prefer GUI using rust through an interface from higher level like FFI/IPC).
I saw this same attitude on a Haskell shop - "we write UIs in Haskell to prevent hiring script kiddies". Turns out Haskell coders with 20y of experience on completely non-visual workloads are terrible at UI/UX, to the point of dismissing the work of building the UI as "a lesser concern".
But let’s say you have two resumes in front of you. One person has only worked in interpreted languages and the other has worked in interpreted languages as well as in C, C++, Go, Rust..
Not enough information. It largely depends on the product, the team, and even soft skills or domain knowledge.
In some contexts, yes having knowledge of compiled or non-GC languages is critical. But there is a certain baseline of programming knowledge that allows any dev to be decently productive; for many products & teams, soft skills become more important after that point. For example: if the interpreted lang dev is great at communicating and the compiled dev is terrible, some teams may elect to choose the first for that reason alone.
You could also argue that it puts you at risk of hiring someone from the other end of the spectrum: a knowledgeable senior dev that is more interested in writing over-engineered solutions for the fun of it, rather than matching the solution to the problem.
Rust is great and shows a lot of promise, but I think you need to have some strong arguments when using a lower-level systems language outside of a systems-focused context. Not saying it can't/shouldn't be done, but it's worrying to me when people stop thinking critically because of the hype.
Usually I see comments like this from people who think "Frontend is easy, backend is hard" and then you look at the frontend code and you scream in pain.
Its not like you can not write bad code in Rust. Rust has for example 6 String types. You can also write unsafe rust code. There were example in the past were major Lib's did it just to make it faster.
Also the rust frontend eco system has a very low maturity. So you probably will be writing a lot of stuff on your own (what script kiddies do because they think they can do it better).
If for you it is important to have someone which is not a script kiddie then you could also go for someone who understands RxJS and Angular. This would also "filter".
I'm not sure how many people you will find with good rust skills and good UI/UX skills. If this is not important then go for it.
Six? I can think of String (owned bag of utf-8 bytes), &str (reference to utf-8 bytes), and OsString (potentially non utf-8 depending on your platform, used for ffi).
Some people say Cow<str> is a string type, but I think it's better thought of as a genetic type you often use with strings.
People say "Rust has six string types" but what they mean is "the standard library has six string types". Rust-the-language has one string type: str. The standard library also has:
* String
* OsString / OsStr
* CString / CStr
if people really want to make it look big, they also include PathBuf/Path and Cow<str>.
Thanks! I'm definitely often guilty of conflating the stdblib and the language.
I prefer to think of it as programers have used strings to represent too many non-string things in the past. It's nice to look at a function sig and see Path/camino::Utf8Path/bytestr::ByteStr and see what they actually plan on doing with it.
In the context of Backend/Frontend development I would question it.
I had a colleague who rewrote some string functions in Java which are part of the stdlib. He called them "Arne Tools". Arne is a name in Germany. We were doing Java Applets back then.
Sure, but just because it’s in the standard library doesn’t mean you use it all the time. 95% of my usage on non-embedded targets is String and &str. The “six string types” makes things seem far more complex than they are.
Unsafe Rust is not automatically bad. The main reason all of those major libraries got switched to safe Rust is that progress in language features made it possible to do the same operations safely.
Correct me if I'm wrong, but isn't one of the main selling points of Rust that's it's "safe"? If you're using "unsafe" Rust, you might just go for more established languages straight up.
Rust's main selling point is a type system that allows safe wrappers around unsafe code by encoding invariants in the types themselves. Stuff that lives in the documentation like "you need to call foobar_free" becomes an unsafe block in a safe Drop implementation that only needs to be extensively tested once to validate the safety of the wrapper. Once the safe-unsafe interface is tested, downstream code doesn't have to worry about the unsafe implementations at all.
Without unsafe, Rust programs would be useless since the Rust compiler can't verify the safety of external libraries that provide critical functionality like memory allocation and syscal interfaces (I/O). It would also go against one of Rust's main goals which is C FFI compatibility, which is something that the Rust compiler can't verify.
It's more about how strongly typed the language itself is. Rust isn't necessarily harder to learn than a scripting language, but a lot of it's syntax is dependent on how well you understand programming fundamentals. For example, you can't just spin up an integer at will in Rust: you need to specify how many bits you're using, and manually sign or unsign each value to manipulate it accordingly. That's the stuff that will filter out JS writers and Python devotees.
It's not really an insult so much as it is commentary about the language. The focus on zero cost abstraction and correctness at compilation means that it's harder for a Rust dev to write a slow program than it is for a Python or Java dev. Again, not necessarily because of any fundamental issues with the other two languages, but rather that Rust is a pickier language.
> For example, you can't just spin up an integer at will in Rust: you need to specify how many bits you're using, and manually sign or unsign each value to manipulate it accordingly.
I mean, you can do this, but it will still get automatically typed as a u8, which could very easily cause confusion for Python devs who really want to push that value past 255. My bigger point (and likely the authors) was that Rusts integers aren't like Java's ints or Python's bigints. Your laziness in that example is still being penalized, it's just harder to see and therefore, less "correct".
Also, it's an attitude completely antithetical to that which the Rust community tries to cultivate.
Literally, the very first sentence on rust-lang.org is "A language empowering everyone to build reliable and efficient software." Making "real" a systems programming language that is more accessible is one of the primary goals of the language. And a large portion of the Rust community are converts from scripting languages like Python / Ruby / NodeJS, and the tooling is inspired by (good parts of) the tooling that sprang up in those communities.
If you want to think that way about "script kiddies" then that is your right, but keep it to yourself.
The Rust community really has a problem with some of its fans and zealots there (far from the only programming language community to do so of course, but I can't remember seeing arguments that users of the wrong language should be tried in Den Haag in other places...).
I'll be a bit raw, sorry for it.
There is a battlefield in the JS ecosystem. Anyone seasoned in it, with all that entails, is not your "script kiddie" as that word originated in a VERY different era, with very different requirements for said "script kiddies". If anything, it shows that the one using this phrase is a bit out of the loop.
(author here)
I probably should have mentioned it more prominently in the post, but Martin's first language isn't English (he's Czech). So not out of the loop, but the exact connotation of the phrase is something I personally cut him slack on
Rust is a language whose selling point is safety so I don't see unsafe code appearing often no matter its popularity.
I do agree that it is divisive, but sometimes it also feels like humbleness of research programming languages (esp. Haskell) designers is a bit faked, which can have the opposite effect and scare beginners. The most popular languages, who beginners love, tend to have a history of being designed to be practical, not well designed or researched.
I have a tiny bit of Rust experience, and honestly if someone taught me Rust as a first programming language, I'd get so frustrated and insecure. Don't get me wrong, it's a beautiful language and the online book is great -- but it has a great barrier to entry and most people would get frustrated. Meanwhile, people following JS tutorials will already feel dopamine hit from getting their own programs running on screen and will be motivated to continue their journey.
I didn't get the impression from speaking with Martin that he was trying to gatekeep. He's spent a lot of time on github and in discord helping people learn Seed and MoonZoon.
In the context of hiring, I think the signal he's talking about is the same for any minority language like Haskell or Elixir. If you're spending nights and weekends hacking in a language that's not widely used in industry, it's an enthusiasm signal. This was true for Python about a decade ago, even though it's an easy language to learn. If you hired python developers, it was a signal that you'd be getting passionate enthusiastic developers.
As Rust becomes more adopted and hiring goes up, I think the value of that signal will go down. Rust certainly has complexity, but I don't think they're insurmountable barriers for any significant class of developers.
On the other hand, it might send potentially negative signals. Someone who "hacks" on a less-used language might have a programming language fetish, i.e. "why would you ever use Java...Rust is better in every way". And yes, I've met a few of those.
Rust should not be a status symbol, but as someone very wary of Rust-hype myself, I'm very wary of the number of 1/2 developers out there.
There are people who pick up a few lines of JS, a few lines of Python and are technically 'developers'.
There are others with much stronger fundamentals.
PG was big on using arcane languages as a form of natural selection, Rust may be nice for that, in the sense that I think anyone who can approach rust and make an app with it, probably fits in the 'developer' camp at least on some level.
I like it because when looking for C++ people, I also want people who have enough self-awareness, and Rust makes you think about things in a different way, and at least contemplate some of the bad habits that exist in C++.
Not just that - using complicated solutions in situations they offer few benefits and a lot of downsides to establish tech is a massive red flag for me.
The worst project I've ever worked on was a C# project where some random mid-level dev thought he was smarter than anyone for learning functional programming. He wrote his own Monad framework that abused LINQ syntax for composition, everything was littered with this bastardised Maybe implementation, he used delegates all over the place - including dependency injection containers, etc.
By the time I came on the project it was years into development and the original guy left years ago. It was the worst mess you ever saw - months long onboarding, unreadable code, stack traces full of useless shit, impossible to lookup where specific dependencies were coming from in the project.
A very technical but immature developer is much worse than a below average dev.
I think it is a disadvantage to write Rust on the frontend. Frontend code moves too much and quick prototyping/iteration is more important than memory control.
As for typing, just use TypeScript. It is really good enough already.
I haven't had many issues with it. My development cycle has normally involved getting the basic functionality of my program to work, then adding a UI layer over it with the GTK crate. In terms of how fast it is to prototype/iterate, I could very easily manipulate and edit the UI file in Glade, then rebuild the program in only a couple seconds to test the result.
>Frontend code moves too much and quick prototyping/iteration is more important than memory control.
You can have both, really: Rust makes a lot of compromises on it's debug builds, but it compiles lightning fast. As I said above, you can change your program and see how it looks in realtime by simply dropping "cargo run" into the shell. There's not much I can do for you here except tell you to see for yourself.
First time compilation is notoriously slow, since Rust has to compile your dependencies into object files, and to make "release" binary, it has to re-compile those same dependencies to make a statically linked and optimized executable. The actual debug process is fairly quick though, since it can just link the deps to a lazily compiled binary for debugging purposes.
It's easy to run into untyped (or partially typed) dependencies (a massive pain to write) or in internal code which uses any/unknown somewhere (causing typing holes which allow for whatever inputs).
I love types but I can't trust TypeScript types to be valid, I've been bit too many times.
Rust (or any other really typed language) would be great if the solutions are mature enough. It's not just for memory control.
I like this idea and want to keep up with it. The only that would hold me back is that I feel spoiled writing JSX, I just think it's such a nice way to write the front-end within the javascript. If you could get JSX like syntax in Rust I would be 100% sold on this. Does anyone know if that is possible? I assume you'd have to write a parser for this?
To me, Rust only makes sense for very CPU intensive applications that don't need the DOM. Run the Rust code in a Web Worker and use OffScreenCanvas to show the results. This can work great for things like remaking Photoshop or Maya for the web.
For you everyday web <form> and <input /> don't complicate things too much.
I wrote the the Seed framework mentioned in the article. I'm still happy with the API, but now my websites are all server-rendered, with no frontend frameworks, no frontend dependencies or build steps, and targeted JS to perform DOM manipulations when required. YMMV!
77 comments
[ 3.4 ms ] story [ 157 ms ] threadThis is likely referring to ASP .NET Web Forms. While this is theoretically true the reality was more nuanced; you had to know HTML/CSS in order to style your applications and you had to know a wee bit of jQuery to make things happen on the page when you didn't want to trigger a "postback" (their proprietary term for a POST request laden with the requisite ViewState and session magic). The _real_ magic of ASP .NET was implicit state management... you didn't have to know anything about sessions, cookies, HTTP, CSRF, or LocalStorage (which, sadly, was around for some of Web Forms's heyday because many devs clung onto it for much longer than they should have). The whole point of Web Forms was to replicate the WinForms experience in a web context so that devs didn't have to reason so much about client vs server state. Everything was rendered server-side and state was retained via a combination of session and the aforementioned "ViewState", which was basically a massive encrypted form field with the application state that got submitted with every request.
It could probably be argued that Web Forms doesn't even really qualify as web development. I've weaned developers off of WebForms and for most of them it was their first exposure to basic tenets of web development like HTTP verbs (let alone RESTfulness), JSON, vanilla Javascript, sessions, and actual honest-to-God state management.
So does JVM now :). But with a more en-vogue API. https://blog.jetbrains.com/kotlin/2021/05/technology-preview...
Since then I am very wary of frameworks that provide a lot of abstractions. Easy to get into but after a while there is a risk spending more energy fighting the framework than you would have spent learning the native way.
Happened in my company with Xamarin. Looked good for C# but after a few months everything got scrapped and the devs went native.
Of course they do. Lots of learning today seems to be based around "what looks nice to put on my resume?" which is effectively a status symbol, rather than choosing tooling that is actually the best for the job.
Same applies for a ton of stuff as well, not just Rust.
That being said, "Rust on the frontend" sounds pretty ridiculous to me.
I'm sorry for not having read the article before commenting.
With that being said, I have written a few GTK+ applets in Rust, and I gotta say that it's not as bad as it sounds or looks. The current GTK crate supports Glade, meaning that you don't have to actually write your frontend in Rust, rather building it in a different program, exporting it as glorified XML and binding the intractables to different buttons and fields. A hello world-styled GTK demo is only a few lines, and of course you get a wickedly performant binary out of the process too (mine used 4mb of memory, which could have been further optimized).
I wouldn't be surprised if you could/had to do something similar to this sprite handling example[1], where instead of updating the sprite's location you update widgets' attributes. This would be a "manual" process, but it should work (if repainting widgets is fast enough).
[1]: https://github.com/steshaw/gtk-examples/blob/master/ch13.spr...
For everything else, you'd probably need to use some bespoke activators to achieve the effect you want. Not terribly hard to spin up, but it's definitely less simple than languages designed for frontend development.
I... don't understand what this means.
Let's say in GTK/Glade I want a Button that when you click on it, it moves from the bottom-left corner to the top-right corner. How do I archive this in that GUI builder or even with the XML spec?
C# is much higher level and ergonomic to use for this, the tooling alone is lightyears ahead for the job - compile times/debugging for GUI iteration alone.
I can understand using rust for front-end to slap some simple gui on top of some complex lib and allows a lot of reuse (although I would still prefer GUI using rust through an interface from higher level like FFI/IPC).
You would anyway need UX designers for that, the issue is leaving that to the developers.
I do my own design sometimes but when I implement a well designed design by a real designer the end result is years light ahead
But let’s say you have two resumes in front of you. One person has only worked in interpreted languages and the other has worked in interpreted languages as well as in C, C++, Go, Rust..
Both of them clear your technical interview.
Which candidate will you pick?
And getting a candidate because of that one metric would be insane..
In some contexts, yes having knowledge of compiled or non-GC languages is critical. But there is a certain baseline of programming knowledge that allows any dev to be decently productive; for many products & teams, soft skills become more important after that point. For example: if the interpreted lang dev is great at communicating and the compiled dev is terrible, some teams may elect to choose the first for that reason alone.
There was another reason for its existence??
Rust is great and shows a lot of promise, but I think you need to have some strong arguments when using a lower-level systems language outside of a systems-focused context. Not saying it can't/shouldn't be done, but it's worrying to me when people stop thinking critically because of the hype.
Usually I see comments like this from people who think "Frontend is easy, backend is hard" and then you look at the frontend code and you scream in pain.
Its not like you can not write bad code in Rust. Rust has for example 6 String types. You can also write unsafe rust code. There were example in the past were major Lib's did it just to make it faster.
Also the rust frontend eco system has a very low maturity. So you probably will be writing a lot of stuff on your own (what script kiddies do because they think they can do it better).
If for you it is important to have someone which is not a script kiddie then you could also go for someone who understands RxJS and Angular. This would also "filter".
I'm not sure how many people you will find with good rust skills and good UI/UX skills. If this is not important then go for it.
Some people say Cow<str> is a string type, but I think it's better thought of as a genetic type you often use with strings.
I prefer to think of it as programers have used strings to represent too many non-string things in the past. It's nice to look at a function sig and see Path/camino::Utf8Path/bytestr::ByteStr and see what they actually plan on doing with it.
and then start to implement things that are in the stdlib?
There's not a lot of reason to re-implement it, because if you can use it, there's not a lot of reason to not just use it.
There are people who make even more string types as packages, and use those. smallstr and bstr are two examples of those.
In the context of Backend/Frontend development I would question it.
I had a colleague who rewrote some string functions in Java which are part of the stdlib. He called them "Arne Tools". Arne is a name in Germany. We were doing Java Applets back then.
I always have to think of that example :D
The argument was that you can disable it easily.
For good and bad reasons.
Correct me if I'm wrong, but isn't one of the main selling points of Rust that's it's "safe"? If you're using "unsafe" Rust, you might just go for more established languages straight up.
Besides, having 95% safe code and 5% unsafe code is still going to help when working on the rest of the codebase
Without unsafe, Rust programs would be useless since the Rust compiler can't verify the safety of external libraries that provide critical functionality like memory allocation and syscal interfaces (I/O). It would also go against one of Rust's main goals which is C FFI compatibility, which is something that the Rust compiler can't verify.
It's not really an insult so much as it is commentary about the language. The focus on zero cost abstraction and correctness at compilation means that it's harder for a Rust dev to write a slow program than it is for a Python or Java dev. Again, not necessarily because of any fundamental issues with the other two languages, but rather that Rust is a pickier language.
Literally, the very first sentence on rust-lang.org is "A language empowering everyone to build reliable and efficient software." Making "real" a systems programming language that is more accessible is one of the primary goals of the language. And a large portion of the Rust community are converts from scripting languages like Python / Ruby / NodeJS, and the tooling is inspired by (good parts of) the tooling that sprang up in those communities.
If you want to think that way about "script kiddies" then that is your right, but keep it to yourself.
However, that doesn't mean the person can write concise code or have good soft skills, or be a good hire.
This whole argument is exclusionary and divisive.
I do agree that it is divisive, but sometimes it also feels like humbleness of research programming languages (esp. Haskell) designers is a bit faked, which can have the opposite effect and scare beginners. The most popular languages, who beginners love, tend to have a history of being designed to be practical, not well designed or researched.
I have a tiny bit of Rust experience, and honestly if someone taught me Rust as a first programming language, I'd get so frustrated and insecure. Don't get me wrong, it's a beautiful language and the online book is great -- but it has a great barrier to entry and most people would get frustrated. Meanwhile, people following JS tutorials will already feel dopamine hit from getting their own programs running on screen and will be motivated to continue their journey.
I didn't get the impression from speaking with Martin that he was trying to gatekeep. He's spent a lot of time on github and in discord helping people learn Seed and MoonZoon.
In the context of hiring, I think the signal he's talking about is the same for any minority language like Haskell or Elixir. If you're spending nights and weekends hacking in a language that's not widely used in industry, it's an enthusiasm signal. This was true for Python about a decade ago, even though it's an easy language to learn. If you hired python developers, it was a signal that you'd be getting passionate enthusiastic developers.
As Rust becomes more adopted and hiring goes up, I think the value of that signal will go down. Rust certainly has complexity, but I don't think they're insurmountable barriers for any significant class of developers.
There are people who pick up a few lines of JS, a few lines of Python and are technically 'developers'.
There are others with much stronger fundamentals.
PG was big on using arcane languages as a form of natural selection, Rust may be nice for that, in the sense that I think anyone who can approach rust and make an app with it, probably fits in the 'developer' camp at least on some level.
I like it because when looking for C++ people, I also want people who have enough self-awareness, and Rust makes you think about things in a different way, and at least contemplate some of the bad habits that exist in C++.
The worst project I've ever worked on was a C# project where some random mid-level dev thought he was smarter than anyone for learning functional programming. He wrote his own Monad framework that abused LINQ syntax for composition, everything was littered with this bastardised Maybe implementation, he used delegates all over the place - including dependency injection containers, etc.
By the time I came on the project it was years into development and the original guy left years ago. It was the worst mess you ever saw - months long onboarding, unreadable code, stack traces full of useless shit, impossible to lookup where specific dependencies were coming from in the project.
A very technical but immature developer is much worse than a below average dev.
As for typing, just use TypeScript. It is really good enough already.
>Frontend code moves too much and quick prototyping/iteration is more important than memory control.
You can have both, really: Rust makes a lot of compromises on it's debug builds, but it compiles lightning fast. As I said above, you can change your program and see how it looks in realtime by simply dropping "cargo run" into the shell. There's not much I can do for you here except tell you to see for yourself.
It's easy to run into untyped (or partially typed) dependencies (a massive pain to write) or in internal code which uses any/unknown somewhere (causing typing holes which allow for whatever inputs).
I love types but I can't trust TypeScript types to be valid, I've been bit too many times.
Rust (or any other really typed language) would be great if the solutions are mature enough. It's not just for memory control.
https://github.com/stoically/syn-rsx
https://github.com/yewstack/yew
But there are others like Sauron, Maple, and Percy that have their own Elm-like approach which is probably almost just as good.
For you everyday web <form> and <input /> don't complicate things too much.