Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

281–290 of 679 posts

Re: Go is Google's language, not ours

#281
post #252

Earlier quoted context omitted.

What type of numerical computing do you do? By that, I mean what is the problem domain?

Mostly machine learning for distributed sensor networks (ie: smart meters). Deal with lots of time-series data, state space modelling, some recurrent neural nets (etc). Our shop has a 'golang only' thing going, which means that I end up having to reimplement algorithms in go sometimes from scratch.

nice area, I would be interested to learn more into this type of problems. Recently, I became for interested in power electronics / smart grids / energy, and looking for the ways to get in touch with people working on such problems, learn more and join any company on these domains.

Re: Go is Google's language, not ours

#284
post #35

Earlier quoted context omitted.

I'm curious what the distinction is between Rust (driven by Mozilla) and Go (driven by Google).

I had a similar question, but rather, what's the difference between Go with Google deciding what goes in, and Python (a year ago) where the BDFL and a couple core devs decide what go in? Sure you could argue that a company may have different incentives than a BDFL, but in this context, it's not clear that Go would've been more likely to accept the change you're proposing if they weren't being led by Google.

[deleted]

Re: Go is Google's language, not ours

#285

Earlier quoted context omitted.

I had a similar question, but rather, what's the difference between Go with Google deciding what goes in, and Python (a year ago) where the BDFL and a couple core devs decide what go in? Sure you could argue that a company may have different incentives than a BDFL, but in this context, it's not clear that Go would've been more likely to accept the change you're proposing if they weren't being led by Google.

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

#286
post #186

Earlier quoted context omitted.

>everyone's pet feature Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.

Generics was introduced in Java in 2004 with J2SE 5.0[0]. [0]: https://en.wikipedia.org/wiki/Java_version_history#J2SE_5.0

Generics were added so late because they had to figure out how to do it properly, correctly, on the first time.

Re: Go is Google's language, not ours

#287

Earlier quoted context omitted.

"Java has been ruined by the push to include everyone's pet feature." Care to expand on this? Java is very careful to release new features.

It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) These different paradigms together make for code that does not read the same no matter who writ…

I have no idea what having a "soul" means. But I suspect that my career has been well-served by being dead inside.

Re: Go is Google's language, not ours

#288
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…

My enjoyment using any given language always tends to grow as I get more productive with it, even if I have a more general dislike for the language itself.

Making computers do things is fun (usually)! The programming language is (almost) immaterial - depending on the task at hand of course.

Despite myself, I've even found myself enjoying JS in the few times I had no choice to avoid it. shudder

Re: Go is Google's language, not ours

#289
post #242

Earlier quoted context omitted.

> Go does not have generic arrays any more than C does. Go does have generic collections, and generic functions operating on these collections. > You cannot e.g. write a generic Go function to reverse an array. You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. > which you can't in Go Beca…

According to this usage, C has generic functions because you can, e.g., index into an array of ints. The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. It has some built-in operators that can operate on multiple types. Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This i…

> The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature.

Go absolutely has this feature. Just not for you as a user of the language.

> It has some built-in operators that can operate on multiple types.

Go has multiple builtin functions which abstract over type parameters e.g. close() can operate on any chan, append() or copy() can operate on any slice. They are not operators (symbolic or keyword).

> Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics".

It's overloading, +(int, int) and +(double, double) are separate functions under the same symbol. It's an orthogonal feature, so much so that there are plenty of languages which do have userland generics and don't have overloading.

> This can't really be the right explanation given that generics are now being added to the language.

The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.

Re: Go is Google's language, not ours

#290

Earlier quoted context omitted.

The top 10 according to Red Monk[1] are JavaScript, Java, Python, PHP, C#, C++, CSS, Ruby, C, Objective-C, Swift, TypeScript, Scala, Shell, Go, R, PowerShell, Perl, Haskell, Kotlin. Of these, Javascript (w3), Python (Python Foundation), CSS (w3), C++ (ISO), Ruby (community), C (ISO), Shell (Posix), R (community), Perl (community), and Haskell (community) are not bound to a single company. [1] https://redmonk.com/sogr…

Kotlin is also no longer in the hands of a single company. https://kotlinfoundation.org/

That’s amazing! When did this happen?
Post reply on HN