Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Go Programming Language and Environment

cacm.acm.org

Post reply on HN
Print view View original

141–150 of 250 posts

Re: The Go Programming Language and Environment

#141

Post by pclmulqdq »

pcwalton wrote: post #134
traceroute66 wrote: post #68

Earlier quoted context omitted.

To me, in the old Go vs Rust debate, there are two things that are abundantly clear in making a compelling case for Go. First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve. But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs). The problem to me with the Rust "no stdl…

There are curated lists of Rust crates to help with the second issue: https://github.com/rust-unofficial/awesome-rust And those two options don't strike me as equally unattractive. Writing everything that isn't in the standard library from scratch is completely impractical for modern apps. Nobody does that in Rust. Integrating crates from the ecosystem into your workflow is just part of developing in the language.

So put them in the standard library or have an organization that guarantees support for the next 10 years. The Rust community doesn't really understand why languages with a standard library have one. It isn't about performance or ease of use, it's about making guarantees about technical debt.

Re: The Go Programming Language and Environment

#142

Post by jerf »

mort96 wrote: post #88
DrBazza wrote: post #3

* "easy" concurrency * rich standard library, particular for internet facing apps * "simple" language * single binaries * massive corporate support * rich or full toolset The first and second point fortunately "coincided" with: the move to multi-core chips, and the "second" dot.com boom of the 2010s. Which you could probably attribute to the rise of (Google) Chrome, and the decline (finally!!) of IE6, which held back…

The concurrency is "easy" in that the syntax for spawning a thread is simple... but that's kind of it. Like other languages, it has a concurrent queue abstraction, and it has some syntax sugar to make using the concurrent queue nicer than some other languages. But like other languages, you end up in concurrency hell with mutexes and condition variables and semaphores and deadlocks. It has a concurrency story that's a…

"Like other languages, it has a concurrent queue abstraction, and it has some syntax sugar to make using the concurrent queue nicer than some other languages. But like other languages, you end up in concurrency hell with mutexes and condition variables and semaphores and deadlocks."

It is true that technically, Go does not force good multithreaded code. What it has is good community practices, and libraries that work with those good community practices.

And there is a good case to be made that a stronger language (like Rust, or Erlang, perhaps Pony) is still necessary to really make multithreaded code take off.

However, if you got yourself caught in "concurrency hell with mutexes and condition variables and semaphores and deadlocks", it is because you weren't programming with the community's best practices.

I mean, I know there's a certain vacuity to "just do it right", but in this case, you really didn't do it right. And maybe you would be better off in a language that wouldn't permit you to do it wrong (Erlang, Pony) or a language that tells you to stop it you can't do that (Rust), but there was almost certainly a better way to get it done.

Re: The Go Programming Language and Environment

#143

Post by krylon »

eb0la wrote: post #30
vintermann wrote: post #16

I think it misses * Made by really famous veteran language designers * Backed by Google Not saying it doesn't deserve its popularity, but most of the things listed are not necessary for explaining its popularity, and none of them (even taken together) are sufficient.

In my case "backed by Google" was a deterrent, not a feature. I gave the language a chance after trying Rust (backed by Mozilla - which was a feature to me ;-) and I found it easy to start. Go is very well documented: That was the killer feature for me. No more search tutorials / videos etc. - just get the go book, read it, and start coding. Of course there are tutorials and videos everywhere for fun stuff. But good…

The documentation is a big point, but to me, two other points are just as important, maybe (probably) more so:

