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

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

news.ycombinator.com

Post reply on HN
Print view View original

291–300 of 310 posts

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

#291

Post by valenterry »

jahaja wrote: post #253
apta wrote: post #252

Earlier quoted context omitted.

> That's one of the major recognized selling points of Go. It's exactly just that, marketing fluff and hype made up by the golang team that is not backed up by actual evidence. Look up several other comments in this thread that mention exactly that. I'm not the only one challenging their false claim. There were never any specific language features that make golang good for large projects. Quick compilation was touted…

You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that. > verbose and error-prone error handling Verbose (and consistent) is exactly what you want for large teams. What's e…

> You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that.

It doesn't matter what language you use - cleverness will come in anyways. Only the way it is achieved is different. Cleverness in the case of go will just be difficult to understand reflection, where it will be difficult to understand types in Haskell.

With go, every line of code will be simpler when compared to Haskell (picking Haskell as an arbitrary example here). However, the go program will also 10x bigger. And complexity grows over proportional with the amount of code. In the end, the understand what the whole thing is doing you will have a harder time compared to the more dense but also much shorter code in Haskell _if you are very familiar and experienced in both languages_.

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

#292

Post by MH15 »

spurgu wrote: post #144
seanwilson wrote: post #83

I don't code with it but I use Hugo (a static site generator) that's written in Go because it's ridiculously fast. Ruby and JavaScript static site generators I've tried end up taking several seconds to generate a handful of pages when Hugo spits out hundreds of pages in less than a second. It's pretty crazy how used we are now to slow dynamic languages. I also like how Hugo is available as a single binary file - much…

I slapped together a static site generator in (mostly) Bash the other day and it renders all of my 6 shitposts (Node for MD -> HTML conversion) in 2.7 seconds flat and I'm perfectly happy with it. Or I was. Now your post made me want to rewrite it in Go, for science.

My Node.js (well, Typescript) static site generator that I wrote for my blog is carefully written to be fast enough for me. I am considering rewriting in Go too, "for science", but I'll probably continue to use the Node.js version if only for the npm packages I use.

https://github.com/mh15/neanderthal

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

#293

Post by vram22 »

ncmncm wrote: post #278
vram22 wrote: post #276

Earlier quoted context omitted.

>Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps. Your first sentence (quoted above) is right. But IMO, the two sentences quoted above, together, are not right. Because, even if not optimal, successive approximation means getting closer at each step, which is unlikely or impossible with a random walk.

With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one. You may laugh, but more code is written this way than not.

>With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one.

Still think the logic is wrong or at least farfetched, but not going to argue it more.

>You may laugh, but more code is written this way than not.

I know that quite well, having been a dev for many years and a manager for some, so seen things from both "sides".

In fact I can say I've seen it from a third and maybe even a fourth side (perspective, really), ha ha, since I've been an independent consultant and trainer for a while now.

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

#294

Post by apta »

hactually wrote: post #269
apta wrote: post #208

Earlier quoted context omitted.

> I should be able to look at a function and understand everything about its possible code paths. Any golang function can panic, so you always have to account for it anyway.

What? That's patently untrue.

What do you mean? A panic can happen anywhere and it is not reflected in the signature.

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

#295

Post by bborud »

chridou wrote: post #285
bborud wrote: post #271

Earlier quoted context omitted.

In order to have a meaningful discussion, let me expand on what I mean by "boring". To me, a boring language is one that is easy to learn, easy to read and which encourages somewhat homogenous code - through coding style and common idioms. It has few surprises and few dark corners. If a language still has major aspects that practitioners struggle with after 2-3 years, it isn't "boring". If you have to expect every co…

> In order to have a meaningful discussion, let me expand on what I mean by "boring". This is the problem with how boring is used. According to Wiktionary it just means "unable to engage or hold the interest". So how can this be a criteria for using a technology? Why do you redefine the word and deviate from the common meaning? What is the reason behind this? Why is it necessary that your understanding of "boring" ha…

Now you are being contrarian for the sake of being contrarian.

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

#296

Post by HerbsMan »

apta wrote: post #256
jahaja wrote: post #253

Earlier quoted context omitted.

You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that. > verbose and error-prone error handling Verbose (and consistent) is exactly what you want for large teams. What's e…

> You seem to be writing that a simple language is somehow harder to scale for large teams I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen other programs in complex languages get out of hand. There is a sweet spot in terms of language simplicity/complexity and usability. Make it too simplistic (like golang)…

Do you use linter sometimes?

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

#298

Post by ncmncm »

vram22 wrote: post #293
ncmncm wrote: post #278

Earlier quoted context omitted.

With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one. You may laugh, but more code is written this way than not.

>With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one. Still think the logic is wrong or at least farfetched, but not going to argue it more. >You may laugh, but more code is written this way than not. I know that quite well, having been a dev for many years and a manager for some, so seen things from both "sides". In fact…

Okay, then.

"Programming by successive approximation" is more polite to say that "flailing randomly", but it would be a mistake to imagine one being more orderly than the other. But it was good enough for our protist ancestors, so it would not do to say it is wrong, as such.

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

#299

Post by MichaelMoser123 »

rowanseymour wrote: post #249
MichaelMoser123 wrote: post #198

Earlier quoted context omitted.

- 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.

If the problem is finding implementations of an interface, that's provided by the standard tooling. If you're using VSCode just right-click on an interface and select Find All Implementations.

actually i was not using 'standard tooling'; was using vim with YouCompleteMe plugin for code completion. I couldn't get all the VSCode plugins to work well, somehow.

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

#300

Post by jahaja »

valenterry wrote: post #291
jahaja wrote: post #253

Earlier quoted context omitted.

You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that. > verbose and error-prone error handling Verbose (and consistent) is exactly what you want for large teams. What's e…

> You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that. It doesn't matter what language you use - cleverness will come in anyways. Only the way it is achieved is differen…

I don't agree that dense code is easier to understand at all. It's both harder to understand and much harder to debug. I don't now why more code is in anyway reflective of how hard it is to understand. That would make the Redis code base harder to understand just because it has more features now than 4 years ago. That's just not true.

Haskell is also a good example, if it was easy to understand, maintain etc. we would have seen a good examples of large-scale apps and projects being developed in it by now. But we do not. Barely a single one.

> _if you are very familiar and experienced in both languages_.

This can be translated to "this is so cognitive challenging that you need to be really well-versed to not fuck this up now". That's not a good user-interface for something to scale on large teams.

Post reply on HN