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

341–350 of 395 posts

Re: Rust needs a web framework

#341

Post by capitainenemo »

appplication wrote: post #337
capitainenemo wrote: post #332

Earlier quoted context omitted.

Can you elaborate? They seemed pretty responsive to me every time I asked for assistance in the channel... (we'd implemented something in 0.4). If "incomplete documentation" is "unserious" that would be the large majority of open source libraries. Actually blocking on completing it sounds like they were taking the release seriously to me. And I understand it taking a while. No one likes writing documentation.

I’m viewing it from the perspective of being a user who is blocked by a feature or bug fix that has been implemented for 2 years and not released. How do you trust the feature/bug fix cadence moving forward? It’s not like users can’t run release candidates in prod, but there are many reasons not to, and good policy guides against this. I used to be an ardent supporter of Uber’s h3 geospatial library. But we’re runnin…

Well. In this case it's almost a labeling thing. You could make an exception for this (maintained) release candidate if in your judgement incomplete documentation (basically rust doc stubs for a significant percentage of the libraries) was (not) a blocker.

In some places we were told to never use libraries that weren't 1.0 - obviously that would be bonkers in the rust world. In these things you really have to use your own judgement...

I don't feel like their decision to make documentation a release blocker shows disrespect for the users. They were repeatedly clear that it was safe to use and feature complete. They did note the shift from a single man project to a foundation governance took longer than expected and was part of the release as well, but, you know, non-code stuff like that also takes longer.

Re: Rust needs a web framework

#342

Post by pjmlp »

fweimer wrote: post #330
pjmlp wrote: post #312

Earlier quoted context omitted.

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.

I don't think constructors are the challenging part. It's about lexically scoped destruction. Certainly there are languages that have that and permit garbage collection, however those constructed values are necessarily second-class citizens and behave somewhat differently than ordinary values. There's probably some reasonable middle-ground, like constructors returning an owned reference that explicitly can be turned…

And those languages do offer lexical scoped destruction.

They are only second class in the context people put all GC languages on the same basket, and rather go for the X rewritten in Y blog posts.

Because apparently adding newer languages to CV is cooler than mastering the one they have.

Re: Rust needs a web framework

#343

Post by palmfacehn »

stefs wrote: post #244
palmfacehn wrote: post #231

I wouldn't mind a Rust based web framework that provides the same features as the base Servlet API. Everything else should be an optional library. When I look into it the rabbit hole goes too deep. It hasn't been immediately clear what the templating looks like. Usually they start talking about some "Reactive" framework, features I don't want and I lose interest. Afterwards, I realize that I'm already satisfied with…

just out of curiosity: why commons db connection pooling instead of hikari? i've only ever used the latter.

I've been using version two for a long time now. It just works. I hadn't heard of Hikari until now.

Re: Rust needs a web framework

#344

Post by kaba0 »

bsnnkv wrote: post #92
throw10920 wrote: post #84

Earlier quoted context omitted.

> I'm an incredibly lazy developer and Rust only makes me lazier You can't be that lazy, or you would use a language that doesn't force you to do memory management. > Rust is the only language where I can open something like Notepad without an LSP or highlighting This is a very weird and arbitrary qualifier that seems designed to filter out other languages with type systems.

> force you to do memory management This is not my experience at all. I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice). Your second comment is a very weird sentence that is very difficult for me to grok.

A better metric for whether you think about it or not would be at refactor time.

In Java, you can just move something around in any way or shape, change its lifetime semantics very liberally (e.g. make it have a single instance, or make every thread have its own, or make it have its own instance of X as a field, or just use a shared one), and it will compile without a word and the runtime will handle it.

In rust, in my experience (though it is surely significantly less than Yours), these kind of refactors actually require code changes at almost every location, and might recursively cause further such issues. I think there is a sort of bias here as well, that people kind of like this kind of refactor where the tooling readily shows you the exact error and it may not be too difficult to solve each case, so this might not register as annoying, but quite obviously a stricter lifetime system will have to have some downsides as well.

Re: Rust needs a web framework

#345

Post by saghm »

mike_hearn wrote: post #254
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? 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…

> 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

> What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin?

I'd argue that Rust has better interop with C, C++, JavaScript, Python, Ruby, and probably almost every other non-JVM language than Java and Kotlin. I'm not sure why you think that getting people to write more libraries is the goal of evangelization; if anything, I think Rust is somewhat notorious for people writing lots of libraries but comparatively fewer full applications.

Independent of interop (which I'm not really sure is as important to understanding why languages are or aren't popular as you seem to imply it is), I don't think the tooling in Java is nearly as beginner friendly as Rust. It's not just about the code itself; handling dependencies and building an application that you can run outside of an IDE are not nearly as straightforward in Java as plenty of other languages nowadays.

My point isn't that Java is bad or that doing things in it is hard in the absolute sense, but that "it's possible to do this in language X" is not the same as "it would be easy for a beginner to figure out how to do this in language X". I think there's an inherent lossiness in trying to distill what people like in a programming language into a bullet-pointed list of features, and it's an easy trap to compare those lists and conclude that one language doesn't have anything novel to offer based on that rather than the entire experience of working in a language.

Re: Rust needs a web framework

#346

Post by saghm »

pjmlp wrote: post #313
smolder wrote: post #287

Earlier quoted context omitted.

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.

> 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 unapproachable way easier to get started with than languages that don't prioritize that sort of thing.

Re: Rust needs a web framework

#347

Post by smolder »

pjmlp wrote: post #313
smolder wrote: post #287

Earlier quoted context omitted.

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.

Yeah, sorry. I was aware of that but was being loose with words. I do think that part of the appeal is rust feels more bare metal and direct to people even if they're using heavy abstractions as compared to Java/kotlin or C# programming.

Re: Rust needs a web framework

#348

Post by raxxorraxor »

Ygg2 wrote: post #340
raxxorraxor wrote: post #298

Earlier quoted context omitted.

Rust to me looks a bit like Java. "One owner per resource" is Rusts "One class per file". I am not convinced that the mental overhead justifies the memory safety guarantees yet. At least for a general purpose language. I didn't yet write a lot of Rust, perhaps more experience trivializes Rusts ownership model.

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

Re: Rust needs a web framework

#349

Post by jvanderbot »

demi56 wrote: post #164
kelnos wrote: post #91

Earlier quoted context omitted.

It would be great to introduce some competition there, then! (Not only because I think competition is good, but because I really do not enjoy writing Go.)

Nobody enjoys writing Go but there’s a reason do code in Go and we can’t ignore it

I write rust full time.

I don't see how people can "love" writing rust either. I love a lot of things about Rust and its ecosystem, but the syntax day-to-day isn't one of those things.

Re: Rust needs a web framework

#350

Post by berkes »

n8henrie wrote: post #308
biztos wrote: post #228

Earlier quoted context omitted.

I like Rust, but wasn’t “plopping” a binary onto a server and running it one of the original virtues of Go? Arguably a louder “plop” due to size, but then you don’t have to chmod.

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?

Post reply on HN