Live data from Hacker News

Ask HN: Go programming language is over ten years old. What do you think of it?

news.ycombinator.com

191–200 of 310 posts

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#191
post #58

Go taught me how we tend to rely on overly complex structures to solve our daily problems, which makes our code look smart, but in fact is harder to maintain and understand by newcomers. 99% of the time, trying to use idiomatic go instead of fighting the type system lets you have more maintainable and easier to understand code. Now, every time i'm back to using another PL, i tend to rely on advanced type systems feat…

So true. I was nervous about not having generics in Go but haven't missed them after primarily working in it for several years. You have to stop trying to write C++ or Java or C# in Go.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#192

Earlier quoted context omitted.

I think most Go people will put most anything that goes over the wire into some protocol description language like protobuf or even swagger. Inside your call stack I am not sure you need enums instead of constants. If you are either persisting or transmitting data then you want some formal description which will essentially get you enums as useful symbolic values.

Lack of real enums is one of my biggest annoyances with Go. So so many times I've put the wrong enum value in because it's just an int and it matches another set of enums. I've taken to putting each set of enums into a separate file and separate folder just to help the compiler catch this. The project I'm working on now has about 25 separate enum files+folders. Gagh!

Typedefing with iota should let the complier catch this, but it is an extra wonky step

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#193

After disliking it for 6-7 years, because it doesn't offer the amount of abstraction that others languages offer (Scala, Haskell, Java), Go has grown on me. I got too caught up in designing elaborate abstractions in those languages. I couldn't avoid it either, since other libraries would also use elaborate abstractions. With Go, I just write plain dull code, against a suite of good dull libraries. Ultimately I spend…

Without too many distracting abstractions I find it easier to evolve a codebase over time rather than overengineering at start.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#194

Great tool, two big negatives. First, checking result values is dumb. It adds 50% more code. Add exception handling. Second, the way imports work is obviously due to some internal google kitschy-ness. Remote import paths are so dumb. People set up entire domains and CDN's just to host some code. The import path has to have a specific format, you can't have three levels. github.com/me/sub1/module won't work, so everyo…

Your first negative is a matter of perspective, so depending upon your coding preferences you may be right. For me personally, even with nearly 2 decades of C# (exceptions are used extensively) I prefer the Go way. Checking results values is not dumb, it's just not the way that suits you. And that's fine. Variety of preference is one of the reasons we have so many programming languages to choose from. As for modules,…

For me personally, with also nearly 2 decades of C# and C++, exceptions is the best possible way to handle errors there is, especially for large projects. I have worked on projects which were built on exceptions, and on projects which were built on return codes. Exceptions is hands down the cleanest. Instead of becoming a mess of call/error handle blocks, you code can clearly separate business logic and error handling. If I had 10 cents for every time I've fixed a bug when an error analysis is skipped because it is not supposed to happen until it is...

Golang way is terribly flawed. As a matter of fact I've watched a video yesterday on golang best practices, and got very excited. And then I realized, this is still a language where you can't throw an exception and that made me very sad, as I realized golang is going nowhere. It will be exciting for a few more years, like ruby was once, and then everybody realizes what a PITA it is for large codebases, and it shall become another ruby.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#195
When I see programmers talk about Go's simplicity, I think about the different things that simplicity can mean. For example:

  seqA = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
  seqB = [2, 4, 6, 7, 11, 12, 14, 16, 17, 19, 20]
You could argue that seqA is simpler because it follows a regular pattern: the range of ints from 0 to 20, inclusive. Or you could argue that seqB is simpler because it contains fewer numbers.

Go seems like seqB to me. It is simple in that it provides a limited set of features, but to me it ends up feeling fractured.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#196

Its a great programming language that is helpful to solve problems without wasting time. I really appreciate the simplicity, I think it totally makes sense at work where not everyone wants to deal with weird code. I think maintaining old golang code will not be a major problem in the future for example. The garbage collector make things a lot simpler too. The dependencies management is not great compared to npm/crate…

