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

231–240 of 679 posts

Re: Go is Google's language, not ours

#231

Post by abhijat »

mcv wrote: post #147
Kovah wrote: post #34

I am about to learn a new programming language and I decided against Go just because of this fact. I do not trust Google and reading this article just makes clear how critical the state of the language is in terms of control by the community. Python looks most promising and I already worked with it, but I am not sure yet. Can anyone recommend a viable alternative for Go? Any web-focused language that is performant, m…

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

#234

Post by threeseed »

ncmncm wrote: post #27
airstrike wrote: post #19

Earlier quoted context omitted.

Java is a footnote?

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

Java underpins Scala, Kotlin and Clojure.

So not just all the big corporates but plenty of tech companies like Facebook, Uber, Spotify, Twitter, Linkedin, Netflix, Apple, Google etc all rely heavily on it.

Re: Go is Google's language, not ours

#235

Post by naikrovek »

reflexer wrote: post #209
doesnt_know wrote: post #162

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…

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

edit: (adding for clarity) In a lot of programming languages, whether they use slices or not, arrays are of a fixed size and must be copied to a new array if you want to add elements. Some languages have some syntax that makes it feel like you are modifying an array in-place, while doing the copy to a new array behind the scenes.

edit-edit: for an implementation example of the above, see Java's ArrayList class: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/...

Re: Go is Google's language, not ours

#236

Post by masklinn »

foldr wrote: post #225
masklinn wrote: post #122

Earlier quoted context omitted.

> ...what in the world makes you thing that? Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.

Go does not have generic arrays any more than C does. You cannot e.g. write a generic Go function to reverse an array. You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which…

> 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

Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.

Re: Go is Google's language, not ours

#237

Post by jacques_chester »

sverhagen wrote: post #196
pjmlp wrote: post #168

Earlier quoted context omitted.

- Distributed transactions across cluster nodes - The IDE experience with PL/SQL, including graphical debugging of stored procedures - Compiling PL/SQL to native code for better performance - Running bare metal without an underlying OS - Oracle RAC - The fine tuning options on their JDBC and .NET drivers - A proper C++ driver API

I don't have the stats to back this up, bit that all seems very niche. I have to imagine you get downvoted because people don't recognize these as real requirements. I needed not a single one of these. Ever.

> I needed not a single one of these. Ever.

Enterprise software tends to have lots of features that the majority of folks will never encounter in their career. The enterprise market space is composed of around a thousand potential customers world wide, all of whom are large enough to have sophisticated and complex internal computing environments. They have varying norms, requirements, workloads, regulatory environments, industry standards and so on and so forth.

Each has a lot of money and rejecting the requirements of one company often means you are effectively rejecting several, or perhaps even an entire sector. So you add something to cover them and before long, your software has the union set of features required solely by enormous companies.

From a non-enterprise view a particular feature may seem like absurd overkill. But someone, somewhere, needs it and there is a long and often impressive story of how it was achieved.

Re: Go is Google's language, not ours

#238

Post by new4thaccount »

cfcf14 wrote: post #214
doesnt_know wrote: post #162

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…

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…

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

Re: Go is Google's language, not ours

#239

Post by japanoise »

User23 wrote: post #145
calcifer wrote: post #63

Earlier quoted context omitted.

By my count, fewer than half of Rust's core team [1] are Mozilla employees, whereas the number is 100% for Go. Rust also has a very clear and open governance model [2], where the Go team is more closer to "we'll do what we want". [1] https://www.rust-lang.org/governance/teams/core [2] https://www.rust-lang.org/governance

Also Rust is observably a better Go than Go.

What an astoundingly ignorant thing to say

Re: Go is Google's language, not ours

#240

Post by jonathanstrange »

cryptos wrote: post #207
jonathanstrange wrote: post #164

Earlier quoted context omitted.

Rust is not a suitable replacement for Go.

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 experience, so I feel somewhat qualified to answer the question you ask---if you meant it seriously, which I doubt.

People use Go for its simplicity, good tooling, good backwards compatibility, fast and modern automatic garbage collection, extensive libraries, and fast compilation speed.

Yes, Rust is hard to learn, puts a constant high cognitive load on its users even once they have learned it, is relatively fast moving - meaning code you write now will likely not be idiomatic in a few years from now -, and has slow compilation speed. It has many other strengths, as you rightly point out, but most of them will not be a reason for someone who uses Go to switch to Rust. For example, most people who use Go do not need or want to quench the last performance out of their CPU and are less obsessed with zero-cost abstractions. Many C++ programmers, on the other hand, might appreciate these features of Rust.

Rust and Go are simply not languages that compete with each other. Go is a competitor to Python, VisualBasic/Xojo, and various server-side scripting languages like Ruby and PHP. Rust is a competitor to C and some uses of C++, and maybe to languages like Ada and Haskell in some safety-relevant domains that do not require a formal language specification.

The OP could have just as well suggested to use Ada instead of Go. It is possible to write Ada like Pascal, making it almost as easy to use as Go, but the suggestion still doesn't make much sense.

Post reply on HN