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

131–140 of 395 posts

Re: Rust needs a web framework

#131

Post by dymk »

throw10920 wrote: post #121
fallingsquirrel wrote: post #115

Earlier quoted context omitted.

> When did threading get added to JavaScript? Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) > And does Rust have type unions and intersections, interfaces, and mapped and conditional types? You can typically accomplish the same thing with enums/proc macros/traits of course—with the additional benefit that the type system is designed to be so…

> Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) ...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. > usually So, not always. That is - TypeScript's type system contains features that Rust's does not have.

> which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency.

Simply so untrue I’m not going to elaborate further

Re: Rust needs a web framework

#132

Post by [deleted] »

fallingsquirrel wrote: post #130
throw10920 wrote: post #121

Earlier quoted context omitted.

> Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) ...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. > usually So, not always. That is - TypeScript's type system contains features that Rust's does not have.

> which is an extremely rare source of bugs Confidently asserted, but very debatable. > The vast majority of errors caused by shared mutable state are related to concurrency. Concurrency, like async-await, you mean? > TypeScript's type system contains features that Rust's does not have Sure, and likewise Rust's type system contains features TypeScript's does not have—for example, just try expressing anything close to…

[deleted]

Re: Rust needs a web framework

#133

Post by sunshowers »

cmrdporcupine wrote: post #129
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.

Or just OCaml

OCaml is an excellent language, but doesn't it have a GIL?

Re: Rust needs a web framework

#134

Post by [deleted] »

dymk wrote: post #131
throw10920 wrote: post #121

Earlier quoted context omitted.

> Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) ...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. > usually So, not always. That is - TypeScript's type system contains features that Rust's does not have.

> which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. Simply so untrue I’m not going to elaborate further

[deleted]

Re: Rust needs a web framework

#135

Post by adastra22 »

J_Shelby_J wrote: post #113
creatonez wrote: post #57

Earlier quoted context omitted.

The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towar…

People who say copilot is useless.... I can only imagine they're in a dynamically typed language. Copilot + Rust makes boilerplate go fast. Strong typing is force multiplier for code gen.

I suspect that’s true. I never blindingly copy LLM generated code (that would be recklessly stupid), but I often only quick skim rust code generated this way, just to make sure the general task it is solving is what I asked for. If there is an unhandled edge case or or memory handling bug, rust will catch it.

Re: Rust needs a web framework

#136

Post by joshdavham »

A lot of commenters are really getting hung up on the author's use of 'lazy'.

When she says lazy, she just means that she'd like a web framework that takes care of the most common and obvious schleps that are needed to create a web framework, like routing and so on. Once you get those schleps out of the way, there's still tons of work that needs to be done. Nothing lazy about that.

Re: Rust needs a web framework

#137

Post by pdpi »

joshdavham wrote: post #136

A lot of commenters are really getting hung up on the author's use of 'lazy'. When she says lazy, she just means that she'd like a web framework that takes care of the most common and obvious schleps that are needed to create a web framework, like routing and so on. Once you get those schleps out of the way, there's still tons of work that needs to be done. Nothing lazy about that.

It all makes sense if you consider laziness here to mean the same as in Larry Wall's three great virtues of a programmer.

Re: Rust needs a web framework

#138

Post by ActorNightly »

tkzed49 wrote: post #83
ActorNightly wrote: post #71

Earlier quoted context omitted.

Typing in modern days is effectively moving the task of debugging to compile/ide annotations process instead of testing for correctness. Albeit it makes the process easier compared to a really shittly written code without strict typing, but against good codebases, it takes the same amount of time.

I strongly disagree on the principle that tests and types have a 100% overlap in the problems they're solving.

Why not?

If you think about correctness of a program, (i.e for any combination of given input , it changes a state in a determinstic way, including no state change for invalid input).

Strict typing is one way to accomplish this. The cpu does not give a shit about types. It cares about memory registers and locations. The unique code built into the compliers/transpilers is the thing that validates the correctness of the program in this case.

You can move that code into the testing suite without relying on the complier, and just do testing. Generally, given competent programming skills, this takes about the same amount of time as designing a well structured program - your tests are pretty much your design document for the thing itself.

Re: Rust needs a web framework

#140

Post by nopeYouAreWrong »

googledocsftw wrote: post #32
doctorpangloss wrote: post #9

For new web applications, why recommend alternatives to Next.js? How do you convince someone to use an alternative? The knowledge needed to understand why will help you get close enough in Next.js anyway.

1. Lots of dead ends. Fetch cache limit for example. Cant replicate prod page caching behaviour in dev. Etc. Many issues with 100 thumbs get abandoned. 2. NodeJS. Not everyone likes it. 3. It is slow. Yes it is! Try to get good web metrics with Next I dare you! 4. Premature release of App Router. Will they do something like that again.

why are you fealung with cache at all in a wrb context? that's what CDNs are for.
Post reply on HN