Brian, -- when you say "raw speed", do you need "Fortran" level speed for numerical algorithms or just "somewhat faster than Racket, almost close to C"? If it's the latter, Rust may work out for you.
-- when you say you need many cores for your computations. That sounds like very-raw speed, not just raw speed. This may call for C after all. -- then again, if it is just about trying to exploit the parallelism of your computer when possible, why not use places (or futures) in Racket? Yes, Rust's type system makes this a bit safer. It basically rules out race conditions via its type system. But this one depends on your take of how much you fear race conditions and how familiar you are with a mostly-functional approach of our CML library, which in my experience reduces this danger, too. -- if you opt for Rust, consider the callback problem. My (passive) experience with lots of code that has to set up call backs from C to Rust, is that this area is a bit problematic. I scanned John's blog post and didn't see how he addressed that, though I didn't read his git repo. Perhaps there are some examples there. And yes, in the end it's doable; it just seems to require a lot of fiddling. -- finally, beware of the need to drop from Rust to unsafe Rust -- where the type system just gives up the key innovations that Rust introduces. This is especially noticable for callbacks, but even other code (see John's) tends to include one or the other unsafe block. -- Matthias On Nov 19, 2015, at 5:37 PM, "'John Clements' via Racket Users" <racket-users@googlegroups.com> wrote: > >> On Nov 19, 2015, at 2:01 PM, Brian Adkins <lojicdot...@gmail.com> wrote: >> >> The more I dig into Racket, the more I like it. It seems like a perfect fit >> for both my personality and the type of applications I am, and will be, >> writing. For the vast majority of what I need to do, it's a great fit. >> >> I do occasionally encounter a need for raw speed, so I'm looking for a >> complement to Racket for those few times when it's not fast enough. I >> chatted briefly about this on IRC the other day, but I thought I'd tap into >> the collective wisdom on the mailing list. >> >> I'm open to suggestions, but I've tentatively narrowed the list down to Rust >> and C. I programmed in C/C++ for about a decade, then Java for a decade, and >> most recently in Ruby for a decade, so it's been a while since I was an >> expert C hacker, and my recent Ruby experience has lessened my polyglotness >> :) >> >> If I were to do a *lot* of lower level coding, I think the niceties of Rust >> would win out over C, but I'm planning on doing most of my application >> coding in Racket, and only needing a lower level language for a few >> speedups, some ad-hoc file crunching programs, etc.. I like the memory >> safety Rust provides without giving up too much performance; the standard >> library seems fairly rich; the language features are fairly nice, etc. >> >> Although I think there is a goal to reduce the amount of C code in Racket, I >> expect there will continue to be a fair amount for the foreseeable future, >> so getting my C chops back would allow me to possibly contribute in that >> area eventually (although I'd prefer to contribute Racket code). And there >> are some Schemes that compile down to C which would allow me to use them in >> some challenged environments (e.g. for Robotics, etc.), so renewing my C >> proficiency would be handy. >> >> I think the FFI interaction between Racket & C may be smoother than between >> Rust & C, but that is conjecture. >> >> Multi-core complicates things a bit. The specific program that motivated me >> to consider Rust or C is an easily parallellizeable program to parse & dump >> a file into a different format, and even though I wrote plenty of >> multi-threaded C code in the past, I'm almost positive this would be much >> more pleasant, and less error prone, in Rust. And given current CPU >> advances, I think multi-core is important for getting the most out of code >> these days. >> >> Ultimately they're not mutually exclusive, but in the near term they are, I >> only have so much time. >> >> Any thoughts from folks that are FFI'ing from/to Racket and/or using a >> second language in the same system as Racket ? > > My “thoughts" are more along the lines of cheerleading. I worked on Hygiene > for Rust, and I really want to see Rust succeed. I’ve built a tiny > proof-of-concept rust ffi interface that I describe at > > http://www.brinckerhoff.org/blog/2013/03/29/embedding-rust-in-racket/ > > … but I can’t really comment on the difficulty of building larger interfaces. > I will say this, though: Rust will make you spend time at the front end, > satisfying the borrow-checker. The payoff comes later, when you don’t have to > debug all of those core dumps. > > John > >> >> Thanks, >> Brian >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
