[HN Gopher] What's the role of Go in a universe where Rust exists?
       ___________________________________________________________________
        
       What's the role of Go in a universe where Rust exists?
        
       Author : Fiveplus
       Score  : 47 points
       Date   : 2021-02-10 14:32 UTC (8 hours ago)
        
 (HTM) web link (kristoff.it)
 (TXT) w3m dump (kristoff.it)
        
       | pornel wrote:
       | To me Go is competing with JavaScript, not Rust. If you're
       | considering writing a CRUD app in Node.js, you can do it in Go,
       | and it'll be equally easy, and maybe run faster.
       | 
       | But if you're writing a driver, codec, kernel, firmware, or even
       | a library that's supposed to be usable with more than one
       | language, Go is just not a good fit.
        
         | developer2 wrote:
         | I never understand why people compare Go to languages like Rust
         | or C. Rust is too low-level for a lot of developers,
         | particularly with its memory management.
         | 
         | Go isn't a systems language. It's a replacement for interpreted
         | languages like PHP, Node.js, Python, and Ruby. I originally
         | come from a PHP background, and have since been through
         | everything-including C. I refuse to use Node.js or Python
         | because I think async/await is a wretched concept that should
         | have never made it to the light of day.
         | 
         | To me, Go is basically PHP version 15.0. Imagine this: in the
         | next 5-10 years, PHP adds easy-to-use concurrency and the
         | ability to compile to binary (not just the recently added JIT).
         | At that point, PHP and Go would be quite similar.
         | 
         | Go is meant to be simple. Hire a bunch of juniors and
         | intermediates, and they can get stuff done.
        
       | dnautics wrote:
       | Great article. I would say my two minor disagreements is that
       | go's fast compilation is not... Typically used for tests, in my
       | opinion the testing discipline in go is low. I would go so far to
       | say that go is neither "a better c++" nor "a better c" but rather
       | "a better python".
        
         | zinclozenge wrote:
         | The golang stdlib is a little too barebones to be a better
         | python, as well as not ergonomic enough. Faster, yes.
        
           | dnautics wrote:
           | Sorry, I should have specified: a better python _for google_.
           | Google doesn 't generally need all the things in the python
           | stdlib.
           | 
           | It does need a way for their legion of new hires to not trip
           | over themselves and slot into an enterprise-friendly
           | programming mode
        
       | elipsey wrote:
       | That fact that we need to prepare in advance to defend learning a
       | new-ish language and then using to build something interesting or
       | useful is a depressing.
       | 
       | Oh well, the PM will make you re-write it in that k8s thingy
       | anyway, because everyone else has it.
        
       | MikeDelta wrote:
       | The other day I read an article about which language C
       | programmers should use, and how Go is better thought of than Rust
       | but that in the end his suggestion is to go for C++ [0].
       | 
       | Interesting observation was that the Rust community had more
       | fanatic followers who believe in Rust and nothing else, whereas
       | the Go community was more relaxed about it.
       | 
       | That makes me wonder: if something had been written in Rust,
       | would a Go, Python, or C++ developer ask why not in their
       | language? Or would they just not care?
       | 
       | [0] https://berthub.eu/articles/posts/cpp-rust-go/
        
       | DLA wrote:
       | All the things 'hn_asker' said plus a giant ecosystem, huge
       | developer attention, amazing tooling, outstanding support for
       | parallelism, jobs, a good pool of enterprise-grade projects
       | (CockroachDB, all the thinks from HashiCorp, K8S, Docker, etc).
       | 
       | And Gophers!
        
         | dnautics wrote:
         | Did you read the article?
        
       | maxekman wrote:
       | Go is good because it's easy to read and pickup, and it compiles
       | really fast. I would say it's good for request based services but
       | I don't think it's as good as it can be for enterprise code. What
       | I miss most is the lack of sum types to limit state space, which
       | is very useful in business logic.
        
       | hn_asker wrote:
       | Go is much easier to learn and get up and running compared to
       | Rust in my experience. It's great for writing servers and multi-
       | threaded applications. Rust can be used to optimize but you'll
       | probably get a lot of mileage out of golang before having to
       | switch.
        
       | waych wrote:
       | "The Go compiler is fast."
       | 
       | This was Google's motivation for Go and the reason it was
       | designed the way it was.
        
       | kevincox wrote:
       | I still don't think Go is a good language. I had notable
       | experience at Google and the following things constantly bugged
       | me:
       | 
       | - It was very difficult to read. When trying to review the code
       | every detail was left out. While each line was simple it was hard
       | to actually get the high-level picture of what code was doing.
       | 
       | - Very error prone. Maybe it isn't C dangerous but "defaults are
       | useful" is the breeding ground of bugs. The number of outages we
       | had due to trivial Go bugs was embarrassing and time consuming.
       | 
       | - Some simple things are just too hard. Most of these boil down
       | to lack of generics. For example inserting an element into an
       | array needs multiple lines of code.
       | 
       | - Many common functions and buitins have very questionable
       | decisions that are huge footguns. Especially the fmt library. (It
       | tries its absolute hardest not to fail. Instead it just outputs
       | garbage and "succeeds")
       | 
       | I get that it is easy to write, and that each line of code is
       | simple. However I think they went way too far.
       | 
       | I see Go as a slightly higher level C. You get better package
       | management, memory management and interfaces. However C is still
       | way too basic for my preferences.
       | 
       | It is a weird spot though. It is sitting in about 2x C
       | performance. It is unclear what to recommend in that spot as many
       | languages are significantly slower. Rust is probably roughly as
       | productive, but much harder to learn. Most of the interpreted
       | languages are significantly slower.
       | 
       | There are some JVM languages that are better and have similar
       | performance. However there is a memory and startup overhead.
       | However I think they make more sense in the end. JavaScript is
       | also a pretty good choice. It is in roughly the same performance
       | realm but much more productive I think. (Especially TypeScript).
        
         | skyde wrote:
         | Are you saying that python is better than GO on syntax alone?
         | 
         | Like easier to review code ...?
        
           | kevincox wrote:
           | In many ways yes. The high level code it is far easier to
           | review the semantics of the change. With Go I feel like I am
           | too bogged down in all of the unimportant implementation
           | details. (I don't really care how you implemented `map` I
           | don't need to see the 4 lines of that loop)
           | 
           | Of course with minimal static typing it is easy to miss more
           | "typo" style bugs but those tend to be caught fairly easy in
           | tests and are obvious when they fail.
        
             | wahern wrote:
             | > With Go I feel like I am too bogged down in all of the
             | unimportant implementation details.
             | 
             | But then when people praise Python and Rust, getting bogged
             | down with "unimportant implementation details" like
             | specialized async typing and colored functions becomes an
             | absolutely essential and useful aspect of the language.
             | 
             | There's just no accounting for taste...
        
               | kevincox wrote:
               | I agree that async creating coloured functions is a
               | compromise. However in practice I don't find it too
               | distracting. At the very least it is less distracting
               | then Go's error handling. (Although IIRC that is going
               | away thankfully)
               | 
               | However if you put N:M threading against 1:1 threading
               | then you can argue about that all day. I think the
               | implementations in Rust and Go are very effectively
               | implementations of each model. The threading model
               | difference is *not* something that I hold against Go.
               | 
               | It is possible for a language to handle some things well
               | but have other downsides that makes me prefer to avoid
               | it.
        
         | eznzt wrote:
         | >There are some JVM languages that are better and have similar
         | performance.
         | 
         | How about a single example?
        
           | kevincox wrote:
           | Java
           | 
           | I mean you can argue about the productivity all day but I
           | think I would slightly prefer it. But there are a handful of
           | JVM languages hovering around 2x C performance (after being
           | warmed up)
        
         | Agingcoder wrote:
         | Well, like everything in life, it's not perfect.
         | 
         | However, after initially intensely disliking the language, I
         | found out that I was surprisingly productive, and that the lack
         | of abstractions made for very readable code. The toolchain and
         | standard library are also very good (coverage, race detector,
         | cross compiler, etc).
         | 
         | Compared to python, I get fewer bugs (no surprises, and compile
         | time instead of runtime) and faster code, and compared to rust,
         | I get readable code. It's strictly better than C / C++ (lack of
         | generics aside until now) , unless you have strong performance
         | constraints (and I'd probably use rust these days anyway).
         | 
         | In the end it's good at some things, not great in any way, not
         | highly appealing but curiously effective.
         | 
         | I think I like it just because it works surprisingly well, even
         | though it initially went against my gut feeling.
        
           | kevincox wrote:
           | I totally agree. I don't think it is possible to build a
           | perfect language. However I don't think there are many sets
           | of requirements were Go is the best option. However there are
           | many situations where it isn't a terrible option, and maybe
           | that is its secret.
        
       | igmor wrote:
       | That's a wrong question to ask. Rust is the one trying to squeeze
       | in to the already crowded place, not Go.
        
       ___________________________________________________________________
       (page generated 2021-02-10 23:03 UTC)