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

Go 1.27

go.dev

Post reply on HN
Print view View original

131–140 of 277 posts

Re: Go 1.27

#131

Post by atomicnumber3 »

fragmede wrote: post #47
osigurdson wrote: post #44

Earlier quoted context omitted.

Go is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding). I wouldn't say it is a "beautiful" language however. Though that is in the eye of the beholder, I don't think the Go designers were even really going for beauty.

They were going for readability. You can make some impossible to read code with C++ because the programmer was too clever, and the designers of golang wanted to avoid that.

They were, very unfortunately, outsmarted by said too-clever programmers. As such I would like to request my enums and ternaries be returned to me. Trust me, they will not make a dent in the messes people have still managed to create.

Re: Go 1.27

#132

Post by mathisfun123 »

wredcoll wrote: post #119
tester457 wrote: post #61

Earlier quoted context omitted.

> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods ( http://en.wikipedia.org/wiki/Cuisenaire_rods ). I grew up and today I use monochromatic numerals. https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

I want to downvote this for being one of the stupidest things I've read this week but you're just quoting it so I guess I'll just seethe silently.

never discount the possibility of so called brilliant people having dumb AF takes.

Re: Go 1.27

#134

Post by someothherguyy »

freakynit wrote: post #124

As I've always said: every non-functional programming language, as it matures, it's adoption rises in enterprise, eventually starts to become more and more like Java in terms of it's syntax and feature-set.

because functional languages already have those features?

Re: Go 1.27

#135

Post by AdieuToLogic »

win311fwg wrote: post #122
AdieuToLogic wrote: post #118

Earlier quoted context omitted.

> Generic methods are a huge win for the language. I've been waiting on these kinds of improvements to the type system ... It's funny that you and many others have found the introduction of "generics" in Go to be highly valuable, considering one of the motivations for Go's existence was: Its designers were primarily motivated by their shared dislike of C++[0] One of the language features C++ provides, "templates", wa…

Generics were always planned, of course: https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s Rejecting templates does not mean rejecting generics.

> Generics were always planned, of course ...

This is provably incorrect.

The position held for many years by the language authors was[0]:

  Generics may well be added at some point. We don't feel an 
  urgency for them, although we understand some programmers 
  do.
  
  Generics are convenient but they come at a cost in 
  complexity in the type system and run-time. We haven't yet 
  found a design that gives value proportionate to the 
  complexity, although we continue to think about it. 
  Meanwhile, Go's built-in maps and slices, plus the ability 
  to use the empty interface to construct containers (with 
  explicit unboxing) mean in many cases it is possible to 
  write code that does what generics would enable, if less 
  smoothly.
Once the community could no longer be held back, the golang FAQ presented a very different position[1]:

  The Go 1.18 release added type parameters to the language. 
  This permits a form of polymorphic or generic programming.
0 - https://web.archive.org/web/20170102202940/http://golang.org...

1 - https://go.dev/doc/faq#generics

Re: Go 1.27

#136

Post by freakynit »

someothherguyy wrote: post #134
freakynit wrote: post #124

As I've always said: every non-functional programming language, as it matures, it's adoption rises in enterprise, eventually starts to become more and more like Java in terms of it's syntax and feature-set.

because functional languages already have those features?

naah.. they are just too different syntactically.. and the way programmers use them..

Re: Go 1.27

#137

Post by theplumber »

xavdid wrote: post #57

I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.

When I started learning Go I went all in including using the recommended editor (acme editor) which has no syntax highlighting, no autocomplete and a very different way of writing code. My production went down a lot but the quality of the code went up a lot.

I think the lack of syntax highlighting was one reason for that. It makes you think more about the code you write and how it should compose, while a fully fledged IDE encourages you to just throw more code at the problem.

I think the ACME way should be used for love of code and ideally when you want to create libraries that stand the test of time. When you just want to get things done fast bring the full IDE and now some LLM vibes and it’s done.

Re: Go 1.27

#138

Post by win311fwg »

AdieuToLogic wrote: post #135
win311fwg wrote: post #122

Earlier quoted context omitted.

Generics were always planned, of course: https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s Rejecting templates does not mean rejecting generics.

> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to t…

Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith.

However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. But not before an acceptable solution was found.

Re: Go 1.27

#139

Post by purpleidea »

teabee89 wrote: post #16

I love how proactive the crypto team is about post quantum. They released https://pkg.go.dev/crypto/mldsa . The lead maintainer Filippo Valsorda wrote a nice piece here[1] to urge the tech world to start deploying good enough versions of post quantum crypto. [1] https://words.filippo.io/crqc-timeline/

This person was public on the recent nist list against hybrid solutions. I simply don't understand why they would oppose the safer option. Yes I've read the mailing list, it just all seems quite suspicious.

Re: Go 1.27

#140

Post by kqp »

stryan wrote: post #103
blandflakes wrote: post #66

Earlier quoted context omitted.

In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.

"bold-faced lie" and "bald-faced lie" are both valid expressions. The original expression is "bare-faced lie" but they're all pretty similar to each other.

Yes but only one of them makes most people who hear it think you don’t know the expression you’re trying to use. There’s no objective reason it has to be this way, but it is, and at least personally I appreciate being told when I’ve got something stuck to my back.
Post reply on HN