4 ms·
I think you got it backwards. Go is good for toy-interpreters, compilers, programming languages in general. Pretty bad for distributed computing though, Rust is
by zzzcpan 8y ago
I think you got it backwards. Go is good for toy-interpreters, compilers, programming languages in general. Pretty bad for distributed computing though, Rust is definitely better for that use case if your only choices are Rust and Go.
- pjmlp 8y agoAs someone that is usually critic of some Go design decisions I fail to see why. If you are going to say GC, it all comes down to how one designs the respective data structures.
- monocasa 8y agoRust's type system is derived from the ML variants, and as such is fantastic for writing compilers and interpreters. ML stands for "meta language", ie. it's named after how good it is at writing compilers in.
- pjmlp 8y agoKind of, I prefer the productivity I get from the GC in ML language variants. Having done some compiler related work back when we had Caml Light, OCaml was still called Objective Caml and Mirada was being turned into Haskell, I don't see what I would gain from having to deal with the borrow checker.
- monocasa 8y agoYou don't really gain anything from the borrow checker in this case, but you don't really lose anything either if you're used to it. It's the ADTs that are killer compared to Go.
- pjmlp 8y agoYeah, but then why Rust and not another ML variant?
- monocasa 8y agoThe discussion here is between Rust & Go. My point is swaping the GC for the borrow checker in order to get ADTs is a net win to me. If we're veering off into hypotheticals that don't have anything to do with the question at hand, I personally write compilers and interpreters in Rust rarher than another ML because my use cases tend to be worst case latency sensitive enough that a GC is a non starter.
- pjmlp 8y agoFair enough, thanks for replying.
- manigandham 8y agoThere are several distributed databases and other systems being built in Go now, so it seems it works fine.