Go is carefully designed to be adequate for the large majority of problems that don't need much, meant for use by the large majority of programmers who don't know or need much, whose attention is elsewhere. It is hard to get too deep into the weeds by accident. It builds fast, so programmers who code by successive approximation, making more or less random changes until something works can get there quickly. It runs pretty fast, so programs usually don't need much optimization attention.

It competes in the same niche as Java, but lacks Java's complications that, more often than not, are purely obstacles.

Before Go, before Java, there was Visual Basic. Visual Basic coders didn't go anywhere. Go acknowledges and welcomes them.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#197

I find myself reaching for it over other languages when I want to build small servers with a bit of in-memory state or a bit of heavy processing. For little search-engines, Go is perfect. While writing servers in Flask + Python is much more convenient, I still prefer Go because I don't run into the limits that Python has. The development process is fluid enough that I wish the language was suited to more usecases. Wh…

TypeScript might be good for your use case, expressing programs in terms of their types. You could also try OCaml/ReasonML.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#198

When a struct implements an interface one has to keep guessing that it really does so (unlike Java, C++ there is nothing in the syntax of go that would show interface inheritance as a fact), and that really doesn't help the poor guys who have to read/understand/maintain some code. Why did they do that to a language that is based on interfaces?

I often find it useful that implementing an interface is implicit. For example maybe I'm using a library that provides a struct A. I can make another struct B that mocks that functionality for testing, and then everywhere in my code use an interface C that encapsulates A and B. That wouldn't be possible if A had to explicitly declare that it implements C. If you want to explicitly declare that you implement an interf…

- that's an optional convention, and it is not always followed

- not easy to search for this pattern.

You are right that go interfaces give you some flexibility with mocking, but i still think it's a questionable choice.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#199

I'm glad it enables other folks to build such great tools with it, but I don't think I'd pick it for my own projects or prefer to code in it at work. For the clever stuff they picked up from ConcurrentML (channels), they treat the user (developer) like an idiot due to having to spell out everything in great deal compared to languages that have a better type system. It's good to get a lot of programmers onboard at Goo…

> I think people complain about Go because it's not the hammer for their nail. Or it's _almost_ the correct hammer! If they'd just fix those damn

It's the correct hammer for a company that employees tons of people who, for the most part, don't really care about the craft of programming and don't want to be bothered by learning anything difficult. They just want to ship their features on time and get their year-end bonus or whatever pat on the head.

Even at a company like Google, I don't think most programmers are really pushing their understanding of software design or tools or techniques. They learn all the silly interview stuff about red-black trees then are just happy using coding within the well-defined bumper car arena of Google's frameworks and coding guidelines (e.g. Golang with no "hidden code" like in C++, where not writing certain things causes the compiler to generate stuff for you).

We all read Hacker News and generally are excited by new advances in things (e.g. C++ concepts! No more stupid SFINAE!), but most people at big companies don't.

It's truly a testament to the genius of Go that it solves this problem: much faster than Java, not complicated because most programmers at Big Corp can't deal with complexity (e.g. no exceptions in Google's C++ coding guideline), and understandable without too much effort by the average programmer at Google.

We all understand what it looks like without this effort: The Monolith of Bug Spaghetti Code

I work for an extremely large software company that is stuck on C for decades. I try to use C++ where I can, but I usually get shot down in code review with a message of "C++ is too complicated for your colleagues to understand what you did". To solve the code mess, they implement their own languages to generate the boilerplate C (e.g. like protobufs, but poorly done and NIH because some guy wanted a promotion to "Principal Engineer").

As much as I dislike Go, I would take Go over the current situation I'm in...

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#200

I do not like it. The lack a proper (1) Class, (2) Enums (seriously, using constants to describe a proper Enum like Java has is a must, we are in 2020 not in 1980), (3) being able to call methods on methods on nil pointers, (4) generics that are available for langauge internals but not for language users, the list could go on. All this just because I am working on it few months now. Let's see how it will evolve throu…

The lack of classes and generics is probably the strongest argument of Golang, so can’t agree with you there. As for enums, I miss them too. Sum types as well.
Post reply on HN