Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

311–320 of 679 posts

Re: Go is Google's language, not ours

#311
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.

> It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.

>I'll never forgive the addition of `var` to the language.

I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?

Re: Go is Google's language, not ours

#312
post #242

Earlier quoted context omitted.

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

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

That seems like a roundabout way of saying that it doesn't have the feature.

>It's overloading

You could just as well regard Go's close, append, copy etc. as overloaded.

> 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.

They've come out with a specific generics proposal. I'm not sure why you would think that they're not serious about implementing it.

Re: Go is Google's language, not ours

#313
post #45
post #27

Earlier quoted context omitted.

Not yet. But we can hope. Ten years is a long time in this business.

Ten years is a very short time for a programming language. Python is decades old and hasn't hit its peak popularity yet. I don't know of a single mainstream language that has died, except for perhaps ColdFusion or ActionScript.

> Python is decades old and hasn't hit its peak popularity yet.

What? Python's peak (2.7) has come and gone.

Re: Go is Google's language, not ours

#314
post #262

Earlier quoted context omitted.

Look at what happened to Kubernetes. They rewrote original Java code in Go and it's a mess because of Go's limited abstraction capabilities. Sure there's an element of rewriting in a new language and attempts to force idioms, but there's also the fact that Go literally hacks in special cases for generics, unavailable to users. They recognize the need for generics, but haven't implemented them, which is a problem for…

If Graal had been mature at the time, I expect Kubernetes would still be written in Java.

If you mean due to AOT compilation to native code, there have been plenty of options since around 2000, their only "crime" is being commercial.

Re: Go is Google's language, not ours

#315
post #146

C# unfortunately has the same issue, but the effect is much more visible. Few people (I'm sure you can find examples, but given how popular the language is on Windows, it's a tiny minority) use C# outside of Windows and it's a shame. There is no good open ecosystem so even as a former Windows dev I hardly use it anymore.

The limiting factor for me, as a long-time C# dev now working outside of Windows, is that many of the tools I used haven't been ported to .NET Core. Take Umbraco, for example. If someone were to port it to .NET Core and rewrite parts of it to use Postgres as a db option there would be zero reason to ever use WordPress again.

Other than like 90% of ISPs only offer cheap hosting for PHP.

Re: Go is Google's language, not ours

#316

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…

It's okay, I like elixir's take on things more and I question how suitable Go is for maintainability of large projects. But it's okay. It will improve as more developer tools and language features come online.

It seems to me that you’re going to have a lot more trouble maintaining Elixir code than Go code over the long run.

Re: Go is Google's language, not ours

#317
post #65

Earlier quoted context omitted.

Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.

This is the general point though. Community pressure would have produced generics under a different leadership model that wants to check the box. Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.

WAI?

Re: Go is Google's language, not ours

#318

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…

I'm by no means a expert, but doesn't Go advocate using append with a slice which will create a new array? https://golang.org/pkg/builtin/#append

Re: Go is Google's language, not ours

#319
post #224
post #192

Earlier quoted context omitted.

That's not really a problem for computer science students, I think. Their area of focus tends to be on the algebraic, theoretical side of the spectrum. It's much more of a problem for computer (software) engineers.

Which boils down to the same issue. Back home CS means Informatics Engineering, a degree certified by the Engineering Order to practice, with enough theory and practice spread across 3 - 5 years. Those that want CS theory without programing have a major in Mathematics with a minor degree in computing.

What country is this? It’s certainly not that way in the USA at most universities.

Re: Go is Google's language, not ours

#320
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.

Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, D, Swift, Sing#, System C#, Common Lisp, Interlisp-D, StarLisp, Real Time Java beg to differ.
Post reply on HN