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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

281–290 of 402 posts

Re: The State of Go

#281

Post by solidsnack9000 »

skybrian wrote: post #83
MichaelGG wrote: post #65

Earlier quoted context omitted.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

The preference for maps and folds looks like a fad to me. I can use them but I don't think it makes the code any easier to understand, just different.

A 70 year fad.

Re: The State of Go

#282

Post by solidsnack9000 »

sidlls wrote: post #70
MichaelGG wrote: post #65

Earlier quoted context omitted.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

Maps and folds are implicit loops. For some explicit is simpler.

Loops are just implicit goto...

The argument for maps and folds is the same as the argument for structured programming in general: using common/reusable idioms brings clarity and familiarity.

Re: The State of Go

#283

Post by solidsnack9000 »

ptero wrote: post #21

IMO the Go goal is to be an enhancement of C. It is not as expressive as some existing languages (i.e., Go programs may be longer), but it is very good for translating clearly thought through logic into efficient machine code. It supports some of the features that original C lacks (networking, parallelism, channels, etc.), which to me is a very good thing. With minimal forethought this allows writing programs that ca…

Libraries may be a stumbling block for Go, though, because C interop is somewhat slow. Photoshop, Python, Postgres, &c are not all likely to support plugin/extension interfaces based on Go calling convention anytime soon.

Re: The State of Go

#284

Post by ino »

tdestan wrote: post #275
DrBazza wrote: post #42

Given some of the comments, I'll make the same comment I've made before: Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. I'm a C++ dev, and I really enjoy using Go. If you don't like what it does or how it does it, it's not for you. Either way, people are out there using it, making systems from it, and generally getting on with…

> Stroustrup is right, there are languages that people complain about, and languages that no-one uses. This quote has always struck me as an intellectually lazy cop out to avoid engaging with criticism. It's an indirect appeal to the fallacy of false equivalence: "If people actually used language $Foo, surely they would complain about it just as much, because all programming languages are basically the same." > Eithe…

To me that quote says that there's no such thing as a perfect language.

Different tools for different jobs. If you wander too far from the main domain of the language, you'll find quirks and it's maybe better to use something else.

Re: The State of Go

#285

Post by solidsnack9000 »

Cthulhu_ wrote: post #170
sidlls wrote: post #72

Earlier quoted context omitted.

I'm not convinced that using startups as a metric for anything programming related is a good idea. At least not startups here in the Bay Area, which seem to me to be very fad driven.

Today's startups are tomorrow's huge stack of legacy software that Nobody Wants To Touch Because It's Our Core Business though; I'd say Go is a pretty good choice for those due to its simplicity and shunning of 'clever' code. Companies like Paypal, Ebay, and probably a few others have (had?) a huge load of old Java code and only recently spent a lot of time cleaning that up (iirc Paypal went with Node, at least for i…

That legacy software has come out of the web or backend stack of startups? Most of Facebook is written in PHP but Cassandra is written in Java.

Re: The State of Go

#286

Post by solidsnack9000 »

zzzcpan wrote: post #186
Buttons840 wrote: post #167

Earlier quoted context omitted.

I've been thinking about a two way compiler with a primary focus on producing readable code. If such a compiler targeted Go or Java, you could white your "Go+" code (for lack of a better name) in a higher level language with more features, and have it compiled to readable Go code. I don't know to what extent this is possible, but if it was good enough you could be a Go developer while rarely writing actual Go code.

It is very much possible, there are already DSLs that generate Go code. I'm even doing that myself.

Can you link some examples?

Re: The State of Go

#287

Post by solidsnack9000 »

geoka9 wrote: post #105
coldcode wrote: post #32

I for one will be more interested in using Go when Jetbrains finishes their IDE. Clearly not everyone cares to develop in an IDE but after 33 years of doing it, I prefer the idea. Give Swift (my current work) as many years as Go has had (10 years), and maybe I won't find Go that interesting any more.

To each their own, but Go is probably the only mainstream language that has first class integration with text editors. So I wouldn't let that stop me from using it, unless you can't see yourself using a text editor at all.

What is the first class integration? My experience using Ruby, Python and Rust (via Racer) with Vim+Syntastic has been pretty good.

Re: The State of Go

#288

Post by solipsism »

dilap wrote: post #81
grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that. An excellent example is the handling of this bug report(§): https://github.com/golang/go/issues/12914 which resulted in this language-change proposal: https://github.com/…

I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools

Seems to be some cognitive dissonance (in the modern erroneous sense of the word) going on. This was a hack necessary because the design of the library wasn't fully thought out. Imagining the world would one day become Google is not thinking things out.

Re: The State of Go

#289

Post by tasuki »

fnl wrote: post #267
Strom wrote: post #223

Earlier quoted context omitted.

It's even easier to mishandle errors and get deadlocks in C++. That is in addition to all sorts of other fun like buffer overruns. If the team is capable of not messing these things up in C++, then they are more than capable of not messing up in Go.

Modern C++14 provides quite good support on those fronts, and modern Java8 has lost most of its "code notoriety". But that's just arguing back and forth. Here's the real argument: What popular OSS projects of noteworthy scale are being developed in Go? I know a few dozens in either Java or C++, and even a few fairly noticable Scala projects (Spark, Flink, Play, ...), but I yet have to see anything written in Go that…

Docker is written in golang: https://github.com/docker/docker

Re: The State of Go

#290

Post by benjaminjackman »

fnl wrote: post #267
Strom wrote: post #223

Earlier quoted context omitted.

It's even easier to mishandle errors and get deadlocks in C++. That is in addition to all sorts of other fun like buffer overruns. If the team is capable of not messing these things up in C++, then they are more than capable of not messing up in Go.

Modern C++14 provides quite good support on those fronts, and modern Java8 has lost most of its "code notoriety". But that's just arguing back and forth. Here's the real argument: What popular OSS projects of noteworthy scale are being developed in Go? I know a few dozens in either Java or C++, and even a few fairly noticable Scala projects (Spark, Flink, Play, ...), but I yet have to see anything written in Go that…

I think IPFS is being made in go. Not sure if that qualifies as industrial sized or not.
Post reply on HN