Live data from Hacker News

Rust needs a web framework

ntietz.com

361–370 of 395 posts

Re: Rust needs a web framework

#361
post #350

Earlier quoted context omitted.

I much prefer rust to go for many reasons, but IME go gets this part much better. Darwin / Linux cross compilation, armv7, FreeBSD, oh sorry you don't have a linker for that toolchain, wait where are those OpenSSL headers... lots of cross-compilation targets I've done in minutes with go that scp and run right away that end up being days / weeks of adventures to cross compile in rust, in spite of me knowing rust much…

I have had the luxury to work in projects that don't have to target many platforms, but rather "one": a server. Which then is often a simple linux variant so setting up a CI or even the local build to target that "one" is relatively simple. But wasn't Go a lot more limited in the amount of targets it can build for than rust?

Yes and no -- obviously I can build for no_std targets like esp32 and atmega128p in rust but not go (haven't tried tinygo), but the proportion of targets that successfully built and ran IRL has been higher for me with go. On rust, the dynamic linking of libc (by default) and failure to include a linker with the toolchain have repeatedly been stumbling blocks, go "just works."

Re: Rust needs a web framework

#362

Earlier quoted context omitted.

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 th…

You can not test for the absence of behavior. You can design type systems to ensure the absence of specific behaviors.

What do you mean by absence?

Re: Rust needs a web framework

#363

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), Rust supports golang style message-passing concurrency if you want it[1]. I'd argue Rust mpsc channels are actually more powerful than Golang's and add richness to message-passing concurrency modeling. [1]: https://doc.rust-lang.org/book/ch16-02-message-passing.html

> I'd argue Rust mpsc channels are actually more powerful than Golang's

Do they support Go select functionality, buffered channels etc without using 3rd party libraries?

Re: Rust needs a web framework

#364
post #266

This article makes several different points that would ideally each be tackled on their own. You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need) Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily CSS/JS tooling makes no sense for many frontend Rust frameworks like Domina…

> You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need)

Web frameworks allow for much more: URL redirections, specific management of append-slash and case-sensitive URLs, complex regex matching, etc.

> Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily

False. Django, Laravel, Rails and batteries-included languages have really good auth management. I personally consider it a gigantic mistake in 90% of orgs to outsource auth to external parties.

The ability for experienced web devs to just hit the ground running and have 10 basic CRUDs running in a single day because they don't have to deal with this needless complexity is simply amazing for small businesses.

Re: Rust needs a web framework

#365
post #266

This article makes several different points that would ideally each be tackled on their own. You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need) Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily CSS/JS tooling makes no sense for many frontend Rust frameworks like Domina…

> You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need) Web frameworks allow for much more: URL redirections, specific management of append-slash and case-sensitive URLs, complex regex matching, etc. > Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily False. Django, Larav…

> URL redirection

Erm, just return a new url after the match? Get fancy with state machine like enums? Rust has everything you need here, not getting why you think this requires a framework.

> Specific management of [...]

again, match for that, map your url parts, whatever - it doesn't need a 10,000 pound gorilla when it can be done in a line or two of code

> complex regex matching

erm, regex crate?

> Django, Laravel, Rails

Yup, those are valid choices. I said it's not a framework problem necessarily.

Not a one size fits all sorta problem.

Wordpress is also a fine choice if your business is knocking out new sites for a new client every month.

But, if you're building a single product over the course of a year or two, it's not the end of the world to spend a couple weeks rolling your own auth and hook it up to transactional emails and everything else. It's just one small problem to deal with, not major in the grand scheme of things. YMMV

Re: Rust needs a web framework

#366
post #352
post #346

Earlier quoted context omitted.

> it is a matter to actually care to learn about their existence That's kind of the whole point I was trying to make above; if one language makes something super easy to do without having to look for instructions compared, that makes a difference in terms of how people will decide whether to learn it. Individually, lots of small quality of life things add up and can make a language that otherwise would be unapproacha…

I know learning is a chore, nothing like jumping into it without thinking. /s

If someone has two choices that can provide the same output, and one of them makes it more effort to figure out how to do, then people will do the other one more often. There's no inherent virtue is spending effort to do something equivalent. It's not clear to me why you seem to think that pointing this out deserves a sarcastic response.

Re: Rust needs a web framework

#367

Earlier quoted context omitted.

This is a very anti-pragmatic way of looking at things in my opinion. The program is not a snapshot that exists in a vacuum. Most programs are going to grow over time and have things added and removed in various places by many people. They're going to have many interfaces and operations. I think you're arguing that tests and types can both be used to check a particular case for correctness. Sure, this is true. Howeve…

So at one of my older jobs, we worked primarily with C code that ran on a mini linux box inside a plane, and interfaces with a sensor pacakge. We wanted to make sure that the software was 100% correct cause any errors would mean an aborted flight test We basically ended up creating a tool+language spec that would let us define the mapping of input to output sequences. We wrote it in such a way where we sat with scien…

Hey, that's awesome. Seems like a great case for verifying things that way! I'm thinking of different cases I think, where you've got something like a distributed system or a web application and it's just harder to fuzz. But I agree, that seems a lot more practical than formally verifying it when that's the kind of testing you need.

Re: Rust needs a web framework

#368
post #271

Earlier quoted context omitted.

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

Glad I noped out of this particular bad-faith subthread last night. I am pleasantly surprised to see however that this unfortunate subthread produced interesting and well-intentioned comments from others.

Perhaps consider not violating the literal letter of the HN guidelines:

> Assume good faith.

https://news.ycombinator.com/newsguidelines.html

You have no idea what's going on it my head, yet you choose to believe that you do as a result of me countering your arguments. This is a great example of why the Rust community has a bad reputation.

Re: Rust needs a web framework

#369

It really doesn't, actix is already there. Recently built my startup code over the past couple years with Actix and it had literally everything we needed easily. We just need more documentation and reference code bases demonstrating how to do these things. Rust devs tend to be fairly advanced and seemingly don't write enough docs or shares. >Routing/handlers Actix has it. >Templates Minijinja or liquid-rust[1] >Stati…

Her point is that she wants a batteries-included framework that comes with integrated choices for these out of the box, similar to Rails or Phoenix or Laravel, so that you can hit the ground running without spending the first few weeks of the project picking crates and gluing them together.

But these things are also gems in Rails the same way they are crates in Rust, no?

Re: Rust needs a web framework

#370

Earlier quoted context omitted.

> dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), Rust supports golang style message-passing concurrency if you want it[1]. I'd argue Rust mpsc channels are actually more powerful than Golang's and add richness to message-passing concurrency modeling. [1]: https://doc.rust-lang.org/book/ch16-02-message-passing.html

> I'd argue Rust mpsc channels are actually more powerful than Golang's Do they support Go select functionality, buffered channels etc without using 3rd party libraries?

What's wrong with using 3rd party library?

Can golang stop you from using a channel when it's consumed/closed?

Post reply on HN