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

Go 1.18

go.dev

Post reply on HN
Print view View original

51–60 of 614 posts

Re: Go 1.18

#51

Post by gerbilly »

ainar-g wrote: post #28
gerbilly wrote: post #20

Earlier quoted context omitted.

> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 70s with some fixes to make it a good language for writing small networked apps. Insofar as that goes¹, the language is fine. However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming commun…

> However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Can you provide examples of that? Because the closest thing I can remember is Go creators saying that C++ had too many features interacting in weird ways, and that they wanted to avoid that. Which is a perfectly normal des…

Sorry can't find any since google results seem to get worse year over year.

Basically I gleaned this impression from the go message groups more than 5 years ago.

Go is pretty nice, but IMHO, it's no masterpiece.

There's a reason we keep copying C like syntax, and it's not just familiarity.

C could be criticized on many points, but in my opinion it was a brilliant case of language design: Only 30 keywords, the stdllib was a separate thing (not common at the time), great as a systems programming language.

If you think of C of the 1970s as a sort of souped up macro assembler, you're not far from the truth, and it was wildly successful, also, because of what it left out.

Go might have had similar ambitions, but the execution was not thought out as well. If you want to design a truly great language, it turns out it's not enough to merely leave things out.

I got the sense that the Go people wanted to be taken seriously on the same level as great achievements like C and UNIX, but the creators quickly saw through the incoming critiques that they hadn't pulled this off.

You know when you create something and then receive criticism? If the criticism is clearly wrong or due to a misunderstanding, you're not upset about it typically. You explain that the misunderstanding, and typically the person critiquing says, "ah ok..." and moves on.

But the critiques which really get to you are usually the ones which you know deep down are right. I think maybe this is why the creators of Go seemed so touchy about it.

EDIT: And for the record I program in Java and Rust mostly, a bit of Python too. I hate C++ (a sprawling mess) and also don't give a crap about Haskell or monads.

Re: Go 1.18

#52

Post by s3graham »

philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

The silly things that bothered me the last time I tried to use it: 1) lame un-opininated formatter (no line wrapping); 2) obtuse-but-mandatory directory structure for modules once you move beyond a single file (maybe this has improved?); 3) embarrassingly large binaries.

Re: Go 1.18

#53

Post by philosopher1234 »

apazzolini wrote: post #16
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

Here's a blog series that you'll likely find enlightening: https://jesseduffield.com/Gos-Shortcomings-1/

I did not find this enlightening (and I’ve read it before). This criticism is fixated on what I would consider minor annoyances in using Go, and doesn’t explain why they’re such a big deal.

Re: Go 1.18

#54

Post by leetrout »

Hooray! Couple quality of life improvements to embedded filesystems... you can now use files that start with an underscore :D

Re: Go 1.18

#55

Post by FpUser »

scottjg wrote: post #44
FpUser wrote: post #36

Earlier quoted context omitted.

Quite frankly Paul's article makes little sense to me. Unless you trying to code in some brainfuck using language A vs language B is of little concern from my experience. I will of course exclude cases when language is simply and obviously unsuitable for the domain. Writing low level video codec in Python is definitely not the best idea. Quality of the programmers on the other hand matters more.

Paul is famous for his essay about Lisp - arguing that his startup beat other startups because Lisp is such a better language than C++ or Java which his competitors were using. Unclear to me if this is really the meaningful reason that Paul's company succeeded (I'd say obsession with programming languages can be a counter-indicator for productivity), but it clearly resonated with a lot of people since that essay is a…

I think that whatever his achievements, those are the result of his business savvy and being able to execute. Praising Lisp just shows that it is his favorite language and he's using his clout to promote it, nothing is wrong about it of course. But as I've already said I believe that he could've used plenty of other languages with exactly the same outcome business wise.

Re: Go 1.18

#56

Post by throwaway894345 »

icholy wrote: post #10
echelon wrote: post #7

Earlier quoted context omitted.

Counter point: Generics make me far more inclined to use Go regularly. If error handling is improved to be safer and more ergonomic, it'll be incredibly compelling for me. Generics were the biggest feature keeping me from using the language, and now that's a done deal. I'm excited.

If you consider the adoption rate, it's pretty clear that the people who avoid Go because of are a vocal minority.

Personally I considered it something of a feature that Go repelled people who prioritized "writing in their personal style" or "showcasing their powers of abstraction" above all other concerns. The result was standard, readable, boring code which made Go a very productive tool.

Re: Go 1.18

#57

Post by nicoburns »

Thaxll wrote: post #39
nicoburns wrote: post #31

Earlier quoted context omitted.

I would suggest that the core complaint is with the lack of ability to create abstractions, which leads to writing a lot of boilerplate. Which in turn makes Go code quite hard to read for anyone who thinks about programming from a top-down perspective doesn't for example want to have to decipher loop indexes to determine that the code is doing a .filter().map() operation.

I disagree, Go is easier to read than most modern languages, it's easier because it has a few keyword and did not add major features in the last 15 years. I can't say the same for Java / C#, Rust / C++ etc ...

I think that's a valid perspective. But there are many of us who don't find Go harder to read than those languages (well, maybe not C++). I think we must recognise that to some extent simplicity is subjective. What is easy to one person isn't necessarily easy to another and vice-versa.

Personally, I think in abstractions. So a language that represents those directly is much easier for me to reason about than one that makes me constantly translate those low-level procedural code and back again.

Re: Go 1.18

#59

Post by jimbob45 »

throwaway894345 wrote: post #29
andrewf wrote: post #14

Earlier quoted context omitted.

I work at a Go shop that was a Python + RoR shop when I joined. I don't dispute Go's benefits at our scale. As a matter of personal preference, I don't enjoy Go. Go is Blub ( http://www.paulgraham.com/avg.html ). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succee…

Go wins because it's generally simple and consistent. People like simplicity rather than kitchen-sink languages. And this doesn't only apply to the grammar and type system, but also to the tooling--Go doesn't require you to: * Pick a testing framework / runner * Learn a DSL to manage dependencies * Learn how to configure the build system to ship static binaries * Debate code formatting rules * Build a CI pipeline to…

I don't know if it's that people like simplicity as much as simple things should be done simply. If I'm in C and I want some user input and I want to concatenate that input to another string, I have four hours minimum research ahead of me to not add a terrible vulnerability to my application right off the bat. User input should be simple in the simple case with complexity hidden behind weird toggles.

Git is great with this. You can get by just fine in 99% of cases with git add, commit, and push and those three could be explained even to a child. However, you can also fine-tune your pipeline just the way you like with Git's endless tweaks.

Re: Go 1.18

#60

Post by djbusby »

throwaway894345 wrote: post #12
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular beli…

What do you build where you see that "healthy margin"? I build mostly webApp, and API services (boring business stuff). Reaching for Go or PHP is about the same (read JSON, business rules, database). For this stuff PHP was hardly better than CGI-Perl - except for application performance - where PHP was better than CGI and Go is better than both. What am I missing in using the tools that I don't see that margin? Maybe I'm measuring the wrong thing?
Post reply on HN