Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Rust Is Tilde’s Competitive Advantage [pdf]

rust-lang.org

Post reply on HN
Print view View original

91–100 of 127 posts

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#91

Post by Inityx »

disordinary wrote: post #46
Nelkins wrote: post #2

So, I've been eyeing Rust for a while and have messed around with it a bit in my free time. Here are some things I'd want to know before trying it out on a large project: 1. What development environment are other developers using with very large code bases? Is the tooling responsive? 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators f…

I just switched from VS Code to InteliJ and it's great. There's been huge improvements in IDE support recently.

Can you elaborate on the differences you've seen between VS Code + RLS and IntelliJ?

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#92

Post by tiuPapa »

tytytytytytytyt wrote: post #80
jabl wrote: post #41

Earlier quoted context omitted.

> Again, I use Rust and Go similarly in this post because Go is my frame of reference. I thought they were the same on this front, though. No? No. Rust used to have a green threads runtime like Go (and Erlang/BEAM, Haskell, etc.) but that was removed before the 1.0 release. So today, a thread in Rust is a heavyweight OS thread, like in C/Java and most mainstream languages.

The intro Rust book says you can easily find crates for green threads of you really want them. Is this not the case?

I am not entirely sure, it appears like due to the present status of std in rust, any green threads lib is prone to Undefined Behaviour whenever something uses Thread Local Storage.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#93

Post by disordinary »

Inityx wrote: post #91
disordinary wrote: post #46

Earlier quoted context omitted.

I just switched from VS Code to InteliJ and it's great. There's been huge improvements in IDE support recently.

Can you elaborate on the differences you've seen between VS Code + RLS and IntelliJ?

Sure, VS Code keeps randomly asking me to choose my toolchain even though a toolchain is chosen, closing it down and re-opening it fixes that.

InteliJ seems a little snappier, it's code completion a bit better.

The biggest benefit in day to day usage is the inline type hinting.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#94

Post by kbenson »

lmm wrote: post #44
notheguyouthink wrote: post #9

Earlier quoted context omitted.

> Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? Can someone explain to me what async/await is, in the context of a language like Go? I've used Rust a fair amount, but Go has been my native language for ~5 years now. With that…

async/await means you mark all your yield points explicitly; rather than having the runtime implicitly preempt you whenever it chooses, you mark the points at which task switching can happen, and at every other point it's impossible (equivalently it's as though any block of code that doesn't contain an "await" were a critical section). The syntax strikes a nice balance, making these markers as lightweight as possible…

> async/await means you mark all your yield points explicitly; rather than having the runtime implicitly preempt you whenever it chooses, you mark the points at which task switching can happen, and at every other point it's impossible (equivalently it's as though any block of code that doesn't contain an "await" were a critical section).

That's not how I understood it at all. I always assumed that it just promoted explicitly acknowledging when the effect of an async block would be present, but that the normal yield points (traditionally syscalls and IO requests in OS threads) generally still held for the actual execution of the other code.

I mean, if we aren't allowing separate code paths to execute (and thus reducing wait on resources such as IO), what's the point?

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#95

Post by laurencerowe »

dilap wrote: post #90
lmm wrote: post #44

Earlier quoted context omitted.

async/await means you mark all your yield points explicitly; rather than having the runtime implicitly preempt you whenever it chooses, you mark the points at which task switching can happen, and at every other point it's impossible (equivalently it's as though any block of code that doesn't contain an "await" were a critical section). The syntax strikes a nice balance, making these markers as lightweight as possible…

Having used both, I'd be pretty shocked if anyone found Twisted to be easier to reason about or less prone to bugs than Go...

Twisted predates async/await syntax in Python.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#96

Post by k6k7f7uky8ki »

knowtheory wrote: post #89
tytytytytytytyt wrote: post #88

Earlier quoted context omitted.

Yes, really. It's not the length, it's the density of interesting content.

Yeah man, learning to scan a paper for interesting content is definitely a skill worth developing!

And still not worth the time when the total interesting content is about 3 sentences long. I hope all that wit makes you feel better, though.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#98

Post by kazagistar »

Royalaid wrote: post #21
notriddle wrote: post #16

Earlier quoted context omitted.

Three things: * Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves. * Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code. * A tracing garbage collector needs about five times as much memory as explicit freeing to reach the…

Additionally things like Spring and dropwizard also add some overhead for better developer UX which rust doesn't have yet.

Dagger is a more efficient, simple, debuggable design for DI, and I fully expect to see similar compile time code gen DI in Rust soon. (Adding ownership, mutability tracing, possible stack allocation, etc does make things a bit harder to get right in this arena.)

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#99

Post by lmm »

kbenson wrote: post #94
lmm wrote: post #44

Earlier quoted context omitted.

async/await means you mark all your yield points explicitly; rather than having the runtime implicitly preempt you whenever it chooses, you mark the points at which task switching can happen, and at every other point it's impossible (equivalently it's as though any block of code that doesn't contain an "await" were a critical section). The syntax strikes a nice balance, making these markers as lightweight as possible…

> async/await means you mark all your yield points explicitly; rather than having the runtime implicitly preempt you whenever it chooses, you mark the points at which task switching can happen, and at every other point it's impossible (equivalently it's as though any block of code that doesn't contain an "await" were a critical section). That's not how I understood it at all. I always assumed that it just promoted ex…

> That's not how I understood it at all. I always assumed that it just promoted explicitly acknowledging when the effect of an async block would be present, but that the normal yield points (traditionally syscalls and IO requests in OS threads) generally still held for the actual execution of the other code.

Put it this way: the language implementation won't preempt you except at your explicit yield points (some standard library functions for things like I/O will and should be yield points that you have to call with async/await). If the language implementation happens to be running as a userspace process on a preemptive multitasking OS then it will still be subject to the same preemption rules as any other userspace process on that OS, but if anything this is usually counterproductive (e.g. priority inversions are almost guaranteed); recommended practice when working in green-thread-based systems is to run with one thread per CPU core and maybe even pin threads to cores if the OS lets you do that, because the language's own M:N scheduling will keep those threads fully occupied and OS scheduling is only going to get in the way.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#100

Post by lmm »

Rusky wrote: post #72
lmm wrote: post #42

Earlier quoted context omitted.

> I haven't seen this done in this context, but it would allow things like passing an async closure, or a generic type with an async trait implementation, to a normal function and having it automatically become an async function instead. I've done that a fair bit in Scala using HKT. E.g. superclass is written in terms of a generic monadic type, one subclass implementation uses Future (actually EitherT with Future), a…

Ah, right. I guess I have seen this sort of thing in Haskell then as well. When implemented with HKTs it usually gets really messy with things like monad transformers, so I prefer to think of asynchronicity more in terms of continuations.

I find monad transformers much clearer than continuations; a monad transformer stack tells you exactly how your effects are going to be interleaved, which is necessarily complex, whereas a continuation could be doing anything at all, the way I see it.
Post reply on HN