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…
Go is Google's language, not ours
291–300 of 679 posts
Re: Go is Google's language, not ours
#292Earlier 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…
Re: Go is Google's language, not ours
#293Earlier 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.
Re: Go is Google's language, not ours
#294Earlier 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…
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
#295Earlier 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?
Re: Go is Google's language, not ours
#296Earlier 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…
Re: Go is Google's language, not ours
#297Earlier 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?
Re: Go is Google's language, not ours
#298I'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…
And it is not the "community" - that is just decoy.
Re: Go is Google's language, not ours
#299So 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.
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
#300Earlier 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.