9 ms·

> Is it a better bet to move on and go full Rust, rather than bother with wherever the goggle golang train is headed? Ecosystem aside, with Rust you'll get far

• LanceH 5y ago
  > Coming from languages that have them, it's just hard to take Golang seriously Some people judge the language on their ability to get work done with it. I get generics, but they really don't come up in daily use with the tasks where I use Go. Yes, it would be nice for writing some libraries but you're going through a laundry list of Rust features which don't hamper my ability to get work done at all. I even like Rust, but if I'm going to write a worker that will read from a queue, do a transformation and write to a few more queues/services upon completion, Go just works and the turn around time is far better than Rust. It's like was Perl was for Unix, but for the cloud instead.
  • choeger 5y ago
    > Some people judge the language on their ability to get work done with it. Really? Safety and correctness aren't relevant for you? Then why even bother with go instead of Python or a Lisp? For me it's crucial that a programming language contains tools that allow me to definitely rule out as many errors as possible. A powerful (and sound) typesystem does just that.
    • cloudfifty 5y ago
      It's already self-evident that Go manages that just fine. That's just weird dogma.
    • ori_b 5y ago
      How are you finding Idris? or are you more in the Agda camp? If you want to definitely rule out as many errors as possible, dependently typed languages are the state of the art, allowing you to write a sort function that will fail to compile if it returns a list that isn't sorted (eg,https://dafoster.net/articles/2015/02/27/proof-terms-in-idris/ https://dafoster.net/articles/2015/02/27/proof-terms-in-idri..., or https://www.twanvl.nl/blog/agda/sorting https://www.twanvl.nl/blog/agda/sorting). After all, if you can't even prove basic properties about your code from your language, like array accesses being within bounds, are you really using all possible tools to rule out errors at your disposal?
      • choeger 5y ago
        To be fair, I never had a chance to use Idris nor Agda. I don't know how capable I would be to encode the proofs in libraries nor client code. If it's usable, I am all for it. Otoh, I do know that languages like OCaml, Haskell, or Rust take the burden of trivial errors from my shoulders for neglible cost.
        • eyelidlessness 5y ago
          Yeah, that was an insincere gotcha question, and it's a shame that it could potentially undermine other readers' potential value of a higher degree of confidence versus a hypothetically perfect confidence.
    • grey-area 5y ago
      Does Rust also have a feature that instills a burning desire to proselytise?
      • choeger 5y ago
  • cube2222 5y ago
    Agreed. I wrote a bunch of Rust, Scala, Haskell, but I still greatly prefer Go, even without generics. I am very happy with the generic container libraries I'll get with generics, but I hope people won't try to be too clever (as they usually do). So far, Go is a language that just rules out a lot of bikeshedding, which I very much appreciate. We'll see how that evolves. I do think premature or wrong abstractions are a much bigger and widespread problem than a lack of abstraction. Also, I really like Go's error handling, it results in error messages in Go projects usually being top-notch (because of explicit handling and wrapping which includes relevant context and human-readable messages).
    • garethrowlands 5y ago
      Premature or wrong anything is clearly bad. But is parameterisation a premature or wrong abstraction? I'd say that parameterisation - even in the type language - is the original proven abstraction.
      • cube2222 5y ago
        Yes, in my opinion oftentimes it is. There is a reason why even in mathematics people like to operate on concrete examples to get an intuition. For many, concrete is much easier to understand than abstract. That's the less important point. The more important point is that making your code generic often involves more trickery which makes the code more complex, even if you only use the code once or twice - so that's just effort wasted. The fact that parameterization is a proven abstraction doesn't mean it's good everywhere. Same as I don't agree with the "Clean Code" way of creating a myriad of 4 line functions. Yes, good programmers won't make these mistakes, you can totally handle them. But when arriving at legacy code or open-source projects I greatly prefer to find under-abstraction rather than over-abstraction. To be clear, I'm not against generics, I just agree with the parent of my original message. I'm worried people will overuse them and I don't want a whole laundry list of Rust features in Go. I'm very happy about libraries with type-safe generic B-Trees.
        • Zababa 5y ago
  • pjmlp 5y ago
    That comparison is a disowner for Perl, given its language capabilities.
    • mseepgood 5y ago
      It's a disowner for Go given that Perl's philosophy is "more is more" and Go's philosophy is the Wirthian "less is more".
  • fiedzia 5y ago
    > I get generics, but they really don't come up in daily use with the tasks where I use Go. I sort of understand this argument, but I can't really imagine defining queue as something else then <T> wait_for_item() -> T. I've been writing Python for to long to know that wait_for_item() -> any will backfire in production eventually and I don't want that. At some scale (both in code size and amount and scope of dependencies) those problems just become too serious and too common to not have language that deals with that. And Go is way too popular for people to limit its use only for the cases where it currently works.
    • LanceH 5y ago
      Define queue using generics, sure. It will be huge for people waiting packages. A specific queue is typically well defined and has a struct in/out. There are times when I've wanted arbitrarily nested JSON that doesn't map into structs very well, but it is uncommon enough.
    • LanceH 5y ago
      I guess a better response to this is that I don't use generics a lot when writing Go, but I probably use a lot of packages where they would have been incredibly useful.
  • eweise 5y ago
    I use Go every day and yeah you can your work done with it but not quickly due to typing all the boilerplate.
  • xedrac 5y ago
    > if I'm going to write a worker that will read from a queue, do a transformation and write to a few more queues/services upon completion, Go just works and the turn around time is far better than Rust. Since the inception of async/await in Rust, it is incredibly quick to whip something like that up. The slowest part might even be the time it takes to compile. Maybe that's what you were referring to?
    • theshrike79 5y ago
      The way Go does it is easier to reason with, channels and goroutines are really easy to explain to anyone.
      • xedrac 5y ago
        That does sound a lot easier than Rust's channels and tasks...
  • heresie-dabord 5y ago
    > It's like [what] Perl was for Unix, but for the cloud instead. Perl and Go both have the kind of long-term language stability that I value above all. But Go offers excellent concurrency, networking baked-in, and now even fuzzing. https://go.dev/blog/fuzz-beta https://go.dev/blog/fuzz-beta
  • thayne 5y ago
    I haven't even written that much go, but even with the little I have written, I have felt hindered in my "ability to get work done" by the lack of generics.
  • pas 5y ago
    > Some people judge the language on their ability to get work done with it. I value maintenability (type safety helps prevent unintended consequences) and readability (Haskell and Clojure are out).
