5 ms·
While Python's bindings in other languages are great, and Rust has amazing features regarding memory safety, I think saying they are the best in their area is a
by linkdd 5y ago
While Python's bindings in other languages are great, and Rust has amazing features regarding memory safety, I think saying they are the best in their area is a bit too much.
For compiled languages: Rust is the best when you care about memory safety. C is the best when you care about performance/simplicity/portability. C++ is the best when you care about modularity, Assembly is the best when you care about lowlevel stuffs, ...
For interpreted languages: Python is the best for data science, Java is the best for entreprise, Javascript is the best for speed, ...
Each one have a use case where they are the best. And those use cases I listed above, are entirely subjectives and will never be the same from person to person.
If there was an objectively best language period, why would other languages exist?
- post-it 5y agoC, C++, and Assembly aren't safe, and Java and JS aren't good glue languages.
- linkdd 5y agoSo? My point was that if you don't care about safety, C/C++/ASM have good aspects too. I can write a program without a single pointer in C, and it will be fast, small, and portable. Java is used a lot in data science alongside Python. And Javascript also have bindings for Tensorflow and other libs. They are scripting languages able to call C code, by definition they are glue languages.
- treesprite82 5y ago> So? Wheelerof5te said Rust is becoming the "world's best *compiled, safe* language". You objected to this, but then only listed alternative languages which aren't in that group. You responded as if Wheelerof5te had claimed there was "an objectively best language period". > They are scripting languages able to call C code, by definition they are glue languages. If I say something like "world's best chef" then I mean the person who is best at being a chef. Not the world's best (most moral?) person who happens to also fulfill the definition of being a chef but may be pretty bad at cooking. I think the same was intended here for "best glue language" - best at being a glue language.
- smitty1e 5y agoImplementing Rust's borrow checker as a C++ compile-time template metaprogramming exercise seems only a guru and a cloud-based compiler cluster out of reach.
- tialaramex 5y agoRust's borrow checker works perfectly well written in Rust without needing a "cloud-based compiler cluster". But I'm guessing what you meant to suppose here would be instead to do this for C++ and that's not going to happen, though it does for some reason seem to be a popular wish of C++ enthusiasts. C++ doesn't express the thing the borrow checker is er... checking. So you'd need to adjust the language, Stroustrup has some sketched proposals about that, but realistically they're years out even if the C++ community was enthusiastic which they are not.
- smitty1e 5y agoIt was a semi-tongue-in-cheek observation along the lines of => https://abel.sinkovics.hu/download/metamonad.pdf https://abel.sinkovics.hu/download/metamonad.pdf
- wheelerof4te 5y agoI said that Rust "is on track" to become the best, not that it is best. It is still a young language, but Rust shows great promise to one day be that one language you need for just about anything, sans scripting. The best part is that Rust is approaching C levels of speed, sometimes even surpassing it. Python is currently the easiest language to learn, has a plethoa of modules in it's standard library alone, plus a vast ocean of 3rd party libraries. From displaying cute cats inside your terminal, to large mathematical monoliths like numpy and scipy. Python has almost everything you need to build programs, minus the speed and easy distribution of executables. Java is semi-compiled and too verbose to be a glue language. Javascript is faster than Python, but is much more difficult to use efficiently. It's standard library is such a joke that I had to install a 3rd-party library just to use a input() equivalent.
- Jansen312 5y agoCompiled with memory safety? Which language you have in mind better than rust at this moment? Just curious.
- wheelerof4te 5y agoHonestly, none that I can think of.
- tialaramex 5y agoOther people have pushed back about safety, but I want to push back on performance. Here's the thing, presumably you agree that "It's fast except that it never works" isn't actually fast. So in practice your high performance C ends up compromised by the reality that it must work, at least often, which constrains what you are confident to actually write because you already know you can't write over-complicated code correctly. Languages like Rust (and C++) enable you to write much more complicated software that you still understand well enough to debug it. An efficient filter that might be a single line of Rust or C++ may take dozens of lines of C, or else several macro invocations that add invisible overhead of lines that are constructed by the pre-processor unseen by the programmer, yet still taint the shared namespace and semantics. As a result, while the Rust or C++ programmer feels free to chain say, six filters the equivalent C looks monstrous and you recoil from it, even though that's the efficient way to solve the problem you had. The intuition that if it looks simpler it's faster is often wrong, the reason Godbolt (Compiler Explorer) exists is that Matt Godbolt was concerned about whether the C++ for-each loop results in the same fast machine code as a manual loop, or whether you might pay a price for the nicer syntax. You don't, and Matt's continued exploration of this sort of issue, plus his generosity in sharing the result with the world is why the site is there now. But of course the nicer iterator loop (and there are a lot of examples like this) encourages you to choose more complicated solutions which are faster, because total cognitive load isn't so great as it would be in a less expressive language. As a result even though you could in principle write an equally high performance C program, actual C programmers would not do that. Now, machines don't fear complexity, so one of the interesting results of WUFFS is that they produce C code which no human would ever write, but which has all the properties they guaranteed (e.g. memory safety but lots more) in their small interest domain, by "simply" using tremendous amounts of complexity. The unexpected effect of this is that WUFFS-the-library is very fast: Since the only possible mistakes are programs that either don't do what is required or don't compile, WUFFS programmers are freed to focus on very fast tight code for the library. Again, you could in theory have written that code in C, but you wouldn't because you're human and you can't handle that.
- adsharma 5y agoAgreed on the need to write simpler programs with less cognitive load. The thing about wuffs is that you can't single step through it and there is no ecosystem of libraries a wuffs programmer could use. This is why a subset of python that shares design principles with Julia and Nim, but transpiles to Rust, Go or C++ is interesting. It's not hugely popular with those language communities (prefer coding natively in Julia or Nim), but the pytorch thread (https://news.ycombinator.com/item?id=29354474#29371641 https://news.ycombinator.com/item?id=29354474#29371641) explains why the ecosystem is important (harder to build). Having said that the basic hello world wuffs example in py2many isn't working as well as I'd like it to, but it's close.