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

311–320 of 395 posts

Re: Rust needs a web framework

#311

Post by pjmlp »

MrJohz wrote: post #309
pjmlp wrote: post #265

Earlier quoted context omitted.

A unit test has nothing to do with a REPL, a proper REPL provides something similar to jupiter notebooks in feel, alongside debugging and hot code reload experience.

Maybe we have different understandings of REPLs. For me, a REPL is a tool that I can use to try out some portion of my code, see how it responds to various inputs, see how it handles certain cases, and explore the internals of it via debugging tools. But... that's what I do in a unit test anyway. A unit test is essentially a REPL session that I've frozen in time, can replay whenever I want, can debug, can trigger a f…

For me the REPL is the experience similar to Lisp Machines, Smalltalk kind of experience, which is loosely captured in Jupiter Notebooks.

As for unit tests being more usefull, depends on how much one is willing to wait for them to run in Rust, given its compile times.

Re: Rust needs a web framework

#312

Post by pjmlp »

fweimer wrote: post #249
saghm wrote: post #148

Earlier quoted context omitted.

> What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that…

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.

Re: Rust needs a web framework

#313

Post by pjmlp »

smolder wrote: post #287
mike_hearn wrote: post #254

Earlier quoted context omitted.

> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? Popular languages don't really have evangelism or fans pushing it aggressively. Those are traits of smaller languages that don't interop well with other ecosystems so they need a lot of evangelism to build out the library ecosystem. > there's a space for a higher-level language with most…

Rust makes an '.exe', Java makes a '.jar'. I think people want to write programs that run on an OS rather than an interpreter.

Java compilers have been producing '.exe' for about 20 years now, it is a matter to actually care to learn about their existence.

Re: Rust needs a web framework

#314

Post by pjmlp »

immibis wrote: post #310
kaba0 wrote: post #295

Earlier quoted context omitted.

For the majority of executing code, there is no fundamental difference when it comes to a JIT compiler. Besides, GraalVM can produce a native executable for pretty much any JVM language/program.

The problem is friction. To run a rust app you can just run it. To run a java app you need to install java first. This is no problem for backends running on servers, but client apps (like Minecraft) have to include their own JVMs to reach a wider audience, and this solution still introduces a bunch of complexity.

Not a thing since Java 9 and jlink introduction, or since those commercial AOT compilers exist, for 20 years now.

And if free beer is your thing, GraalVM native image or OpenJ9 also produce a regular executable.

Re: Rust needs a web framework

#315

Post by kaba0 »

ActorNightly wrote: post #138
tkzed49 wrote: post #83

Earlier quoted context omitted.

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

Types [1] can only reason about categories of values, not about values. Tests and types do have an overlap, but the best option is both. Especially when combined with fuzzing, types can exclude large number of cases, making it even more efficient at covering a huge range of code paths.

[1] yeah, there are type systems like lean, coq that can do both, but the proving process is just currently not realistic for everyday applications

Re: Rust needs a web framework

#316

Post by pjmlp »

Galanwe wrote: post #243
saghm wrote: post #148

Earlier quoted context omitted.

> What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that…

> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? I think Rust is especially popular with a demographic that was not previously exposed to lower level programming. Meaning younger programmers (because modern languages are higher level) and web centric programmers (because we're in a boom of web development). This demographic had a hard t…

Having learnt C in high school, and doing Z80 Assembly prior as a 12 year old kid, only with a bunch of books from the local library, it is kind of interesting to read about fear and hard regarding C.

Yes it does corrupt memory, there are some crashes, I usually bash C, nonetheless it seems we have too much "safety playground" regarding learning processes nowadays.

Re: Rust needs a web framework

#317

Post by marcosdumay »

PedroBatista wrote: post #42

Possible unpopular opinion: Rust is a systems language, doing "web work" in Rust is a waste of effort as there are much better languages and ecosystems for that.

I do almost completely agree. But I just want to point out that the intersection between system programming and web programming is not empty.

Neither is the intersection between embedded programming and web programming.

But either way, if something like Django, .Net, or go is an option, Rust is probably a bad idea.

Re: Rust needs a web framework

#318

Post by capitainenemo »

hobofan wrote: post #207
paulgb wrote: post #3

I was surprised not to see Rocket ( https://rocket.rs/ ) mentioned among the frameworks the author listed; I haven’t used it myself because I _like_ the more unopinionated axum/actix-web, but as I understand it its goals are much more in the vein of what the author wants in a batteries-included framework and it’s been around for a while now.

While Rocket was one of the earliest Rust frameworks that really pushed for good UX (via proc-macros), I think it has largely fallen out of favor in many parts of the community. For a very long time it required nightly Rust versions to build, which is a no-go for many people wanting to use a framework in a production setting. Also for a period of ~2 years it was stuck in a 0.5.0 release candidate limbo where the late…

When I asked them about that 2 year limbo, they said the release candidate was feature complete, and simply had incomplete documentation (also some plans for a new management structure).

So, it wasn't actually lagging, it had that async for quite some time... But yeah, being in a "release candidate" did scare people off.

Re: Rust needs a web framework

#319

Post by stefs »

berkes wrote: post #226
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…

> that are nothing even remotely close to systems programming This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably. Sure, rust is primarily a language aimed at systems programming. But it also is so much more (and also a cult). * Its type system is excellent. Especially the lack of a "null". Even if, like me, you're fine with a GC, th…

a few months ago there was an article linked here on HN (iirc about rust game dev) that argued that while rust is great, it's virtue of being mostly correct every time can also be a weakness.

the argument was that in early dev and prototyping phases you don't want to write good, clean, correct code but move fast and break things while not caring about edge cases - and this, the author argued - is relatively hard in rust.

making the good way the _relatively_ easy way

Re: Rust needs a web framework

#320

Post by CharlieDigital »

antonvs wrote: post #277
pjmlp wrote: post #211

Earlier quoted context omitted.

Easy, stay with .NET standard tools, MSBuild. There is also Visual Studio and Rider.

> stay with .NET standard tools That’s a dealbreaker in many situations.

If you haven't used .NET since the early 2000's, I'd recommend checking out current `dotnet` CLI and tool chain.
Post reply on HN