4 ms·
1. Features 2. Performance 3. Usability You can pick only two options;
by known 8y ago
1. Features 2. Performance 3. Usability
You can pick only two options;
- awestroke 8y agoOr use Rust to get all 3!
- pjmlp 8y agoThey still need a bit of work to improve the 3., specially against GC languages.
- semi-extrinsic 8y agoI'm sorry, but Rust certainly doesn't score high on usability. Compare e.g. the "Guessing Game" intro from the official docs, just look at how much more complicated both the code and the tutorial is as compared to how you would do the same in Python, heck even in Fortran: https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html https://doc.rust-lang.org/book/ch02-00-guessing-game-tutoria...
- adrianN 8y agoI don't think comparing 100 line programs is a good benchmark for usability. Most software is much larger and the design choices you have to make for a programming language should favor programs with at least a few thousand lines of code.
- pjmlp 8y agoThen try to do a few thousand lines of code in Gtk-rs, including custom widgets, the issues with borrow checker and internal mutable struct data accessible to callbacks is what lead to the creation of Relm.
- giornogiovanna 8y agoThe final code is longer because Rust's standard I/O is a lot more minimal than Python's, Fortran's, and even C's. If you use a library like [text_io], which provides the equivalent of scanf, then I don't think that it'd be any longer. [text_io]: https://crates.io/crates/text_io https://crates.io/crates/text_io
- semi-extrinsic 8y agoBut surely, having a sane way to do I/O in the standard library is one of the traits included in "Usability"?
- giornogiovanna 8y agoWhy does it have to be in the standard library when adding it as a dependency involves adding just a single line? Since (a) there's no one true way to do input parsing, and (b) most projects don't need to interactively ask for input, it doesn't sound like something that belongs in a standard library.
- skocznymroczny 8y agoYou could use D for all three - https://github.com/Netflix/vectorflow https://github.com/Netflix/vectorflow
- semi-extrinsic 8y agoFrom the examples there, we find e.g. this nugget: return bigEndianToNative!T((cast(ubyte*)&b)[0..b.sizeof]); Do you really feel this is a language that scores high on usability? Because it doesn't look like it.
- skocznymroczny 8y agoIt's basically a reinterpret_cast, it's dirty and should look dirty, even if it's necessary in this case.
- semi-extrinsic 8y agoWhy is it necessary to do something that looks dirty? To me, "usability" means I shouldn't have to care about endianness, pointers, all the superfluous mental overhead of C et al. If you program in Python, at best you need to care about whether something is a float or int (or string if read from file). In recent Python versions we no longer have to care if a string is unicode or not (they're all unicode now); that is precisely progress in usability.
- renox 8y ago1) Define usability? Syntax? 2) Which language do you find "usable"?
- kwertzzz 8y agoJulia fits the bill quite well in my opinion: * features: you have an extensive standard library, macros, high level constructs (like generators, asynchronous programming, ...) * performance: julia is based on LLVM and as long the code is type-stable and avoids memory allocation in hot loops, the performance is similar to C or Fortran. * usability: you can also program at a very high level like you would do in matlab or python/numpy.
- dunefox 8y agoI really hope it takes off as it seems very promising.
- akhilcacharya 8y agoHonestly, I think Swift on Tensorflow fits the best for this case right now. The problem being that they seem to be integrating Tensorflow directly into the compiler (correct me if I'm wrong) which is going to be impossible to upstream and just going to lead to a Google-derived Swift fork.