• kubb 5y ago
  There is a market for a language like Rust but with garbage collection and reflection. There is OCaml, but it's not for the modern developer. Go with generics is the closest thing to that which is getting some use.
  • jpgvm 5y ago
    I think so too but I think the languages that fit the bill are Kotlin and Swift. Both modern syntax, great generics w/GC and ARC respectively. Go w/generics falls very short IMO, expressibility, type safety and poor null handling all rule it out as a reasonable stand-in for Rust.
  • echelon 5y ago
    Swift is pretty much that language. It doesn't have the imitable crate ecosystem or tooling, though.
  • wbl 5y ago
    Why not Ocaml?
    • wk_end 5y ago
      Ocaml's ecosystem is a total disaster. Do you use the lousy included standard library? Do you use Jane Street Base? Jane Street Core? Async? Lwt? Batteries? Containers? Iter? Esy? Opam? Ocamlbuild? Dune? Have you seen Dune's documentation? And Facebook fractured the ecosystem even more with Reason, obnoxiously.
  • cb321 5y ago
    This more|less also describes Nim. The recent automatic memory management ARC/ORC alternative is not really even what most people think of as "garbage collection". Its macros give you full AST accept & re-emit powers and it's had generics since before Go existed. I realize it probably does not score highly on "gets used", but it deserves more attention.
  • ReleaseCandidat 5y ago
    > There is a market for a language like Rust but with garbage collection and reflection. That's why languages like JS/TS, Haskell, Elixir, OCaml (which is way more modern than Go), ... exist and are used.
