Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m Frustrated with Go

dev.to

Post reply on HN
Print view View original

21–30 of 233 posts

Re: Why I’m Frustrated with Go

#21

Post by andreasgonewild »

dvfjsdhgfv wrote: post #5
andreasgonewild wrote: post #2

Go contains many good ideas that may be carried over to more pragmatic languages. Using it for anything beyond simple, self-contained command-line tools and network servers never really worked out for me. And that makes sense, since it was explicitly designed to scale over groups of inexperienced developers at any cost; the opposite of my needs. Modern C++ runs circles around Go for more complex software, and it prov…

Your blog entry you're referring to contains surprisingly little information to support the arguments mentioned in your posts. Maybe if you provided some specific example of why a given fragment of code works better in C++ rather than Go, we could have some interesting discussion.

I can't take responsibility for your expectations, differences between languages and their consequences for the code we write is a tricky thing to quantify. I have no proof and I'm not here to argue, only to share my authentic experience in the hope that it helps someone else. Both codebases are clearly linked from the post for comparison. Feel free to ignore my advice if Go is working out for you.

Re: Why I’m Frustrated with Go

#22

Post by masklinn »

rvense wrote: post #20
jbg_ wrote: post #16

The link to the immutable, ordered map that "Java provides" seems to be a link to a third-party library created by Google. If that's enough for you to consider that a language provides a feature, just wrap the immutable ordered map implementation in your blog post in a library, publish it, and now Go provides that functionality too.

Is it possible to write a reusable version of something like this in Go without using interface{}?

If "static codegen" is considered OK, then I guess yes, and I guess you can use The Thing[0] to even make them look like actual generics.

Every user of the library will need to run codegen to post-process their source files and generate the relevant instantiations of the "generic" collection.

[0] https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

Re: Why I’m Frustrated with Go

#23

Post by seanwilson »

latch wrote: post #11

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…

> This is especially true when your system is interacting with external data - like user input and a database. I did C# and Java for years. These interactions are, at best, painful with static languages.

Why? I find when you're importing external data or user input, that's exactly where you want strong types as that's the most likely place unexpected values are going to be generated (e.g. unexpected null values, string instead of an array).

Re: Why I’m Frustrated with Go

#24

Post by alkonaut »

Having to encapsulate data to ensure read only semantics seems like par for the course from an OO perspective. In C# (which is 15ish years old at least) I don't think there has been an immutable map until very recently. Also (and this is probably a code style thing) I can't remember having reached for an immutable ordered map in a long career.

Re: Why I’m Frustrated with Go

#25

Post by dvirsky »

doublerebel wrote: post #6

So, once upon a time I wanted to associate information with http connections (as I am accustomed to in every other language I've ever written) just to enable proper http keepalive and debugging through a proxy written in Go. Ended up with this. [0] Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib. I still appreciate many go tools and the cross platform single…

These days you have http requests with context (I think starting from Go 1.8), see https://golang.org/pkg/net/http/#Request.Context

Re: Why I’m Frustrated with Go

#26

Post by dvirsky »

thinbeige wrote: post #9

OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?

I don't know specifically why that is for this specific project, but in general Go has GC and bounds checking that slow things down.

Re: Why I’m Frustrated with Go

#27

Post by thinbeige »

43224gg252 wrote: post #18
latch wrote: post #11

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…

>I found it a chore to maintain Go-based systems My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week. I don't have much…

> I don't have much experience with elixir, but that's because I like to stay employed.

While the previous commenter gave an objective and rational overview why he think Go gives him a hard time you can't resist to get polemic.

Re: Why I’m Frustrated with Go

#28

Post by masklinn »

thinbeige wrote: post #9

OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?

> does anyone know why they chose Rust instead of Go for the Parity client?

Maybe ask them? According to their FAQ (https://github.com/paritytech/parity/wiki#our-priorities):

> Minimise Moving Parts: While Rust is multi-paradigm, we aim to write intra-function logic in as functional a manner as possible. Mutability is avoided except where necessary for the algorithm or efficiency.

> Minimum Footprint, Maximum Performance: Maximise references, minimise copying and holding copies. Rust makes it safe. When there are dynamic data structures, provide means for keeping them under control.

> Reliability: Through Rust's language-level memory and thread guarantees and a disciplined approach to exception-handling we can state with a high degree of certainty that our code cannot crash, hang or bomb-out unexpectedly.

But I can't tell you that's all of the story. In the original announcement thread on /r/ethereum, the main point of comparison was C++ rather than Go so ymmv.

Re: Why I’m Frustrated with Go

#29

Post by _ph_ »

Ar-Curunir wrote: post #8
dvfjsdhgfv wrote: post #7

I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages. However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.

Go is not in the league of C for efficiency though? Very different kinds of languages...

In my day to day work, I find Go very much in the league of efficiency of C, if, for robust and real programs, not beyond. Low level Go code compiles the same as C code does (yes, C compilers have better optimizers), you have sometimes to pay for some overhead (bounds checks, GC), but that often pales compared doing this by hand in C, when you need a reliable and robust application.

Re: Why I’m Frustrated with Go

#30

Post by masklinn »

dvirsky wrote: post #26
thinbeige wrote: post #9

OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?

I don't know specifically why that is for this specific project, but in general Go has GC and bounds checking that slow things down.

Rust bounds-checks indexes by default (there exist indexing methods which bypass that, they are unsafe).
Post reply on HN