Earlier quoted context omitted.
Technically you can get the convenience of not needing to write async/await, with the same runtime implementation decisions underneath as Tokio/futures. Kotlin is an example of this approach- its coroutines are state machines but with implicit awaits. This can even be extended to "awaiting across function calls" with effect polymorphism. I haven't seen this done in this context, but it would allow things like passing…
I have been meaning to dig into Kotlin's implementation, thanks for that! Is there any good reference documentation to dive into? Most of the stuff I saw was from a user's perspective.
How Rust Is Tilde’s Competitive Advantage [pdf]
71–80 of 127 posts
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#72Earlier quoted context omitted.
Technically you can get the convenience of not needing to write async/await, with the same runtime implementation decisions underneath as Tokio/futures. Kotlin is an example of this approach- its coroutines are state machines but with implicit awaits. This can even be extended to "awaiting across function calls" with effect polymorphism. I haven't seen this done in this context, but it would allow things like passing…
> 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.
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#73So, 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…
1. VS Code with the Rust plugin along with rustfmt and the rls is great - when it works. I've had some issues now and then, but the tooling is pretty great. 2. Not qualified to answer this 3. There's a ton of rust libraries out there. The whole cargo ecosystem is quite nice. Coming from a C background (and dabbling in lisp), I love Rust. It's C with batteries and concepts from functional programming - iterators, immu…
I've been using VS Code and WLS to execute the Ubuntu version of Rust from the bash console in VS Code. I'm not sure if this is a good method or not... but it feels very natural.
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#74> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?
I call bullshit. Most probably their Java code was FUBAR.
> Most probably their Java code was FUBAR.
And so what? If a language's natural form leads to FUBAR code, what else is to blame?
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#75Earlier quoted context omitted.
5 times the memory is a serious exaggeration. At least twice, but no more than 3x.
The linked Wikipedia page references a OOPSLA 2005 paper by Matthew Hertz and Emery D. Berger that presents data saying that with 3x memory you might reasonably expect a 17% slowdown when compared to manual memory management. (And 70% slowdown when limited to 2x memory.) Of course there have been some advanced in GC technology since 2005 (and that paper was deliberately measuring a relatively standard generational ap…
Yes I've read the paper. Advances in CPU microarchitecture alone have noticeably shrunk that gap. There have also been significant algorithmic advances in GC. For instance, a few simple prefetching hints speed up marking easily by 30%, and parallel marking scales almost linearly with core count, to mention but two simple performance improvements.
So like I said, maybe in 2005 a 3x memory overhead only incurred 17% slowdown, but 3x overhead is at least at par, and possibly even a little ahead, of manual memory management.
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#76So, 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…
Neat, what is your use-case for OBD-II data? I've been investigating ways to get data from a race car back to the pit crew via something like a raspberry pi.
For the radio component - I suggest that you build a "block" of useful data and send that several times using very good Hamming (error correction) instead of error detection. If using wifi then consider UDP.
You'll get better range out of something proprietary, I've had success in the 915 Mhz band. A spread-spectrum approach is better if possible.
Ideal would be if the car assumes it cannot receive anything and attempts to send each block several times before beginning to transmit the next block. Another approach could be to send a window of blocks each time.
Receiving outside the car is likely to be much easier - a large antenna can be used away from all interference. An option could be a human operator holding a directional antenna, visually tracking the car.
You might also store the blocks within the car for later 100% accurate download.
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#77Earlier quoted context omitted.
Neat, what is your use-case for OBD-II data? I've been investigating ways to get data from a race car back to the pit crew via something like a raspberry pi.
Right now I just want to get more fine-grained data about my mileage. But maybe add some automation into the mix later on (remote start, etc.).
Ensure your remote-start doesn't turn into a remote-stop and a crash.
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#78I've come to realize that the main thing that is making me procrastinate giving Rust a proper go is entirely superficial at this point. Basically it looks like a "clever" programmers dream language - which is usually not my cup of tea. I'm also worried that larger projects ("real-world" projects, so not projects like Servo) will inevitably become an illegible mess when clever programmers makes the most of a clever la…
May you always work with clever programmers who make clever code simple.
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#79Earlier quoted context omitted.
> 2. Using a language for a large project without some kind of async/await notation seems painful And yet most of the software we use, billions of lines of code, from Chrome to Linux, from Photoshop to bind, and from Nginx to Skype, has been created without such notation. Somehow we've managed.
"Managed" and "seems painful" don't disagree with each other.
That doesn't make the assertion that you need async notation for any large project to not be painful any less ridiculous.
Re: How Rust Is Tilde’s Competitive Advantage [pdf]
#80Earlier 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…
> 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?