Go is Google's language, not ours • Hacker News Board

Re: Go is Google's language, not ours

#461

Post by xyzzy_plugh » Wed, May 22, 2019, 4:05 PM UTC

meddlepal wrote: post #446

danielmg wrote: post #177

For what it's worth I'm a semi-grey beard (20 years in) and I love golang. For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. It needs close parenting. Java has been ruined by the push to include everyone's pet feature.

> For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. Your comment is the problem with the Go community. I have seen a number of comments from Golangers that they want a "fun" language that helps them reminisce about the past. They also want to write a lot of senseless boilerplate because for them more typing is somehow about them reliving their past. And…

> we need better tools

Sure, and the "right tool for the right job" is still my mantra. Go is a very good at solving for an incredible amount of tasks in many problem spaces. Users will always want to bend tools to work in new places, and that's okay -- sometimes it isn't a fit.

Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements.

Re: Go is Google's language, not ours

#462

Post by apta » Wed, May 22, 2019, 4:05 PM UTC

akarki15 wrote: post #450

jasonhansel wrote: post #277

I really wish Go had learned a lesson from Java: programmers will eventually want generics, and adding generics to a language that was not designed for them leads to new and unexpected obstacles. The lack of generics makes Go uniquely unsuitable for functional programming, an unfortunate outcome when functional programming is the New Cool Thing.

> New Cool Thing See that's your issue. Go tries super hard to _not_ be that and evidently has succeeded.

The original view of the golang authors was that it was made to replace C++. It obviously failed at that, and ended up being used as a faster Python.

Re: Go is Google's language, not ours

#463

Post by bojo » Wed, May 22, 2019, 4:08 PM UTC

nudq wrote: post #359

jolfdb wrote: post #328

Earlier quoted context omitted.

Do you need an alternative to GHC?

What's GHC's bus factor? (Actual question.)

The top 10 contributors are active and fairly well known in the community (I recognize 5 of the names at least), of 170 members with commit bits for the project.

https://gitlab.haskell.org/ghc/ghc/graphs/master

Re: Go is Google's language, not ours

#464

Post by damnyou » Wed, May 22, 2019, 4:09 PM UTC

72deluxe wrote: post #354

0815test wrote: post #307

Earlier quoted context omitted.

> From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. ... The complexity created by implicit and explicit copy/move constructors is just insanity for me... This is the best argument for move from C++ to Rust instead. No "move constructors" whatsoever, move semantics are the default and are always performed via a trivial memcpy. There are explicit…

So what if I have an object that has a pointer to another object? memcpy is not what I want in that instance.

If you mean intrusive data structures, Rust just doesn't support them. Everyone still manages to write software in Rust just fine. (There's some early support for immovable data with `Pin`, but that's only exposed via async/await at the moment.)

Move constructors are one of the worst parts of C++ and being able to write movable, intrusive data structures is absolutely not worth the cost. If you do need one, Rust shows that it's better to sacrifice movability than introduce move constructors.

This is not uncommon -- there are some things you can do in C++ that you simply cannot do in Rust (either safely, or at all). Usually there's another, better way to achieve the same overall goals.

Re: Go is Google's language, not ours

#465

Post by tene » Wed, May 22, 2019, 4:13 PM UTC

72deluxe wrote: post #354

0815test wrote: post #307

Earlier quoted context omitted.

> From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. ... The complexity created by implicit and explicit copy/move constructors is just insanity for me... This is the best argument for move from C++ to Rust instead. No "move constructors" whatsoever, move semantics are the default and are always performed via a trivial memcpy. There are explicit…

So what if I have an object that has a pointer to another object? memcpy is not what I want in that instance.

Assuming struct A has a reference to struct B, memcpy is a fine way to move struct A, and struct B cannot be moved while borrowed.

Here's an example I put together demonstrating this: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Go is Google's language, not ours

#466

Post by richardwhiuk » Wed, May 22, 2019, 4:16 PM UTC

baby wrote: post #418

Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for…

Go already supports generics - the hashmap is generic, and the array is generic.

It's just you can't implement your own hashmap in Go, and make it compile time type safe.

Re: Go is Google's language, not ours

#467

Post by richardwhiuk » Wed, May 22, 2019, 4:19 PM UTC

jmtulloss wrote: post #23

The article uses "Google" instead of individuals names to make the actions taken seem like sinister actions of a faceless corporation. My interpretation is that Google employs a tight-knit group of people that work on Go and collectively are the BDFLs of the language. This isn't that much different from most large OSS projects, although it does seem likely that this core team weights the opinions of those that they i…

The basic question is "Are they on the core team because they work at Google?"

- If someone new joined Google, would they immediately get added to the core team, with no history of contributions?

- If someone had a long history of contributions, but wasn't hired by Google, could they join the core team?

Those two questions are pretty determinate on whether this is a community project or a Google project.

Re: Go is Google's language, not ours

#468

Post by stcredzero » Wed, May 22, 2019, 4:22 PM UTC

eloff wrote: post #379

doesnt_know wrote: post #162

I'm going to risk being labeled an ~incompetent dev~ or whatever but learning golang was seriously a breath of fresh air compared to literally any language I have ever tried to grok before. Everything felt like it was there on purpose. It always seemed like there was a "proper" way to achieve something. Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk. You never have to worr…

I agree, the greatest thing about Go is all the stuff it left out. Which is still annoying sometimes coming from more expressive languages (no exceptions! no generics!) But thanks to the simplicity and the common format standard it is so easy to read and understand. If I want to know about an edge case of a library function, I just dig through the code in my IDE until I have the answer. In most other languages I'll h…

I rarely have to think much about how to write the code itself, just about the actual problem that I'm solving.

Bingo. This is also what the designers of Smalltalk, Ruby, and Python were trying to achieve. This is the opposite of C++, where I find that I'm thinking about the how all the time. (And at least 25% of the "agile" process time is spent on this activity in explicit reviews.)

Re: Go is Google's language, not ours

#469

Post by fwip » Wed, May 22, 2019, 4:25 PM UTC

maxiepoo wrote: post #394

jerf wrote: post #374

Earlier quoted context omitted.

Haskell also has the motto "Avoid 'success at all costs'."[1] What that means is not that they want to fail at the things they set out to do, but that they want to ensure the language is never in a position where it's so important that certain behaviors or code be kept exactly the same because there's too much code that depends on it in the wild that they can't experiment with some new interesting feature in the next…

The "motto" (if it can be called that) is not "avoid success", it's "avoid 'success at all costs'" which makes the sentiment clearer: increasing adoption should never be a priority over principled design.

Interestingly, the motto can be parsed two ways, with different connotations.

"Avoid (success at all costs)" or "(avoid success) at all costs."

Re: Go is Google's language, not ours

#470

Post by stcredzero » Wed, May 22, 2019, 4:26 PM UTC

There are many answers for why this won't happen, but one that does not usually get said out loud is that Go is Google's language, not the community's.

More precisely, its design belongs to a small number of capable people who are on the same page, with regards to a pragmatic, minimal-ish design. This is better than a "benevolent dictator," in that there are some checks and balances. It's also better than design by mass committee from the public.