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

Is Rust Web Yet?

arewewebyet.org

Post reply on HN
Print view View original

51–60 of 183 posts

Re: Is Rust Web Yet?

#51

Post by steve_adams_86 »

tempest_ wrote: post #36
DelaneyM wrote: post #9

This content, while still accurate (Rust is Web-ready, and all the frameworks listed are excellent!), is missing out a few credible and recent options. In particular I want to shout out for Axum ( https://github.com/tokio-rs/axum ), from the folks who brought us Tokio. I've been building with it for the past few weeks and have enjoyed every minute. I started with Warp, but ended up struggling a bit with middleware. I…

I have been toying around with Axum a bit and it is nice as a web framework. I really appreciate the many examples in the repo. Having come from python (day job) I did hit a screeching halt when it came time to meaningfully interact with a database. It is unfair to compare Rusts current offerings to something as mature as SQLAlchecmy but boy does it slow things down dev wise to be mapping my own types and queries usi…

Although you do get the initial screeching halt, I’ve found having those types mapped out and with sqlx actually makes for a very nice and fast dev experience eventually. Having typed queries right in the IDE is pretty amazing.

Similar to typescript, where years ago I thought “but I just want to write code!”, now I can’t imagine going back. At least not for meaningful projects where I need to care about consistency and stability for more than a few months/for something critical.

The initial slowdown affords you a lot in the longer term.

Re: Is Rust Web Yet?

#52

Post by thesuperbigfrog »

est31 wrote: post #32
recuter wrote: post #15

Earlier quoted context omitted.

Because C is 50 years old and boring. And Rust is slightly more intellectually demanding and takes longer to get into so has a a smaller monk like comm-- oh my god.

I'd argue that Rust is less demanding intellectually than C as you don't have to constantly worry about UB. C is definitely easier to "get into", if by "getting into" you mean writing unmergeable contributions full of unidiomatic code and security vulnerabilities. C's age is not an issue in itself. The programming languages it replaced were ahead of C in many ways. It was a setback from a language design point of vie…

>> C's age is not an issue in itself. The programming languages it replaced were ahead of C in many ways. It was a setback from a language design point of view, even 50 years ago.

C takes a different approach to how it handles problems that was described well in "The Rise of Worse is Better":

"Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called PC loser-ing because the PC is being coerced into loser mode, where loser is the affectionate name for user at MIT.

The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.

The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix -- namely, implementation simplicity was more important than interface simplicity.

The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn’t understand (I’m not sure I do either).

Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language.

Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven’t they?

Unix and C are the ultimate computer viruses."

Source: https://dreamsongs.com/RiseOfWorseIsBetter.html

Re: Is Rust Web Yet?

#53

Post by DixieDev »

whb07 wrote: post #4
DixieDev wrote: post #3

"Rust has mature and production ready frameworks in Actix Web and Rocket" Why is Rocket considered production ready when it's only just at version 0.5? Similar <1.0 stories can be found on crates for sqlx, rusqlite, and postgres. Am I wrong in assuming the API must be quite stable before it can receive the 'production ready' label?

That’s correct, the creator has been uber meticulous and methodical in his versioning and using stable Rust parts.

I feel like they should probably advertise this fact somewhere, as I couldn't find it in their docs, website, or readme, and it is quite a significant detail.

Re: Is Rust Web Yet?

#54

Post by TheDong »

LAC-Tech wrote: post #45

I spent about the past month learning rust - and decided it just wasn't a usable language for me. I think what it comes down to is that I'm just not that into bondage and discipline from a compiler. Yes, I know, it's trying to make my code 'safe', and I'm horribly cavalier and I should feel bad, but: 1. the borrow checker rejects valid programs, has a lot of corner cases it can't catch, and is in active development 2…

> 3. people routinely freak out about 'unsafe', which is a bit much given the first point [borrow checker]

It sounds like you're making a common misconception here. unsafe code and the borrow checker are not closely related, and unsafe blocks are not a way to play fast and loose with ownership issues. See https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...

If you don't want to deal with the borrow checker, the solution isn't unsafe, it's Arc, Clone, RefCell, etc.

Re: Is Rust Web Yet?

#55

Post by CraigJPerry »

Waterluvian wrote: post #27
jackblemming wrote: post #11

Can some explain why I always get cult like vibes from the rust community?

Imagine your job is hammering nails. Eight hours a day for twenty years. You’ve hammered 403,286 nails. And then someone shows up and hands you a nail gun. Rust makes me happy because we speak the same language. Stuff gets done and I go home at 4:30 and play with my kids instead of my compiler.

Someone hands you a waffle head hammer seems like a more apt comparison.

If you can get the hang of it, it’s a safer hammer. You’re still going to be manually managing your memory allocations though. The nailgun people have garbage collection (and yes for the gc folks, I’m aware you can still write allocation free code, or at least take manual control of allocations in a garbage collected language and therefore opt out of garbage collection overhead - but why would you unless there was a performance issue)

Re: Is Rust Web Yet?

#56

Post by mindwok »

avl999 wrote: post #42
api wrote: post #28

Earlier quoted context omitted.

Go has a fat VM with GC. It’s great for lots of things but is not a systems language.

People are writing production level databases, distributed systems in Go... ofcourse it's a systems language unless your definition of a systems language is something super narrow.

There’s some places you can’t use a language with a large runtime like Go. For example, operating system kernels, real time embedded systems, game engines, anywhere you want to be extremely careful about memory allocations. You can write go for most of these use cases as toys and demonstrations, but this is where languages like C dominate and Rust/Zig are making inroads because of the ability to execute on bare metal with no runtime.

Re: Is Rust Web Yet?

#57

Post by NavinF »

41b696ef1113 wrote: post #26
jeroenhd wrote: post #8

> Yes! And it's freaking fast! Going by these benchmarks (click around to find your own use case) Rust is definitely fast, but not (much) faster than many other languages, including Javascript. https://www.techempower.com/benchmarks/#section=data-r20&hw=... When it comes to JSON serializers, there is a Java framework that is faster than Rust, which is interesting to say the least. When you start comparing actual full…

Not that I think those metrics are all that relevant, but can someone explain to me how just-js ranks so highly? Very much defying my expectations in comparison with some of the top representatives of compiled languages.

Not sure, but it’s pretty funny how the most popular frameworks (rails, Django, flask, laravel, etc) are way at the bottom with 3% the score of the winner.

Apparently async db requests and batching transactions are the key to winning on that benchmark: https://news.ycombinator.com/item?id=24315512

I wish more benchmarks would produce latency vs requests/second curves in microseconds. I bet the latency is massive due to batching.

Re: Is Rust Web Yet?

#58

Post by LAC-Tech »

ReaLNero wrote: post #48
LAC-Tech wrote: post #45

I spent about the past month learning rust - and decided it just wasn't a usable language for me. I think what it comes down to is that I'm just not that into bondage and discipline from a compiler. Yes, I know, it's trying to make my code 'safe', and I'm horribly cavalier and I should feel bad, but: 1. the borrow checker rejects valid programs, has a lot of corner cases it can't catch, and is in active development 2…

> the borrow checker rejects valid programs Yup, this is the tradeoff you have to make to catch the wide variety of bugs. For personal use, probably not worthwhile, but it definitely pays off for the safety it provides in production contexts. The way I view Rust's philosophy is "it's better to catch bugs at the compile stage than at the execution stage".

One charitable way to view Rust's philosophy is that it's better to catch bugs at the compile stage than at the execution stage.

In theory yes. In practice, getting to the execution stage was such a slog that it rarely happened.

Would have liked it a lot better if the borrow checker had the option to be -Wall instead of -Werror.

Re: Is Rust Web Yet?

#59

Post by heavyset_go »

avl999 wrote: post #42
api wrote: post #28

Earlier quoted context omitted.

Go has a fat VM with GC. It’s great for lots of things but is not a systems language.

People are writing production level databases, distributed systems in Go... ofcourse it's a systems language unless your definition of a systems language is something super narrow.

When I think of systems languages, I think of languages that are suitable for all of those use cases, but also for writing operating systems and code for embedded microcontrollers. Writing a kernel in a language with garbage collection is possible, but would it really be optimal compared to writing a kernel in other languages without it?

Re: Is Rust Web Yet?

#60

Post by ibraheemdev »

41b696ef1113 wrote: post #26
jeroenhd wrote: post #8

> Yes! And it's freaking fast! Going by these benchmarks (click around to find your own use case) Rust is definitely fast, but not (much) faster than many other languages, including Javascript. https://www.techempower.com/benchmarks/#section=data-r20&hw=... When it comes to JSON serializers, there is a Java framework that is faster than Rust, which is interesting to say the least. When you start comparing actual full…

Not that I think those metrics are all that relevant, but can someone explain to me how just-js ranks so highly? Very much defying my expectations in comparison with some of the top representatives of compiled languages.

If you look at the techempower submission source code you'll quickly see why: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast....
Post reply on HN