291–300 of 302 posts
Earlier quoted context omitted.
Rust is not an easy language to learn. Among languages in common use, it is almost certainly the most difficult language to learn.
Disagree. C++ is the most difficult - the compiler accepts programs which Rust would reject and then they segfault or worse.
“Since we began our journey with Rust, the number of projects using Rust inside Meta has increased at an accelerated rate” That almost sounds like an endorsement. I’ve been holding off learning Rust. However, it seems like Rust adoption is reaching a tipping point.
Yep, and its pretty much going to become the next C++ - i.e widely adopted at first, and driven into a shit state. Specifically because of this https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html This needs to exist in Rust for it to get adopted, because forcing good developers to get explicit with code for memory safety when they are doing simple operations is going to result in them ignoring the language. So ev…
That's...exactly what Rust is doing with their compiler, which checks ownership and lifetimes, so I don't understand your point here. Maybe they didn't need to write a whole new language, but why not add modern features like pattern matching along the way?
Earlier quoted context omitted.
> I’m no expert but always saw Go as the better choice for CLI tooling where performance is important I'm no expert in golang, so golang may in fact be better(?) by some metric of better, but as the author of a Rust CLI tool[0], I will say that Rust is extremely performant, and pretty fantastic at this very use case. It seems like a sweet spot to me. [0]: https://github.com/kimono-koans/httm
Sure, I wasn't really implying that Go is more performant than Rust, but that Go is a better choice where performance is important, but not so important that you'd forgo the simplicity of Go for Rust's more complex development style (borrow checker, etc?). I'd really love to get into Rust (and Go, tbh) but haven't needed the performance when I'm working on personal stuff and it's generally 1000x faster for me to jump…
I understand why someone might feel this way, but I think it may misunderstand/misinterpret a few things.
First, a more complex development style is not a chronic condition, because you become proficient in the language you work in. For instance re: the borrow checker, you begin to understand what it wants you to do, and why. Rust may be harder to pick up, but, once you do, it's just as easy to build a CLI tool in Rust.
Second, obviously, it depends on the type of CLI tool you're writing. Maybe the CLI tools Meta are writing look less like Python scripts, and more like Valgrind or tcpdump.
Third, not to disparage golang in any way, but golang's simplicity is something of an illusion. Because all "simplicity" is an illusion. It breaks down quickly at the edges. As someone else noted, you should take a look at "I want off Mr. Golang's Wild Ride"[0] but also perhaps "Simple Made Easy"[1].
[0]: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... [1]: https://www.youtube.com/watch?v=SxdOUGdseq4
Earlier quoted context omitted.
For CLI apps, performance may be important, and Rust offers a performance profile similar to C++. This is exactly the niche where relying on an automatic GC may be undesirable. But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC. It kinda makes sense if you only focus on management of memory as a resource, but it ignores the whole race condition angle (which…
«But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC.» Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice. My point is: there are tons of GUI application…
Earlier quoted context omitted.
Disagree. C++ is the most difficult - the compiler accepts programs which Rust would reject and then they segfault or worse.
That's true, but it doesn't mean C++ is harder to learn. Rust has a broader and more novel conceptual surface area than C++. This is what influences difficulty, not memory safety guarantees.
Earlier quoted context omitted.
«But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC.» Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice. My point is: there are tons of GUI application…
The question, rather, is why one would want to use C++ rather than something higher-level (e.g. C#, Java, Swift) for a GUI app in 2022. We're long past the point where performance benefits were worth writing the whole thing that way. Most apps can get away without anything C-like at all, and for the few that need that perf boost, it's easier to implement the corresponding part as a C++ library called from higher-leve…
Unless you mean that the lower level GUI code should be rewritten in Rust, so that other languages can provide a higher level interface on top of that. That might indeed sort of work. But the vast amount of work is going to be in Rust. And you still pay some penalty, depending on the mismatch of the higher level language and rust. You will need to have a frictionless integration as between C# and WinForms.
The hard work is on that lower level. A simple text input control takes a lot of engineering. You will still end up with something like QT in Rust.
Earlier quoted context omitted.
Sure, I wasn't really implying that Go is more performant than Rust, but that Go is a better choice where performance is important, but not so important that you'd forgo the simplicity of Go for Rust's more complex development style (borrow checker, etc?). I'd really love to get into Rust (and Go, tbh) but haven't needed the performance when I'm working on personal stuff and it's generally 1000x faster for me to jump…
> Go is a better choice where performance is important, but not so important that you'd forgo the simplicity of Go for Rust's more complex development style (borrow checker, etc?). I understand why someone might feel this way, but I think it may misunderstand/misinterpret a few things. First, a more complex development style is not a chronic condition, because you become proficient in the language you work in. For in…
- Java (with JOOQ): As a high level typed language (similar to Hack for Meta's use case. If Golang's generics help create a JOOQ equivalent in the future, then this would be Golang).
- C++/Carbon: As a systems/performance language. (We haven't tried Carbon yet, but this I feel would help beat Rust for this systems category)
- JS/TypeScript (Node or Deno or zx): As a scripting/tools language.
- Python: As a data processing and machine learning language (primarily thanks to the JIT computing and data libraries for Python). (This list ignores CUDA :))
In a pre-AST project 2 world, I've found the following 4 languages work well for programming (non-frontend) use cases, based on my startup experience: - Java (with JOOQ): As a high level typed language (similar to Hack for Meta's use case. If Golang's generics help create a JOOQ equivalent in the future, then this would be Golang). - C++/Carbon: As a systems/performance language. (We haven't tried Carbon yet, but thi…
Update update: Or reluctantly with Python instead, with a similar library such as PugSQL.
In a pre-AST project 2 world, I've found the following 4 languages work well for programming (non-frontend) use cases, based on my startup experience: - Java (with JOOQ): As a high level typed language (similar to Hack for Meta's use case. If Golang's generics help create a JOOQ equivalent in the future, then this would be Golang). - C++/Carbon: As a systems/performance language. (We haven't tried Carbon yet, but thi…