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

121–130 of 395 posts

Re: Rust needs a web framework

#121

Post by throw10920 »

fallingsquirrel wrote: post #115
throw10920 wrote: post #110

Earlier quoted context omitted.

When did threading get added to JavaScript? And does Rust have type unions and intersections, interfaces, and mapped and conditional types?

> 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.

Re: Rust needs a web framework

#122

Post by bigiain »

elAhmo wrote: post #18

Rust is not for lazy developers and there are other languages if you want to put minimal effort in building things.

Larry Wall (the Perl guy) had "The three virtues of a great programmer", in which the "Laziness" virtue wasn't putting minima<l effort into _building_, instead it was about building stuff that created minimal effort for people to use. I can easily see a definition of a "lazy Rust developer" which is about writing things that work properly for everybody all the time. It's being lazy about minimizing the future effort you'll need to put in fixing bugs or answering questions about it, instead of the "throw together something that looks kinda like it meets the requirements" in the minimal amount of time/effort sort of lazy.

Re: Rust needs a web framework

#123

Post by dap »

devjab wrote: post #10

> I like to make silly things, and I also like to put in minimal effort for those silly things. I also like to make things in Rust… I think this part is perhaps the silliest part of a very silly article. If you really like to put in a minimal effort then why on earth would you use Rust? If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the stan…

For what it’s worth, for me, the time-to-first-attempt-to-run-it is faster in Python or Node than Rust (sometimes), but the time-to-first-working program is generally not, and by the time I have the Rust one working, it handles most of the corner cases with clear error messages. There are rarely unexpected cases not handled.

In other words, I find it faster to produce working stuff in Rust and much faster to produce quality stuff.

Obviously I’m just one data point.

Re: Rust needs a web framework

#124

Post by throw10920 »

bigiain wrote: post #114
throw10920 wrote: post #94

Earlier quoted context omitted.

> I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice). Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. My second paragraph is pointing out that "where I can open something like Notepad without an LSP or highlighting" is a strange qualifier. Why does it matter if you don't have semantic analysis…

> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. If you know that using global variable is often a bad idea, then you are, in some sense, worrying about lifetimes. I first learned this in the mid/…

> As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though.

Yes, to a much smaller extent. Rust's object lifetimes, for all the performance gains you get, add on a layer of additional cognitive and development overhead that is simply not present in memory-managed languages.

Re: Rust needs a web framework

#125

Post by throw10920 »

bsnnkv wrote: post #97
throw10920 wrote: post #94

Earlier quoted context omitted.

> I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice). Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. My second paragraph is pointing out that "where I can open something like Notepad without an LSP or highlighting" is a strange qualifier. Why does it matter if you don't have semantic analysis…

> Worrying about lifetimes Again, not my experience at all. I simply don't think about any of that stuff when I write Rust, all my mental energy can safely go towards working on whatever I'm building. If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.

> Again, not my experience at all. I simply don't think about any of that stuff when I write Rust

Your subjective perception is not reality. You have to think about it, or your programs will be incorrect. The mental load may be low to an experience Rust programmer, but it is there, and it's very intrusive to Rust beginners like myself.

> If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.

That's not relevant. Lack of external indicators of cognitive load does not mean that it's not happening.

Re: Rust needs a web framework

#126

Post by LAC-Tech »

I'm struggling to see a usecase for rust. If I want to do something as high level as a web app, GC is fine. If I want to do something at the systems level, Zig is much more at home there.

And development in rust is glacial. It's no one language featurep (not complaining about the borrow checker in particular), but the accumulative overhead of all of them acting in weird ways.

I will say the tooling is absolutely amazing, it's nice to span "app level" and "systems level" concerns in a single language. But it is a lot of language.

Re: Rust needs a web framework

#127

Post by neonsunset »

slashink wrote: post #105
wongarsu wrote: post #24

Earlier quoted context omitted.

This is definetly something the article should have drilled down on. Why Rust? I'm sure everyone's tired of hearing why rust is an excellent alternative to c/c++ for new projects, but as an alternative against Python it gets muddier. Rust has a clear advantage in performance and memory footprint and a much better multithreading story, but those are things that aren't high priorities for 95% of web development. That b…

For what I hack on I often run into issues with the FFI performance between go/c# c/c++. I’d rather not write C or C++ and Rust is one of the few languages that allows me to mess around with obscure libs at native performance and yet slap a web interface in front of it. cxx/bindgen is stellar in how fast they allow you to wrap libraries. These cases is where I would want like the simplest most opinionated web framewo…

FFI can be a source of performance issues in Go but not in C# (at least not to the same extent), unless you go out of your way to fight the happy path approach.

Sometimes you do have to rethink what you marshal vs what you just manage manually, but that’s what pointers are for (that can be turned into ref Ts for single values and into Spans for slices/arrays/etc). The idea is that performance ceiling of FFI in .NET is as cheap as direct calls.

Re: Rust needs a web framework

#128

Post by bigiain »

sublinear wrote: post #96

I guess I'm just "weird" for thinking the laziest and least error prone way to write a web app is in plain javascript? Any framework is too much extra work to learn and going to eventually get you shot in the foot.

I think there's a scale/complexity thing to be considered.

If your web app is simple, then frameworks and "safe" languages are unnecessary.

At some stage though, that flips around. There's no way I'd choose to write, say, gmail or Trello in "plain javascript". The learning curve of a suitable framework for projects like that are well worth the eventual productivity, and the number of feet to shoot in your project will way exceed the number of feet added by the framework, and hopefully the framework will prevent way more foot shooting opportunities than it adds.

Re: Rust needs a web framework

#129

Post by cmrdporcupine »

CharlieDigital wrote: post #100
troad wrote: post #87

Earlier quoted context omitted.

I am a fan of Rust for systems programming, but so many people are using Rust for things that are nothing even remotely close to systems programming. So many projects you see being written (or rewritten) in Rust are projects where I just think 'wait, why can't this just have a GC'? And then you look at the code base, and it's all Arc >s, and you can't help at marvel at this, since that's just GC, so what's the benefi…

> 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

Re: Rust needs a web framework

#130

Post by fallingsquirrel »

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

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 traits with TS's type-erased generics. Since the feature sets aren't the same, I suppose it's a matter of opinion which type system is preferable. But I know which one is more helpful for me for sure (especially considering the aforementioned soundness issues).

Post reply on HN