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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

361–370 of 670 posts

Re: Toward Go 2

#361

Post by runT1ME »

elliotmr wrote: post #233

I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless. It also really makes me wonder if I am living in some…

>What I appreciate most about Go is that I am sure that I can look at 99% of the Go code written in the world and I can understand it immediately.

No you really can't. You can look at any given line of code and tell me what it does, where as it might take more time to parse any given line of Haskell, Scala, or OCaml longer.

However, expressivity in a large application pays a dividend tenfold, because the main challenge of reading code is not any given line, it is understanding the application architecture, the frameworks, the data flow and how it all works together.

> That is the reason there are so many successful new programs popping up in Go with large open-source communities.

Successful, or popular? Just look at Docker. Certainly popular, but check the bug tracker or talk to anyone with real world experience using it at scale and you'll be hearing a completely different story.

Re: Toward Go 2

#362

Post by TazeTSchnitzel »

notjack wrote: post #200

> We did what we always do when there's a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as…

They did the same thing with adding a “round” function. As a result, there are myriad implementations of round() in the wild in Go, and almost every single one is broken in several ways.

Re: Toward Go 2

#363

Post by vram22 »

notheguyouthink wrote: post #211
dragonwriter wrote: post #107

Earlier quoted context omitted.

Breaking things aren't want makes people want to move; it's a cost, not a benefit. Now, you need to offer benefits to get people to pay the cost for those benefits. The Python 2/3 problem was because there was too much breakage for the perceived benefit (especially early on) for many users, not because there was too little breakage.

Fwiw, I think breaking implies improving. Arguing that breaking doesn't inherently mean improving is.. well, duh. So in the case of many peoples comments here, "not breaking enough" means not improving enough. I know this is an obvious statement, but I feel like you're arguing a moot argument.. i.e., being a bit pedantic. As an aside, since you're making the distinction, can you have meaningful benefit without breaka…

>As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Eg, you're specifically separating the two - so can you have significant improvements without breakage?

One way is by having a new language feature which does not interact with anything else in the old version of the language, i.e. is orthogonal.

Re: Toward Go 2

#364

Post by tsuraan »

grogenaut wrote: post #341
bboozzoo wrote: post #267

Earlier quoted context omitted.

Unless you're writing in Erlang, in which case you program the success path and 'let it crash' in a controlled manner.

You're assuming that it faithfully crashes in all error states as opposed to incorrectly continuing on it's merry way.

Have you used erlang? Pattern matching is a big part of it, and pattern match failures always result in errors. So, if you have some function foo() that always returns ok or {error, Reason}, then in the "follow the happy path" style, you'd just have a line reading "ok = foo(),", and then if foo actually returns something else, you get a "crash". There's no assuming anything there, it's just the way the language works.

Re: Toward Go 2

#365

Post by 43224gg252 »

notjack wrote: post #200

> We did what we always do when there's a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as…

It's not absurd. This methodology may not be best for everyone, but imo it's best for the language its self, and seeing as Go is one of todays fastest growing languages the developers must be doing something right.

Re: Toward Go 2

#366

Post by weberc2 »

steveklabnik wrote: post #259
weberc2 wrote: post #254

Earlier quoted context omitted.

Ah, I think the bit where generics is useful is in making sure the value types are consistent (i.e., that you're not building a query that subtracts an int from a string or compares a date to a bool). This still doesn't guarantee that the types will match with the database columns, but it is a step up from the non-generic alternative.

It can check that they match with the columns, yeah. It also heavily relies on generic types to ensure that everything is well-formed, and to provide zero overhead.

How does the compiler know the types of the database columns? That information has to come from somewhere. Also, type checking is negligible from a performance perspective, so I the "zero overhead" is of minimal interest.

Re: Toward Go 2

#367

Post by why-el »

loup-vaillant wrote: post #195

> For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. […] If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones. Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild……

> Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously.

I think you misunderstood. Clearly he meant to ask for examples from the real world that lack generics, but shows how adding them would improve the system.

Re: Toward Go 2

#368

Post by wtfrmyinitials »

baq wrote: post #322
jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

there's nothing magic about generics. every time you make a channel or a map in go, you're using a generic function even if go people don't want you to call it that. there's nothing magic about exceptions, too, it's that it's harder than necessary to use them correctly and that's why it's not as big of a deal to not have them in go - as evidenced by this thread.

I can sympathize with the dislike of exceptions. I very much prefer Rust's error handling model (return Result)

The fact that Go has had this much success without generics is mind-boggling to me.

Re: Toward Go 2

#369

Post by kasey_junk »

43224gg252 wrote: post #304
conorh wrote: post #263

Earlier quoted context omitted.

Would you mind providing examples of what you are talking about? My experience has been different - I find that the golang maintainers are thoughtful but also very very (very) busy people. So I find they tend to respond in a terse, and sometimes what might seem like an unfriendly way, but I haven't seen any of what you mention here.

Same, and to add: Go 2 has been planned for a while (since the beginning?) and I'm pretty sure the core developers tend to defer major new feature ideas (e.g. generics) to Go 2. If they implemented everything everyone asked for they'd have another screw-up like C++ or Java.

Calling those languages screw ups is one of the funnier things I've seen in awhile.

Re: Toward Go 2

#370

Post by weberc2 »

hinkley wrote: post #350
weberc2 wrote: post #254

Earlier quoted context omitted.

Ah, I think the bit where generics is useful is in making sure the value types are consistent (i.e., that you're not building a query that subtracts an int from a string or compares a date to a bool). This still doesn't guarantee that the types will match with the database columns, but it is a step up from the non-generic alternative.

I keep meaning to pick up Rust, still looking for some entry point that's interesting enough to get me off my butt. How (well) does diesel deal with migrations? I've seen other ORMs fall down the stairs trying to deal with schema modification over time.

I think you meant to respond to Steve. I'm not a Rust guru (I keep trying it, but I don't have any applications for which it's reasonable to trade development time for extreme performance). I definitely don't know anything about diesel.
Post reply on HN