Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust needs a web framework

ntietz.com

Post reply on HN
Print view View original

321–330 of 395 posts

Re: Rust needs a web framework

#321

Post by throwaway173920 »

wonrax wrote: post #206
bsnnkv wrote: post #95

Earlier quoted context omitted.

I'm the other way around I guess - a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python and JS at work. Part of it might be the terrible tooling story in each of those language ecosystems as well. Last week I deployed a Ruby change where a missed comma between two strings in an array did not get picked up by any of the automated tooling or by 3 other team members who code reviewed my change,…

> I feel a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python, and JS. I resonate with you even with TypeScript, since it's just annotating types but not the true value under the variable. You would have to go to a greater extent to make sure that everything from outside (library code, parsing HTTP responses, database queries, etc.) conforms to your annotated types. Even in the same project…

I haven't had this experience with TypeScript. In the projects I've worked with, we turn on strict mode and heavily discourage using `any`. I generally feel pretty confident that the type annotations match the runtime values.

Re: Rust needs a web framework

#322

Post by slowmovintarget »

drpossum wrote: post #234
Capricorn2481 wrote: post #147

Earlier quoted context omitted.

Doesn't really answer the question. Most webapps are this way and people are still surprisingly unaware of this.

It is a refutation of the premise which invalidates this particular question as it was posed.

"Not every" is not the same as "none" and the discussion is about the majority, so I think your refutation is only of the absolute case and not of the original premise.

Rust would be overkill for most web applications.

Re: Rust needs a web framework

#323

Post by CharlieDigital »

satvikpendem wrote: post #169
CharlieDigital wrote: post #100

Earlier quoted context omitted.

> I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. F# seems like a good option.

How is F# on non-Microsoft platforms, is it fully cross platform? I don't use C#, .NET, or F# so I have no idea about the ecosystem.

Really good.

I'm in a startup using .NET. We deploy to a variety of targets including AWS t4g (Arm64) instances in AWS as well as x86/64 targets in GCP. All devs are on M1 Macs. Our build pipeline is GitHub Actions Linux runners. Our DB is either AWS RDS Postgres or GCP Cloud SQL Postgres with a mix of EF Core as ORM and Dapper (for more complex read queries).

C# has, over the years, converged with TypeScript so they are very similar[0] (though no Duck typing in C#). Good mix of OOP and FP paradigms borrowed from F#. F# interoperates with C# so it can tap into the larger C# ecosystem.

It's a good platform; very productive. CLI has a functional hot reload (much more limited than Node on JS as the granularity of module replacement isn't quite as good).

[0] https://github.com/CharlieDigital/js-ts-csharp

Re: Rust needs a web framework

#324

Post by discreteevent »

echelon wrote: post #101
angra_mainyu wrote: post #78

Earlier quoted context omitted.

The developers they measured, were they using the languages for the exact same tasks? Otherwise it's just stating that they assign the languages to categories of problems they are equally efficient in.

https://www.youtube.com/watch?v=QrrH2lcl9ew > "We have at this point rewritten a large number of systems [..] have some very concrete things that we can say" > "When we've rewritten systems from Go into Rust, we've found that it takes about the same sized team about the same amount time to build it. [...] no loss of productivity when moving from Go to Rust." > "We do see some benefits [...] we see reduced memory usag…

> "When we've rewritten systems from Go into Rust, we've found that it takes about the same sized team about the same amount time to build it."

A rewrite should be much faster than the original. Much of the original development will have had changes in requirements, refactors because of better understanding the problem domain, best structure for the code etc. A lot of that can be just 'copied' into the new system. The developers know exactly what to do.

To complete this experiment they should have also re-written it in C# or java and then compare with rust.

Re: Rust needs a web framework

#325

Post by chrismorgan »

isosphere wrote: post #252

Doing my web stuff in Rust was fine but concurrency was a pain. A crate that abstracts web workers with transferrable types would help. After that you have to pick a component library of which there are few, and all are experimental. Making pretty, performant things is hard. Switching compontent libraries isn't easy. The backend stuff is a breeze, I think Rust is doing fine there. I'm switching to Flutter for my UX n…

> I stayed away from Flutter at first because it doesn't respect the DOM etc but at this point I'm willing to sell my soul to the devil for how easy it is to make a great UX that deploys anywhere.

