On Sat, Jan 26, 2019 at 9:46 PM Anselm Garbe <garb...@gmail.com> wrote: > > What are your concerns about Rust? > > The language itself is certainly better than C++ or Java and avoided > many mistakes (like exceptions and going to far with OO). On the other > hand the typesystem isn't great and much more complex than golang's > approach.
Although I follow this mailing list from the "shadows", I would like to contribute on the topic of Go and Rust as "saner" programming language alternatives. First of all I've programmed both in Go and Rust and, if I need a "native" executable, I can say this: * I'll resort to Go if it's a prototype / one-off project or if it is heavily concurrent; (although if I can get away with a Python script I'll do that;) * on the other hand I'll look towards or Rust if the project is more "involved" (i.e. more complex, or with high-performance requirements), but not too concurent; * I would never resort to C++ (which can easily be replaced by Rust); * I would skip C if it doesn't require too much OS-related interaction; in fact if I do need OS interaction, Rust is a better alternative than Go, due to Go's goroutine runtime which, as a previous poster noticed, doesn't play nice with the standard C library; On the other hand comparing the two languages (as in syntax and features) is not enough; one has to look at their ecosystem, better said the tooling, documentation, and third-party libraries (and dependency management tooling). I would like to touch especially on the third-party libraries and dependency management: * Go's approach (until lately) was, how to put it, "non-existent"; you would have a `src` folder where you've let `go get` checkout your dependencies at whatever version their `master` branch was at, hoping for the "best"; **there is no concept of version** (therefore there are a lot of competing "vendoring" tools;) * Rust's on the other hand went the Java / NPM / Ruby / Python way in providing a centralized repository, explicit versions, explicit dependencies, etc.; All in all, each has its strengths and weaknesses, and I would say Go's approach better resembles the UNIX world in which you'll have to maintain a coherent development environment. However in the current development landscape (with frequent chances) I am always amazed how the whole things still works... (For example in Go, I'm yet to find a good way to fork a library, patch it, publish it under my own GitHub account, and still be able to use it without changing all the imports to the "forked" location...) Regarding the type systems you can't actually compare them: Go is to Rust, as C is to C++. (However please take into account that I've developed a large-ish (for a single person) Rust-based project and **never** had a segmentation fault / null-pointer-exception. I can't say the same about Go.) And lastly there is a hidden pitfall with Go, which Rust solves it "better", in the case of high-performance use-cases: heap-based allocation of what "seems" to be a stack-based allocation (especially in the case of buffers). Go's compiler tries its best to use stack-based allocation, however it throws the towel whenever it encounters a interface. For example say you want to implement a simple tool that computes the cryptographic-hash for the input stream. You'll just use the `Hash` interface, declare a buffer of "enough" size, and loop through read-hash. Unfortunately because we use the `Hash` interface Go's compiler can't keep the buffer on stack, but instead it allocates it on the heap. However one allocation is not that bad, unless you've decided to declare the buffer inside the loop (just before the read), instead of outside the loop; in the former case you'll end up with as many allocations as there are iterations... In Rust on the other hand, being explicit about allocation, you don't have to "hunt" for such places in your code. (The previous is not a "made-up" story. I encountered this in a real project which involved writing a high-performance HTTP server in Go... The solution let's say was not that pretty...) > Besides this it's the hipster environment of Rust that is putting me > off. I am truly curious what contributes to this "hipster" perception? (I myself find that the old web site was "better" than the current "color-fest" site... However if you look past that I find it quite "serious looking", or at least as "serious" as Go's ecosystem...) > the main ideas that resulted into Go > are clearly footprints of Bell Labs. Sometimes I would say that perhaps in Go there is too much "Bell Labs" heritage... (For example the `Dial` function name... What's wrong with `Connect`?) > In Rust I do miss this influence > -- there seems more influence in Rust from the 'functional' > programming folks - which have also worsened Java dramatically since > the Java 6 days (lambdas, weird container/collection programming > paradigms etc.). I do acknowledge that sometimes "functional pipelines" seem more closely to badly written Perl code; however I do miss (in Go) the ability to `v.map(|x| x*2)`... > When looking at Rusts' experiemtal features such as future, intrinsics > etc. I have the feeling that adopting it might lead to a big regret in > the mid term, which is why I would stay away ;) Indeed Rust (as a language) seems to become larger and larger with each new release. Even as it stands today it is a daunting task to learn, and indeed it took me more time to learn Rust than Go. On the other hand, a plus on its side, Go seems to invest more in tooling and libraries than in language features. Thus my bottom line about the two would be: I like them both (perhaps Rust a little bit more), but each has it's own use-cases which don't overlap much. And being on the subject of programming languages, I understand why this community dislikes (initially I wrote "hates") Java / Python / Ruby / PHP / etc., my take being that they don't fit the main use-cases of this community. However I am yet to find a large "enterprise-ish" / user-interacting system written in C / Go / Rust; and in fact at the moment if I were to start a large "enterprise-ish" project (especially of the "book-keeping" kind) I would choose Java without a regret... Moreover, last week I've played with HHVM (Facebook's PHP execution environment), and I would say that in this configuration (i.e. HHVM as the "PHP execution environment") and with simple PHP code (without frameworks which try to mimic Ruby's Rails) the result could be quite "suckless" and UNIX-y in nature. BTW, does one know of a "suckless" CGI HTTP server? (Perhaps written in Go?) :) (And `Caddy` doesn't fit the bill as it has almost everything but it's own TCP/IP stack and file-system...) Ciprian.