1. The standard library is very good in the sense it covers a fairly wide range of areas and gives you some idea of how to use Go idiomatically (I feel this is more important in Go than in other languages I've used).

2. The language just feels right to me. I have not met any other language that feels like it was optimized for my brain that well. I recently made an attempt at learning Rust, and I kind of got it, but I eventually gave up because the benefits did not seem worth it to me in light of the steep learning curve. Go just clicks with me. It's not the best language ever by whatever metric you choose, but for my needs, it is the right language.

Re: The Go Programming Language and Environment

#144

Post by tptacek »

gameswithgo wrote: post #67
intothemild wrote: post #42

Earlier quoted context omitted.

I agree here. Using the two examples go and rust, Go's documentation is on another level compared to rust, it's more common to see examples in Godoc's than in Rust documentation... That's not a failure of Rust or the maintainers, it's just a different culture I guess. If I want to do something in Go with a new lib, i can easily put together what I need to do using the documentation. Where as with Rust, it's often con…

I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Especially if you are a programmer with a background in any of the C-ish syntax languages (C,C++, javascript, Java, C#, etc), its just really easy to pick up. Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.

They both have good patches of documentation and bad ones. They're both better documented than, say, Ruby. Go has multiple edges, not just simplicity, but also a larger user base. You couldn't reasonably disqualify either language basd on their documentation. Certainly, Go is easier to pick up than Rust, but nobody's arguing that.

Re: The Go Programming Language and Environment

#145

Post by earthboundkid »

lifefeed wrote: post #129
vintermann wrote: post #16

I think it misses * Made by really famous veteran language designers * Backed by Google Not saying it doesn't deserve its popularity, but most of the things listed are not necessary for explaining its popularity, and none of them (even taken together) are sufficient.

The "Backed by Google" is an under-appreciated social piece of the puzzle. It's not just that Go has institutional backing, it's that googlers produce a lot of startups, and they bring their favorite things with them, and quite often one of those things is Go.

That's why we all use Dart today.

Re: The Go Programming Language and Environment

#146

Post by imiric »

jasode wrote: post #75
vintermann wrote: post #16

I think it misses * Made by really famous veteran language designers * Backed by Google Not saying it doesn't deserve its popularity, but most of the things listed are not necessary for explaining its popularity, and none of them (even taken together) are sufficient.

>- Made by really famous veteran language designers - Backed by Google Looking at decades of how various programming languages gain popularity, those proposed reasons don't seem that convincing when we look at counterexamples . E.g. counterexamples of unknown (at the time) creators creating popular languages : Bjarne Stroustrup (C++), James Gosling (Java), Rasmus Lerdorf (PHP). E.g. counterexamples of famous computer…

I think there's another big reason: simplicity. The language spec is very short and readable, and there are very few concepts to learn to be productive with it. Compared to most other popular general purpose languages, this is a refreshing–if at times frustrating–quality to have.

Re: The Go Programming Language and Environment

#147

Post by Matl »

gameswithgo wrote: post #67
intothemild wrote: post #42

Earlier quoted context omitted.

I agree here. Using the two examples go and rust, Go's documentation is on another level compared to rust, it's more common to see examples in Godoc's than in Rust documentation... That's not a failure of Rust or the maintainers, it's just a different culture I guess. If I want to do something in Go with a new lib, i can easily put together what I need to do using the documentation. Where as with Rust, it's often con…

I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Especially if you are a programmer with a background in any of the C-ish syntax languages (C,C++, javascript, Java, C#, etc), its just really easy to pick up. Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.

> I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust.

Having used both I disagree; Go's stdlib is extremely well documented, even unexported types are along with examples etc. Rust docs are useful but more often feel like there's many things you're expected to figure out from the source and only minimal examples are given.

I am a fan of Rust, but I think Go's docs are an example to follow. The more complex the language, the richer docs it should have imo.

Quite aside from docs, Go's tooling situation is also better.

Re: The Go Programming Language and Environment

#148

Post by cy_hauser »

UncleMeat wrote: post #98
ampersandy wrote: post #83

Earlier quoted context omitted.

I really dislike this meme of pointing out that Google has deprecated a lot of projects. Do people actually expect Google to staff people & resources running every project they've released forever? A more interesting comparison would be open source projects that Google has abandoned or failed to properly hand over control of to the community, especially if we're talking about Go.

I agree. It is true that Google has some poor product management and has some hilariously inept examples or product coherency (chat being the biggest disaster). But people praise startups for pivoting (read: killing a product) and (in general) demand innovation over glacial iteration. Trying new stuff necessarily means killing things that don't work (or paying a whole bunch of engineers to maintain a dead product for…

>> But people praise startups for pivoting ...

Yes, but you discount the size of Google. Some of the things Google has killed have been large enough to have been considered successful products for a startup. They kill a "tiny" product because it's only large enough to be what some startup hopes to become. Google Reader is my favorite example of this. Multiple companies now exist in the soil on top of that grave.

Re: The Go Programming Language and Environment

#149

Post by vlunkr »

jasode wrote: post #75
vintermann wrote: post #16

I think it misses * Made by really famous veteran language designers * Backed by Google Not saying it doesn't deserve its popularity, but most of the things listed are not necessary for explaining its popularity, and none of them (even taken together) are sufficient.

>- Made by really famous veteran language designers - Backed by Google Looking at decades of how various programming languages gain popularity, those proposed reasons don't seem that convincing when we look at counterexamples . E.g. counterexamples of unknown (at the time) creators creating popular languages : Bjarne Stroustrup (C++), James Gosling (Java), Rasmus Lerdorf (PHP). E.g. counterexamples of famous computer…

I would also add that the tooling is very good. A few examples:

- Built-in test suite that is simple but extensible. Also fast because it can test different packages simultaneously.

- Building is easy. Unless you're doing something unusual, you probably don't need a Makefile or any configuration, you just run go build .

- Gofmt means that everyone's code looks the same and you don't have to waste your time arguing about indentation or whatever. Some may see this as a downside.

Re: The Go Programming Language and Environment

#150

Post by timbit42 »

anthk wrote: post #119
timbit42 wrote: post #91

Earlier quoted context omitted.

>> Made by really famous veteran language designers > Yeah that’s a positive No, that's also a negative. C is close to assembly and produces fast code but it's weakly typed and very unsafe. Pascal was the strongly typed and safe option but people went for C because speed was considered more important than safety back when processors were slow. In today's online world, we've realized safety is more important than spee…

Pascal in DOS was as fast as C if no more.

Turbo Pascal wasn't entirely compliant to the Pascal spec either.
Post reply on HN