4 ms·
Rust needs a prototyping/scripting/application language on top of it, with 80% of the speed and 99% of the safety, with automatic memory management (reference c
by dkarl 3y ago
Rust needs a prototyping/scripting/application language on top of it, with 80% of the speed and 99% of the safety, with automatic memory management (reference counting or GC) and at least one idiomatic way of doing concurrency that disallows sharing mutable state. A language that is tailor-made for building applications quickly on top of the Rust ecosystem, with a build tool that gracefully handles mixed projects if you need to build part of your application in Rust, and support for writing small shebang scripts.
Also, I'd like a pony, a jetpack, and VIP passes to the premiere of Dune: Part 2.
- tikhonj 3y agoI've worked on a Haskell + Rust project that followed roughly the dynamic you're describing and was pretty happy with it. I wrote some simple tooling that let us share algebraic types between the two to manage our interfaces and it worked pretty well. In our case we needed to serialize/deserialize data between our components so the interfaces were at a bit of a distance, but, in principle, it would have been totally doable to extend the same kind of tooling to provide a legitimately easy-to-use FFI layer between the two languages. Haskell is a bit of a tricky language organizationally for mostly social/political reasons, but if I end up starting my own company in the future, Haskell + Rust is definitely the tech stack I'd lean towards.
- Qworg 3y agoI made the call between Haskell and Rust for my fintech startup. I chose Rust when I realized how few Haskell programmers there were available to hire - at 20 engineers, we'd be one of the largest shops on the West Coast of the US AFAIK. That said, we were one of the largest Rust shops outside of the FAANGs, but Rust was straightforward to teach to C/C++ folks.
- tikhonj 3y agoWe actually had the opposite experience in hiring for our Haskell team: it was substantially easier to find legitimately strong engineers for Haskell than for other teams using Python and Scala. I figure it comes down to two things: 1. A lot more people want to do Haskell than there are Haskell jobs 2. Haskell is an easy way to signal (show not tell) that our team is willing to do things differently—especially important because our team was at Target, which did not have much of a reputation as a tech employer! We didn't try hiring Rust programmers because the existing Haskell folks were more than happy to pick it up. So making hiring easier is one of the reasons I'd want to use Haskell, counterintuitively!
- Qworg 3y ago! Amazing. I had seen so many strong Haskell teams that Rust seemed like the play, for the same reasoning. I'm glad it worked out for both of us.
- iknowstuff 3y agoI think you’re describing Swift
- suby 3y agoThis would infect the language ecosystem. People that use Rust are usually using it because they don't want the performance sacrifice that gc or reference counting would bring. I am convinced that one of the reasons D did not catch on is because it had gc, an anti feature for the target demographic. You could disable it but it split the community and some of the standard libraries weren't compatible. Moreover, just about every mainstream language has automatic memory management. There are plenty of choices for those that want that, Rust is really the only mainstream choice for its niche so it's for the best to not try to turn it into something else.