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

Go is Google's language, not ours

utcc.utoronto.ca

Post reply on HN
Print view View original

571–580 of 679 posts

Re: Go is Google's language, not ours

#571

Post by jayd16 »

akerro wrote: post #497
jayd16 wrote: post #455

Earlier quoted context omitted.

C#'s language is much better designed IMO. Can anyone compare LINQ and Java's streams and not pick LINQ? Feels much sloppier in Java and Java came second.

Yes, I personally prefer streams, LINQ seems to me like mixing SQL in C# and that feels wrong.

That's probably what I like most about it. But that aside, the naming of tasks seems much more consistent in C# than Java. Java already had streams and maps and mangling those names makes searching for documentation a pain.

Re: Go is Google's language, not ours

#572

Post by eropple »

jimmaswell wrote: post #568
eropple wrote: post #557

Earlier quoted context omitted.

I do mean that, and I do mind it a lot when I'm so used to just being able to erase the generic. There are performance implications to type erasure, to be sure, but when our computers are mostly all future machines from beyond the moon, I'm more interested in minimizing the impedance between my brain and a solved problem.

This is the only non-bad consequence of type erasure I'm aware of. On the other hand, a lot of code I've written in C# would be impossible or severely hacky without type retention, like "new T()", "T is Thing", finding all classes that are derived from T, etc.

TBH, I'm just as happy passing a factory method in for that sort of thing. Because it allows you to do both and pick the one that makes the most sense for you in a given situation.

Re: Go is Google's language, not ours

#573

Post by pron »

dirkg wrote: post #550
pron wrote: post #503

Earlier quoted context omitted.

C# has made some serious mistakes: reified generics (which has basically destroyed simple language interop on the CLR and makes it an unattractive target for language implementors), and recently, async/await. Both of these help in some ways, but have costs that are higher than the benefit and much better alternatives. Java is not trying to "keep up." It is intentionally slow-moving and conservative (this design goal…

async/await is fantastic and pretty much the direct inspiration for the exact same feature om ES6, where its a godsend. C# i s one of the best dev experiences in any language/IDE

Async/await is fantastic compared to not having anything at all. It's a big downside compared to other things you can do (cf Go, Erlang), and hard to get rid of. It's the classic case of getting easy short-term benefits at the expense of long-term costs. It's main benefit from an implementor's perspective is that it's better than nothing and very cheap to implement quickly. Just as .NET has lived to regret reified generics[1], it will live to regret async/await.

[1]: Maybe not C# programmers, but there are easier ways to do a single-language runtime.

Re: Go is Google's language, not ours

#574

Post by mcguire »

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…

I don't know the real relationship between Google and Go, but Go is very much a product of its current core team, who are (AFAIK) all veterans of Bell Labs (Robert Griesemer?) and all have the same Bell Labs approach.

Bell Labs invented Not Invented Here syndrome. You can know this to be true because there is no way this group of people could have the syndrome so bad any other way. The other side of the coin is that they are very, very good. You can know that because they do a lot of interesting, novel work without obviously (or obviously without) having looked at any other research in that field.

Take for example, Chris's comment, "(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google's Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)"

The second link there is to https://peter.bourgon.org/blog/2018/07/27/a-response-about-d... From that: "[RSC and the dep-pies] discussed dep at the GopherCon contributor summit. Matt Farina says that [Russ Cox] said [he] could do better if [he] went off on [his] own and built something. ... The clear impression was that Russ wasn’t going to engage with the committee, the research [the committee] had prepared for him, or the prototype product of that research, dep — at least, not yet. The clear impression was that Russ had his own hypothesis about what a solution would look like, and that he was interested in validating those hypotheses, by himself. ... Russ decided to implement his ideas on his own, and make a proposal without us, and without telling us that’s what he was doing until it was essentially done."

This is what I'm talking about. If your ideas suitably mesh with their philosophy, they may be adopted. If they do not, the Bell Labs team will ignore them completely. And if they think the problem is a problem (and they don't, in many, many cases), they are quite capable of doing an end-run around you and producing a solution which satisfies their perception of the problem.

Go may or may not be Google's language. Go is the Go-lang team's language and you will go where they want you to go, to adapt MS's old slogan. To an extent, it's similar to Perl; one's success as a Perl programmer depends entirely on your ability to hold your mouth right and successfully simulate Larry Wall. Perl is not a DWIM language, it's a do-what-Larry-would-mean-if-he-wrote-what-you-wrote language.

[^1] I myself do not endorse the technical ideas in that post. "[Something] does not support using multiple major versions of a program in a single build. This alone is a complete showstopper." is true. The fact that most tools don't do it---and have to live with the resulting pain---simply means that it's hard, not that it's not necessary.

[^2] A previous discussion of Go modules here: https://news.ycombinator.com/item?id=17534923

Re: Go is Google's language, not ours

#575

Post by neop1x »

hvidgaard wrote: post #72
smt88 wrote: post #50

Earlier quoted context omitted.

C#, F#, Kotlin, TypeScript/Node (someday Deno) I wouldn't worry much about "performant" though.

F# and Haskell are two very nice languages if you want to try something truly different.

... and if you are ok with investing to adapt newcommers coming to your team and fine with lack of people actively using it

Re: Go is Google's language, not ours

#576

Post by NateDad »

naikrovek wrote: post #235
reflexer wrote: post #209

Earlier quoted context omitted.

wrt a "proper" way: adding item to a slice, uhmm?

A slice isn't an array. A slice is a view into an array. You don't look through a window in your house into the backyard, and plant a tree in the backyard by fiddling with the window. It's the same with arrays and slices in Go. If you want to insert an item into a slice, insert it into the array (by copying to a new array and adding your new element to it while copying), then creating a new slice which includes your…

    names = append(names, "Bob")
.... that's really it. Will it have the same backing array as it did before you did append? Maybe, maybe not. Should you care? Absolutely not, and if you do, you're probably doing something wrong.

Re: Go is Google's language, not ours

#577

Post by mcguire »

richardwhiuk wrote: post #467
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.

- Probably not?

- Maybe?

A better question is, "Can you successfully act like you worked at Bell Labs in the 70s and 80s?"

Re: Go is Google's language, not ours

#578

Post by Retra »

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.

Rust doesn't move through the pointer, it moves only the pointer, which should be perfectly fine.

Re: Go is Google's language, not ours

#579

Post by mcguire »

DannyBee wrote: post #432
silvester23 wrote: post #82

Earlier quoted context omitted.

The last two paragraphs of the article address exactly that issue - that it's hard to tell whether the direction of Go development is decided solely by the Go core team or by Google as a corporation.

Which is nonsense, and is equivalent in this case to "i never bothered to ask so i'm just going to assert some stuff that agrees with my viewpoint". They could have just asked. In fact I can answer this for you, since I was the relevant director (IE Go directly reported to me) It was driven by the core team, and more particularly, the leads and what they want to be trying to do. I have provided precisely 0% of the vi…

So, why is Google paying them? Is Google getting enough value out, or PR, or...?

Re: Go is Google's language, not ours

#580

Post by asveikau »

damnyou wrote: post #464
72deluxe wrote: post #354

Earlier quoted context omitted.

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 show…

> Move constructors are one of the worst parts of C++

Move constructors fix a narrow problem, which is, when you have something like a vector append, how do you copy over all the previous elements as a "shallow" copy rather than a deep one?

In C with realloc(), it's just assumed that memcpy works for that. With C++03 and earlier copying the elements could very well end up duplicating everything on the heap for no reason, then discarding the old copy.

How does rust do this? What I am reading from googling is that every assignment is a move?

Post reply on HN