• hpen 5y ago
  Is Rust really a suitable replacement for Go? I mean I know they are both system languages but I feel they have different use cases completely.
  • deleted 5y ago
    [deleted]
  • pizza234 5y ago
    I'm a Rust "fanboy" (if one wants to say so), and I still think that the use cases for Rust are just a minority in the landscape of modern languages (that is, where there is a choice). Rust has a mind-boggling overhead, for many reasons (and I'm not talking about the borrow checker, which I think one gets used to after some time), even if the language itself is consistent and ergonomic (within the intended constraints). To me, they have very different use cases - one will definitely know when Rust is required or it's an appropriate pick. For the rest, Go is fine. I think that those who put them on the same basket, haven't really used one of them. Regarding systems programming, my opinion is that they require the lack of a runtime (not just because of the performance, but also, for the framework(s) written with low-level primitives in mind), but this is arguable (in particular, there's no clearcut definition of what systems programming is).
    • hpen 5y ago
      I have only touched Rust & Go but I would only consider Rust where I would previously have used C or C++. The stuff that needs to be fast, low memory, and what not. I see Go as more of a Java. Good for backend systems. Also CLIs.
    • nu11ptr 5y ago
      Also a Rust "fanboy" and I would disagree. I'm amazed how productive I am in Rust (about 6 months in). I've written tons of Go as well, and I write Rust faster (What I was expecting was to write better code, but have it take longer, but turned out not to be true). I also thought the language would be too "low level" for the type code I write (I wrote in Go and Python mostly before, though I've written in many languages in the past), but I found it scales very well up and down to low and high level challenges (Serde _rocks_). At this point, I use Rust for everything except a couple hundred line script (Python for that). I'm not saying everyone would fit in that camp and it is a harder language to get started in for sure, but I think the borrow checker scares away too many people. It is a learning curve, but when it clicks, you will realize that every language has ownership and borrowing... you just didn't realize it because the GC allowed you to be sloppy about it. Once you do, it makes you a better programmer (just like coding in Haskell does).
• saghm 5y ago
  Slight nit: Rust does have an `Any` type[0] (and has since at least 1.0). Unlike Go's `interface{}`/`Any` type though, it's actually type-safe; the only way to get a value from it is to try to downcast into a concrete type, which returns an Option and will always be `None` if it doesn't match the type. [0]: https://doc.rust-lang.org/std/any/trait.Any.html https://doc.rust-lang.org/std/any/trait.Any.html
  • jerf 5y ago
    That's generally how interface{} works in Go too. In local idioms, but the same effect. Only valid operations are permitted. If you continue to disagree with me, please be specific about what operation Go permits on interface{} values that you consider type-unsafe.
    • saghm 5y ago
      The trailing suffix cast (not sure the actual name, but `x.(string)` and the like) are not type safe. Yes, it's not required to be able to try to deal with an empty interface type, but it's there, and it will always compile fine and allow code afterwards to freely assume the cast succeeded without any errors. I imagine the rebuttal to this is that you could always just manually `unwrap` the `Option` that is returned by the downcast methods in Rust, but I pretty strongly feel that adding explicit syntax for this type of unsafe cast normalizes it to an extent that having an `unwrap` method on a generic Option type doesn't remotely approach. It would be quite a stretch to argue that having the `unwrap` method on Option is explicitly a endorsement on unwrapping on the downcast methods given that Option is used for far more than just that (and especially given the huge amount of stigma that using `unwrap` gets in the community, which is mostly fair but sometimes goes a little overboard). On the other hand, having specific syntax that is used for unsafe casts and nothing else is a pretty explicit argument that it should be done sometimes, or else it wouldn't be in the language at all. Go could pretty easily have gone the route they did with map lookups and had the unsafe casts return two values, the latter of which is a boolean indicating success or failure (and in the cast of `false` being returned, the former value would just be the zero value for the output type), and the fact that this wasn't done means that ergonomics was prioritized over safety.
• flippinburgers 5y ago
  The actual need for generics is, I think, overstated. If you are writing a very abstract library, maybe, but most problems that I have encountered don't even begin to approach needing them.
• throwaway894345 5y ago
  > Or reinvents generics with code generation and aboriginal characters. Tell me you’ve never used Go without telling me you’ve never used Go.
  • speed_spread 5y ago
    I believe OP is referring to this https://github.com/vasilevp/aboriginal https://github.com/vasilevp/aboriginal
    • throwaway894345 5y ago
      Yes, I know, but that was a transparent joke.