Great UX, you say? Great UX!? Flutter’s unashamed pure-canvas approach makes it fundamentally and unfixably awful. Links don’t work because they’re fake (and it’s impossible to fake them), scrolling is atrocious for a significant fraction of users, text handling is obnoxious and wrong… seriously, speaking as a user, I’ve come across things made with Flutter three times in the last four years (plus looking at their demos), and Flutter makes for literally the worst user experience that I have come across in that time.

Now Flutter does actually have a DOM renderer, but it never seems to be used. I’m not entirely sure why. Actually, scratch that, I just went to find a link, and found https://docs.flutter.dev/platform-integration/web/renderers only talking about canvaskit and skwasm, no mention of the html renderer any more… it seems like they deprecated it earlier this year https://github.com/flutter/flutter/issues/145954>, and will presumably remove it some time soon, doubling down on pure-canvas. Well, at least that lets me more unconditionally condemn Flutter for the web.

Text is bad, especially if you use emoji. Links are bad because they’re fake. Scrolling is bad for a decent fraction of users. And none of these three are fixable if you insist on pure-canvas. (Links you could kinda make work tolerably if you were willing to compromise a little, but the other two just can’t be done.)

If you want more substance to my complaints about the pure-canvas approach, search HN comments for “chrismorgan canvas” or similar. I still haven’t finished reducing it to an article on my website.

If you intend to target the web and care about the web at all, please don’t use Flutter.

Re: Rust needs a web framework

#326

Post by binkethy »

jillesvangurp wrote: post #281
tcfhgj wrote: post #264

Earlier quoted context omitted.

It's an investment in energy efficiency

The advantages of a language like Rust where most interactions are blocked on either user input or network IO are fairly limited. Rust shines when things are CPU or memory bound primarily. Web applications are mostly IO bound. Which is why people have been getting away with fairly poorly optimized interpreted languages for decades. Even when computers were a lot slower than they are today, this worked fairly well.

Strict typing can enforce proper composition from models to the request responses.

Rust is a high AND low level lego due to type composition and ability to directly address memory with no hacky garbage collection required.

Garbage collection is a bad idea when your state machine is basically a stateless request response cycle that can fit in n stack frames and has a defined lifetime ending in the response.

Interpreted languages calculate runtime code paths on an ad-hoc basis and are subject to bugs that a binary executable will never encounter.

One can objectively state that Interpreted languages and their virtual machines are LESS DETERMINISTIC than binary executables whose runtime code already exists at compilation time.

Of course, shared libs and other things that violate the spirit of the above can wreak havoc with even binaries, however the executable is a finite artifact.

Re: Rust needs a web framework

#329

Post by K0nserv »

jknoepfler wrote: post #14

I wish the author success in their endeavor, but Rust is pretty far down the stack of languages I'd use to deliver a webserver. I look at Rust for serving web-traffic and I see: dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), weak client library stories (if I'm writing a service layer for a db, etc.), high barrier to entry, thin overlap with the core Rust value pr…

> dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang)

With the exception of having to write out `async`/`await` the dominant concurrency model in Rust is mostly the same as Go(work stealing CSP). Sure Rust's memory model makes it a bit more cumbersome than Go. Rust's Send/Sync bounds might seem complicated, but those concerns are equally relevant in Go, the compiler just doesn't help you.

Re: Rust needs a web framework

#330

Post by fweimer »

pjmlp wrote: post #312
fweimer wrote: post #249

Earlier quoted context omitted.

One issue is that with GC, you lose prompt finalization of resources. A lot of code is written with this assumption in mind (e.g., file buffers are flushed if the last reference to the file is dropped—which is arguable incorrect due to the lack of error checking). And the borrow checker is the only thing that keeps everything from being mutable in place in Rust today. Having GC would open the possibility for alternat…

An issue only in some GC languages that don't provide the constructors for deterministic resource handling. Unfortunately people keep placing all GC languages on the same basket. And before anyone mentions that it is easy to forget, well those languages have their own "Clippy" to take care of it.

I don't think constructors are the challenging part. It's about lexically scoped destruction. Certainly there are languages that have that and permit garbage collection, however those constructed values are necessarily second-class citizens and behave somewhat differently than ordinary values. There's probably some reasonable middle-ground, like constructors returning an owned reference that explicitly can be turned into an unowned reference, thus opting out of deterministic destruction.
Post reply on HN