Rust needs a web framework
191–200 of 395 posts
Re: Rust needs a web framework
#192Earlier quoted context omitted.
The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towar…
Most of those people aren't aware that the type system is a feature from most ML derived languages since Standard ML is a thing. All of them with better ergonomics for Web development.
Do they really have better economics? (EDIT: ergonomics!)
Last time I looked into OCaml, I struggled to find a way to interact with the database in a type-safe way, I never figured out which standard library I was meant to install, I was being encouraged to use 2-3 different project management tools (Dune + Esy + OPAM), and I gave up on writing tests. But at least there's a garbage collector!
I realise these are all problems that I'll wrap my head around over time, and eventually they'll seem completely trivial to me, but the introductory documentation on getting started as a professional (and not as a first-year student doing a French-language compsci degree, which is what most of the documentation assumes), is pretty dire.
Meanwhile, much as I'm sure I overuse `.clone()` and `[A]Rc`, the ownership model of Rust is deeply useful. It's something I often find myself missing in Javascript - not necessarily because I want to produce the most performant code, but because it's useful to understand the lifetimes of the objects I'm keeping around. Am I accidentally storing a reference to something in a closure that I forgot about? When this object gets deleted, have I checked that it's the last possible reference to this object? Etc.
Like, I don't think everyone needs to learn Rust. It's a great language, but there's lots of other great languages out there, depending on your personal and business contexts. But I think this idea that Rust can and should only be a low-level language feels absurd to me. It is a fairly ergonomic language with a fantastic ecosystem, a powerful type system, and an ownership model that will be useful even if you do try and opt partly out of it with GC-like wrapper types.
Re: Rust needs a web framework
#193Earlier quoted context omitted.
The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towar…
> The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. TypeScript has an equally powerful type system. Python's type system is almost as good. Both have are significantly more productive when it comes to writing software, and have bigger ecosystems and lower learning curves. > It makes a lot of progress towards the goal of "make invalid states unrepresentable", which…
As someone who loves both TS and Rust: you couldn't be more wrong. TS is not even half as good at making invalid states unrepresentable.
A simple example of the (many) things you can't do in TS:
struct StateStart;
struct StateEnd;
impl StateStart {
fn foo(self) -> StateEnd {
StateEnd
}
}
fn main() {
let start = StateStart;
let end = start.foo();
let another_end = start.foo(); // this won't compile
}
I miss more features of Rust in TS that features of TS in Rust. All the time.
Re: Rust needs a web framework
#194"Right tool for the right job," no? Learn multiple languages. The whole "I want to do everything in the language I already know" is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
> Learn multiple languages
Not everyone wants to be jack of all trades - master of none or have time, energy or capacity to waste their life in hamster wheel of constant relearning of the same thing.
> is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
If they’re dominating our field they can’t be terrible by definition.
Re: Rust needs a web framework
#195So strange reading all the comments here saying that Rust is not a language for "lazy developers". I'm an incredibly lazy developer and Rust only makes me lazier. I can pretty much turn off the part of my brain that deals with "programming language" stuff and put all that energy towards the part of my brain that deals with "building stuff" whenever I write code in Rust, because I have a high level of confidence that…
> 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.
> You can't be that lazy, or you would use a language that doesn't force you to do memory management.
Eh, depending on what you're building you don't do much if any memory management in Rust. You just declare what you want and it's automatically released at the end of scope.
Yes I know the borrow checker. With experience it stops getting in the way while catching the occasional bug.
And no, building linked lists or recursive data structures are edge cases that you don't need to develop for most applications.
Re: Rust needs a web framework
#196I guess I'm just "weird" for thinking the laziest and least error prone way to write a web app is in plain javascript? Any framework is too much extra work to learn and going to eventually get you shot in the foot.
Least error-prone and JavaScript in one sentence, I’m not sure about that, to be honest. JavaScript alone without any types in a big project is a shot in the foot, let alone the quirks JavaScript has. Apps crash when a thrown error is unhandled, etc. I would say JavaScript is easy, but it’s definitely not the type for a least error-prone app.
Slap TypeScript on it.
Re: Rust needs a web framework
#197> I like to make silly things, and I also like to put in minimal effort for those silly things. I also like to make things in Rust… I think this part is perhaps the silliest part of a very silly article. If you really like to put in a minimal effort then why on earth would you use Rust? If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the stan…
From a technical point, you are absolutely correct. From a developer heavy business, it's a little more complicated.
If Rust had a good full-fledged web framework, it would enable more developers to justify why the business should use Rust. The culprit is that it would require a heavy education budget, but it would in turn enable the business to allow using Rust for other parts of the business which could benefit from Rust, e.g. middleware, small components, CLIs and systems programming in general.
Having a little bit of Python here, a little bit of Go there and a bit of Java elsewhere can become chaotic. There is a huge benefit for a small company to only have 1 programming language everyone agrees on using.
Re: Rust needs a web framework
#198Earlier 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…
Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless.
It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one?
I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.
Re: Rust needs a web framework
#199Earlier quoted context omitted.
> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. If you know that using global variable is often a bad idea, then you are, in some sense, worrying about lifetimes. I first learned this in the mid/…
> As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. Yes, to a much smaller extent. Rust's object lifetimes, for all the performance gains you get, add on a layer of additional cognitive and development overhead that is simply not present in memory-managed languages.
> Rust's object lifetimes, for all the performance gains you get
Lifetimes are not about performance gains. They're about correct behavior under concurrency, which you have even on JS with async-await.
Heck, let me correct that: even under programs without concurrency it's very easy introduce subtle bugs due to shared mutable state (something as simple as having a global mutable variable, you don't even need concurrency to mess that up, concurrency just introduces more issues like race conditions).
> cognitive and development overhead that is simply not present in memory-managed languages
No, the cognitive overhead is there, you're just ignoring it (and thus more likely to introduce subtle bugs).
If anything, Rust lowers the cognitive overhead by taking care of that for me statically at borrow check time.
Lifetimes are just types (literally). If you think lifetimes are cognitive overhead, so are regular types. Same argument could be used there since types are "cognitive and development overhead that is simply not present in dynamically typed languages". But I wouldn't write anything beyond a few thousand lines of code without them.
When I write Rust I spend more time thinking about types than about lifetimes.
Re: Rust needs a web framework
#200I am wondering why there is resistance to adopt GraphQL and a React-like front-end. Essentially, you no longer have routing/templating/web-server/etc... and you get lots of things handled for you (like authorization). You pretty much remove the web framework concept and just work directly on your application functionalities. With stitching, you have a gateway that add up various graphql gateways. So you could mix and match rust with other microservices or whatever.
I don't see myself doing it any other way these days.