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

351–360 of 395 posts

Re: Rust needs a web framework

#351

Post by Ygg2 »

raxxorraxor wrote: post #348
Ygg2 wrote: post #340

Earlier quoted context omitted.

> "One class per file". Wait. What? Neither Java nor Rust limit class/struct per file. You must mean public class per file. As a fellow Java dev, no it doesn't look like Java at all. Maybe it looks a bit like Kotlin, but only superficially. I wrote Rust on and off for 5 years, by that time you internalize the borrow checker.

I did mean one public class per file. I didn't mean syntax or core lib to be similar, I just generally meant that both languages impose restrictions on themselves which might seem sensible at first.

Java isn't that restrictive. Rust's type system is much more restrictive and customizable.

That said, a good way to think about programs is a series of restrictions, i.e. invariants. Truth be told, only Ada Spark so far really embraced invariants.

Re: Rust needs a web framework

#352

Post by pjmlp »

saghm wrote: post #346
pjmlp wrote: post #313

Earlier quoted context omitted.

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

> 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

Re: Rust needs a web framework

#353

Post by adamrezich »

saghm wrote: post #148
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…

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

A web framework doesn't need GC, it just needs some ability to express the idea that per-request code should get its own allocator, with knowledge of said allocator propagating down through function calls.

Jai solves this by having a "context", which includes an "allocator" member by default, whose default value is a standard heap allocator. You can override this allocator member to point to your own allocator, so it's easy and straightforward to have the main server procedure allocate a pool of memory, create a new context with a new allocator that uses this pool of memory, then "push" this context for the duration of the request resolution, then free (or mark for reuse) the memory pool afterward.

Re: Rust needs a web framework

#354

Post by berkes »

stefs wrote: post #319
berkes wrote: post #226

Earlier quoted context omitted.

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

I partially agree. It's not so hard to write software that keeps the borrow checker happy in early stages. But it does restrict the freedom to make terrible decisions a bit. Sometimes in that stage terrible decisions are OK.

But I do like that even in this stage, one is forced to at least make the decision to have terrible things, explicit. Like with 'unwrap()' and 'expect()' littering the code in PoCs and exploratory projects.

For me, a bigger problem in this stage is that I lack the information to make decisions on types. I have this same problem in TS and Java. It's guaranteed that I'll shape types in ways that will prove difficult, or slow me down a lot next week. I'll be spending time refactoring types when I should move on to the next feature.

I guess, but that's just my experience, that statically typed languages are just not well suited for early stage software. When we don't know the shape of the data we'll be pushing around, nor know anything about the shape of the layers, ports, modules and so on. Which is why I'll grab ruby for these kind of quick explorations often. And once the shapes emerge, rewrite it in rust :)

Re: Rust needs a web framework

#355

Post by super_flanker »

pjmlp wrote: post #177
fallingsquirrel wrote: post #108

Earlier quoted context omitted.

> TypeScript has an equally powerful type system. How does TypeScript's type system prevent shared mutable state?

How does Rust's type system prevent shared mutable state for out-of-process data common in distributed computing? It doesn't.

Just curious, which programming language allows preventing shared mutable state for out-of-process data?

Re: Rust needs a web framework

#356

Post by dougthesnails »

angra_mainyu wrote: post #82
dougthesnails wrote: post #62

Take F# for a spin. It offers nearly all of the type system tomfoolery one craves and all the tooling and nice-to-haves one wants. The big drag is that the async story and memory management aren't as big as a time vampire as Rust, so you do run the risk of actually solving business needs. I am sure some part of dealing with Microsoft can fill that void, though.

I've been on the fence w.r.t giving it a try. How does it compare to Ocaml and haskell?

It is Ocaml in all the ways that matter, but with .NET's async story/runtime/memory management, and tooling.

Re: Rust needs a web framework

#357

Post by echelon »

discreteevent wrote: post #324
echelon wrote: post #101

Earlier quoted context omitted.

https://www.youtube.com/watch?v=QrrH2lcl9ew > "We have at this point rewritten a large number of systems [..] have some very concrete things that we can say" > "When we've rewritten systems from Go into Rust, we've found that it takes about the same sized team about the same amount time to build it. [...] no loss of productivity when moving from Go to Rust." > "We do see some benefits [...] we see reduced memory usag…

> "When we've rewritten systems from Go into Rust, we've found that it takes about the same sized team about the same amount time to build it." A rewrite should be much faster than the original. Much of the original development will have had changes in requirements, refactors because of better understanding the problem domain, best structure for the code etc. A lot of that can be just 'copied' into the new system. Th…

> Much of the original development will have had changes in requirements, refactors because of better understanding the problem domain, best structure for the code etc.

Having written services in the Google style for years at a major fintech surrounded by Xoogler peers, systems design starts with a design document. You capture requirements upfront and solicit buy-in from the stakeholders. It's nothing at all like what you describe. You design the API and systems upfront without code (apart from capacity testing) and actual implementation happens quickly.

If iteration time was some "gotcha", Google would have made that footnote. That's not really how service development works in companies of this scale.

Translation time from design document to service is the same for Golang and Rust.

Re: Rust needs a web framework

#358

Post by ActorNightly »

tkzed49 wrote: post #184
ActorNightly wrote: post #138

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…

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 scientists and pretty much mapped all the possible cases that they could think of for valid inputs and what the code should produce.

Then this tool would basically write automated tests for us, in such a way as to not only test correct behavior, but also do combinations of inputs out of order, fuzz testing, and so on. We ended up making it also check memory state, to ensure that there was no memory leaks, and analyze the memory space for required data or data that should not be there.

In the end, whenever someone was developing anything for this software, they would basically just run the tests, and it would be very good at catching possible errors, mostly on the negative side (i.e for a fuzzed input, it would result in an output that should be an error).

We could have done the same thing with a typed language, but it would have to be very strict typing to the point of something like CoQ, and it would have taken us probably the same amount of time to write that.

Re: Rust needs a web framework

#359

Post by sn9 »

pjmlp wrote: post #178
echelon wrote: post #46

Earlier quoted context omitted.

Counter-point: developing web services in Rust is just as easy as doing it in Go or Java, yet you now have an excellent type system (sum types!), an excellent package manager, and extremely good performance. You can do dependency injection in Rust to share connection pools just like you would in Java, and it's super simple to write threaded background tasks. Google gave a talk recently that said they measured Rust de…

Anyone on JVM has already Kotlin or Scala for that. Likewise on CLR with F#.

These are measurably used orders of magnitude less than the flagship languages for those platforms.

Re: Rust needs a web framework

#360

Post by sn9 »

slowmovintarget wrote: post #322
drpossum wrote: post #234

Earlier quoted context omitted.

It is a refutation of the premise which invalidates this particular question as it was posed.

"Not every" is not the same as "none" and the discussion is about the majority, so I think your refutation is only of the absolute case and not of the original premise. Rust would be overkill for most web applications.

Performance is one thing but there's also maintenance costs and the cost of servers. Also potential for future scaling.
Post reply on HN