3 ms·
Yeah--so, Rust's mission is memory safety without garbage collection. Is there ever really a situation where you need to write a web service but cannot afford
by kyllo 11y ago
Yeah--so, Rust's mission is memory safety without garbage collection.
Is there ever really a situation where you need to write a web service but cannot afford garbage collection?
Rust is a really cool and novel language. I considered learning it, but since I mostly program web apps and services, I decided to go with Haskell instead. it has much better performance than dynamic languages, but is still garbage collected, because managing memory manually in my code seems like a wasted effort.
I chose Haskell rather than Go just because I like functional idioms, but you could just as easily replace Haskell with Go in the above paragraph.
I mean, I guess the fact that you can write a web app in Rust is cool, I just don't understand why you'd really want to, when there are languages like Haskell and Go (and Nim and D...) that give you fast binaries and garbage collection.
- jpgvm 11y agoThe only real time Rust would be better due to lack of garbage collection is when you need performance consistency. It might be better than some of those languages for other reasons though. For instance I think Rust is more expressive than Go. I think it's easier to learn and more practical than Haskell (though I do enjoy me some Haskell too) and I think it has better tooling than all of those mentioned (except Nim, I don't know enough about Nim to pass judgement).
- aethertap 11y agoI've been writing a web app in rust for a while now (using a different framework though, iron's ergonomics didn't suit me for some reason). Overall I've found it a pleasant enough experience. The reason I like the it is that I write code for a wide variety of domains, from web apps to compilers, and so far rust has been a decently usable language in all the domains I've tried it in. I really like the "one language to rule them all" aspect of it because it simplifies my life - chances are good that whatever problem I'm looking at will either be trivial enough for shell scripting, or will be amenable to a rust-based solution. Narrowing down the language set seems like it could also lead to some interesting interoperability potential, like an easy web UI for a disassembler library or something. I still use half a dozen other languages on a regular basis, so the dream of being able to really focus on just one is still just a dream. However, rust is getting closer, and I'm gradually migrating most of my work to it when the choice is up to me.
- yokohummer7 11y agoIf you can write programs without garbage collection, why should you use it? Because using it makes your life easier? To me, Rust is easier to use than both Go and Haskell. Regarding Go, I don't like its inexpressiveness. Regarding Haskell, I'm tired of its various aspects like 1. Insane defaults. `String` being `[Char]`, `-Wall` is almost always necessary, no record types, `import` imports all names by default, etc. Haskell is clearly showing its age. 2. Lazy evaluation. Not only does it complicate inspecting what's going on, but also it leads to memory bloat. Don't say you can manage it easily. I had tried that. 3. No stack trace. No, enabling profiling won't help, because thanks to lazy evaluation the exact location of the error will not be given to you. So, to me, Rust feels like a "saner Haskell". Having a trait system similar to Haskell's type class, but without many of its warts. That said, if there's a mainstream language that is more similar to Haskell but uses strict evaluation, I will definitely be sold. Idris is one of the contenders, but it isn't quite mainstream yet.
- MichaelGG 11y agoThe most mainstream lang similar to what you're talking about is F#. Excellent tooling support; lots of libraries via .Net, and a reasonable ML with some fun stuff like active patterns. Web dev can use the ASP.NET stack or F# specific stuff like WebSharper (cross compiler to JS, plus web framework).
- yokohummer7 11y agoYeah, actually I recently installed Visual Studio and wrote some elementary F# code. Seeing the IDE and the debugging facility work out of the box was quite pleasant. I'm also sure I could get advantages from the huge .NET ecosystem, although I have no idea where to start because I haven't used MS products until recently. MS's recent open sourcing move made me think about liking and using their products. That said, I have a few concerns before actually being sold to F#. 1. F# must interact with the remaining of the .NET ecosystem. So, I think F# may have some interoperability features to ease the process. Wouldn't that increase the complexity of the language? This is a similar concern when I evaluate Scala as an alternative to Haskell. The feature set of Scala looks a bit messy to me, nearly on a par with C++. It could be OK if I use only the "functional" subset of the language. But does it really make me free from e.g. null pointer dereferences? 2. Do F# guys actually develop their "native" libraries not relying on the .NET ones? This is similar to #1 but slightly different. I think if the two languages are somewhat similar, and even share the ecosystem, there may arise a tendency to make libraries that work on both languages. But if one makes a C#-focused library it must not be very easy to use in F#. Is this not a concern in the F# community?
- bad_user 11y ago> Is there ever really a situation where you need to write a web service but cannot afford garbage collection? Yes, anything that has a real-time requirement.
- kazagistar 11y agoDoesn't the latency of connecting over the web make it unsuitable for real-time anyways?
- nitrogen 11y agoSometimes the important criterion for "realtime" is jitter, rather than latency. GC means jitter (inconsistent or unpredictable delay).