Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

291–300 of 679 posts

Re: Go is Google's language, not ours

#291
post #24

Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…

Companies pay Oracle because 1) PostgreSQL doesn't take you to lunch and 2) Oracle "just works." I mean, we all know #2 is effectively a lie but having the option to go to Oracle directly for issues (even if the response is just "pay a contractor") immensely reduces risk for executive leaders.

Re: Go is Google's language, not ours

#292
post #275
post #222

Earlier quoted context omitted.

They are still pretty similar, Microsoft re-introduced quite a few features back.

They are similar only on a superficial level, at their core they have not only vast differences in terms of how they work but they also have a different philosophy. It is not a matter of what you can do in terms of features, but also how you do it and how that affects the IDE, which is a core element of VB6 as opposed to VB.NET where you could be using whatever text editor or IDE you want (it isn't a coincidence that…

I used VB 3 - 5, later on did a couple of ports from VB 6 to VB.NET, and I am lost on what you actually mean.

Re: Go is Google's language, not ours

#293
post #147

Earlier quoted context omitted.

I'd say it depends on what you want to do with it. Go is, as far as I understand, mostly a systems programming language. A replacement for C, basically. That means it competes mostly with Rust I guess. (I'm not familiar with Go or Rust, though.) Python is mostly an application programming language. It competes with Java, Ruby, C# and those kind of languages. Python also has tons of excellent libraries for a wide vari…

I wouldn't call Go a systems programming language. Having a GC alone sort of removes it from that category.

That sounds logical, and I'm no expert on either Go or systems programming, but I've often heard of Go being referred to as a systems programming language, and on their own blog[0] they list it in third place at 37% as popular use of the language. Well after web development, admittedly, so apparently it is more a web development language than a systems programming language. I was clearly wrong on that part.

[0] https://blog.golang.org/

Re: Go is Google's language, not ours

#294

Earlier quoted context omitted.

Why not? I consider Rust to be superior in almost all respects apart from learnability and compile times. So if these two downsides are not more relevant than the downsides of Go (in a certain context), I don't see any reason why Go could not be replaced by Rust.

Ah, the Rust fanboys who vote down comments of anyone who criticizes Rust. They are actively trolling forums and spoil Rust for the rest of us. (IMHO, similar behaviour played a big role in the relative lack of success of CommonLisp, which is another language that I really like.) So I know both languages, have chosen Go instead of Rust for a larger programming project recently, and have 30+ years of programming exper…

I'm not a Rust "fanboy". I'm not even a Rust developer, but I know the language somewhat. I've had my time with Go, but wasn't satisfied with it. Some things I didn't like in Go are better solved in Rust (generics and error handling for example).

But thanks for replying seriously, even if you doubted that I wasn't only trolling (what was not my intent).

Re: Go is Google's language, not ours

#295

Earlier quoted context omitted.

Absolutely agree.. look what happened to C++ over the last decade(s).

Not sure - I thought it got significantly better with C++11/14? Admittedly it also became rather more complicated, but the changes were generally for the best I thought?

From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. (I “kinda” get it, but am not confident about it). It seemed more and more convoluted every time I tried to study about it. The complexity created by implicit and explicit copy/move constructors is just insanity for me...

Re: Go is Google's language, not ours

#296
post #214

Earlier quoted context omitted.

I completely agree. When I first started writing Go (coming from Python/C#) I complained an awful lot about what felt like pointless hamstringing of functionality. Go is a simple language, and you don't get many toys. It also feels very verbose at times, and forces you to think a lot about doing things which seem automatic in other languages. However, as time went on, I noticed a few trends. Firstly, forcing me to th…

Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot. It can be that your learn a language better, became more comfortable with the way it must be used: say, stopped writing code in Elixir the way your used to write in Python. But the other thing is that it's in our human nature that we tend to look for something positive in bad situations we ex…

This. Plus folks are always comparing to their previous experience, which is likely to still be a subjective and also hard to compare at all too. It's like apples (Go) vs oranges (C#) vs broccoli (Python).

Re: Go is Google's language, not ours

#297

Earlier quoted context omitted.

I guess the most important distinction is the “B” part (benevolent). Guido is called that because he is known (since before BDFL is a thing) to listen to other people, and adapt when they disagree strongly with his decisions. Google has never demonstrated the same attitude afaict, and in multiple occasions showed exactly the opposite. Edit: And to answer the question, no, there’s no philosophical differences. And the…

Wasn't Linus the original BDFL?

I think the B stood for something else in his case...

Re: Go is Google's language, not ours

#298

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…

But this is not about Go's merits or disadvantages - this is about who is calling the shots.

And it is not the "community" - that is just decoy.

Re: Go is Google's language, not ours

#299
post #193
post #22

So proprietary is bad? I have no issues with things being owned by a single entity, especially when they're financially backed by that (massive) entity. What is being proposed as the alternative here?

I even think that for language and base class library design a strong ownership is key to success. They make the language consistent and the library easy to learn. In both aspects, just compare .NET/C# with PHP.

Exactly. I want my language to be crazy good and have an amazing library to tap into. In fact, it was Go's great standard library (JSON parsing, hardened prod' ready HTTPS server, SSH, crypto, etc) that formed a large part of why I love the language.

And yeah, I'd rather go with .NET/C# over PHP any day (although I understand PHP is getting better and better, which is good to hear.)

Re: Go is Google's language, not ours

#300
post #216

Earlier quoted context omitted.

Only if there are major contributing developers who do not work for Google. Is that the case with Go? If there are no major non-Google contributors to Go, then the fork may not be successful due to lack of familiarity with the code base.

It depends on what you mean by "the community". If it's a community of contributors, and Google pulls it into a direction the contributors don't want, then they can fork it and continue contributing to it. If it's a community of users, then they have no choice but to follow whatever the contributors decide. I agree you need to have major contributors on board with a fork.

There's more nuance to it though. Users eventually become contributors (at least some percentage are), they become and stay contributors when they feel heard and feel like they have the ability to influence development. That's what nurturing an open source community means. If you start alienating your non-core contributors they'll stop contributing, if you nurture and support your non-core contributors they might become core contributors. No body wants to work voluntarily on a project they can't influence - that's not a contributor, that's an employee.
Post reply on HN