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

191–200 of 402 posts

Re: The State of Go

#191

Post by steveklabnik »

oscargrouch wrote: post #126
sametmax wrote: post #111

Earlier quoted context omitted.

I don't know. I feel like if I need something productive, I would go very high level like Python. In the VERY rare case Python is too slow, I would go really low level like rust. I don't see the interest for something that not really low level, but not realy high level either like Go. If concurrency is the main issue and is the niche I'm targeting, I would go Erlang or Elixir. I have a hard time finding any use case…

For me Go is the goto language for usecases where Python and Java were used. Python is great for tooling, and Java was the primary language for the backend. So now, whenever i think about tooling or backend, Go is the primary answer, because its good in both paradigms. The other languages i use is C++, and Swift, each one with their own niches. C++ for complex machinery, that requires more control and integration wit…

One nice thing about the "rewrite C++ in Rust" is that oh can do it incrementally; we're taking the same approach for Firefox, for example.

Out of curiosity, what are the libraries in C++ that you miss in Rust, or would have to re-write?

Re: The State of Go

#192

Post by closeparen »

jankiel wrote: post #79
user5994461 wrote: post #60

Earlier quoted context omitted.

Of course I mean ruby on rails when I say ruby. Initial release 2005. i.e. Young.

Ruby on Rails is a web framework, not a language. Also web dev is about shipping a product fast, that's why you don't see Java there.

You do see a ton of Java web apps in in-house and consultant-built line of business applications. Just not so much from product companies.

Re: The State of Go

#193

Post by steveklabnik »

IshKebab wrote: post #82
rpercy wrote: post #35

Earlier quoted context omitted.

100% agree re: readability (as I've mentioned elsewhere). I've actually been very surprised at the near-ubiquity of Go in the modern infrastructure/tools space though. Seems like each new OSS product I evaluate is written in Go. See companies like Cloudflare, Hashicorp, InfluxData, CoreOS, and, obviously, big projects like Kubernetes.

I think that's mostly because Go trivially generates static binaries, and cross-compiling is also trivial (as long as you don't use CGo). I can't actually think of a single other language that matches that. Rust might get there one day but cross-compiling still requires a C cross-compiler (ugh) and C dependencies (e.g. OpenSSL) are often dynamically linked.

Cross compiling shouldn't require a C compiler unless you have a dependency on C code.

Most wrappers should at least provide an option to statically link the C; I know the OpenSSL ones do.

Re: The State of Go

#194

Post by danellis »

pvg wrote: post #166
vvanders wrote: post #155

Earlier quoted context omitted.

Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.

Perhaps you could help clear up the misconception by fixing Wikipedia's 'System Programming' and 'System Programming Language' entries.

It might also be worth commenting on these[0] Stack Exchange answers, too.

[0] http://softwareengineering.stackexchange.com/q/151610/54726

Re: The State of Go

#195

Post by twic »

Qerub wrote: post #110
jrs95 wrote: post #76

Earlier quoted context omitted.

I suppose most of my negative experiences with it are specifically in the context of using it to build microservices. The memory usage alone created a bit of a problem, I ended up using nearly all of my 16GB of RAM when I had to run many services simultaneously. And because the functionality of any given service was fairly minimal, there really wasn't a need for a framework like that. The autoconfiguratuon was also a…

I usually get rid of @EnableAutoConfiguration and then selectively import the auto-configuration classes I actually want with @ImportAutoConfiguration.

A Spring developer once mentioned, on a mailing list post i have long since lost, that the autoconfiguration stuff is pretty much demo-ware. It's good for getting a simple app up and running fast, but for anything serious, you should import the configurations manually, exactly as you say. Fortunately, that's an easy enough transition to make at any point in a project's lifetime.

Re: The State of Go

#196

Post by Keyframe »

One thing I never understood with Go was what's the deal with multiple return values in functions? Why would you do this? What was the reasoning?

Re: The State of Go

#197

Post by twic »

cs02rm0 wrote: post #122
hepta wrote: post #47

Earlier quoted context omitted.

What are your problems with spring boot? What bloat are you referring to?

For me, I imagine the dropwizard guys sat round asking each other what the best servlet container is, web MVC tool, ORM, DI framework, etc, etc. and they choose the very best they can think of for a dev to work with. Then a couple of years later that company comes along where they ask the same questions and but there's a guy with Tourette's in the corner and Every. Single. Time. the answer to the question is SPRING!!…

Actually, in that company, the answer isn't always Spring Boot. Sometimes it's Cloud Foundry.

Re: The State of Go

#198

Post by chimeracoder »

prodigal_erik wrote: post #169
chimeracoder wrote: post #74

Earlier quoted context omitted.

> Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I've been writing Go full-time as my primary language for nearly five years. Before that, my languages of choice were Lisp[0] and Python, with R as a very distant third choice[1]. I have always been a polyglot and enjoyed experimenting with any new language I could try out - you'd be hard pressed to name a non-esoteric la…

>I strongly reject the criticisms that Go is meant for "mediocre" programmers I don't know how else to describe people who don't resent being second-class citizens under the library designers, who don't insist on being able to create their own abstractions and use them with the operators that slices or maps support. The language has extensible interfaces but doesn't use them for things like iteration and equality.

> I don't know how else to describe people who don't resent being second-class citizens under the library designers...

One suggestion: describe them as "people who have a different opinion than I do", rather than automatically concluding that anyone who doesn't feel the same way as you do about something must be "mediocre". There are popular languages that I can't stand writing, and languages that I think are badly designed, but I would never be tempted to say that those languages are "for mediocre programmers" just because they don't have the attributes that I look for.

As a polyglot, I can definitively say that every language in widespread use is "missing" something in its design that, at first glance, would be glaringly obvious to someone who's used to a different language. If anything, the sign of a good programmer (as opposed to a mediocre one) is the ability to conceptualize why a language might be successful despite (or even because of) this apparent "flaw".

Re: The State of Go

#199

Post by yokohummer7 »

chimeracoder wrote: post #189
yawaramin wrote: post #180

Earlier quoted context omitted.

> But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, ... It's not a criticism, it's literally how the Go language creators themselves describe it. See the Rob Pike quote at http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

> It's not a criticism I'm responding to criticisms in this and other HN threads about Go, so yes, I'm talking about a criticism. > it's literally how the Go language creators themselves describe it. See the Rob Pike quote Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same th…

> Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same things that excite researchers about programming languages don't lend themselves to good software engineering in industry. (And he's right).

If that was the case, it was a very dubious thought. Before Go was launched, the languages used in Google were Java, Python and C++. None of them look academic, none of them seem to require another language that is specifically designed to "unexcite" newcomers. Neither is functional, really.

Re: The State of Go

#200

Post by yawaramin »

chimeracoder wrote: post #189
yawaramin wrote: post #180

Earlier quoted context omitted.

> But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, ... It's not a criticism, it's literally how the Go language creators themselves describe it. See the Rob Pike quote at http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

> It's not a criticism I'm responding to criticisms in this and other HN threads about Go, so yes, I'm talking about a criticism. > it's literally how the Go language creators themselves describe it. See the Rob Pike quote Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same th…

OK. I should have said, it's not inherently a criticism, it's just a fact. That others may choose to use it as a criticism--well, that's upto them.

Personally I don't think there's such a thing as a 'mediocre' programmer, I think there are programmers who have studied and trained in concepts, techniques and idioms and those who haven't.

It seems pretty clear from that quote that Google is hiring kids fresh out of college, and instead of training and educating them they're throwing them at an intentionally simplified language to get them to churn out code quickly.

Also I find it hard to believe that type-safety guarantees don't lead to good software engineering in industry, when the biggest industrial users of Python, PHP, JavaScript and Clojure--the dynamic language titans of the tech industry--have all recently developed and popularised type systems for them.

And in fact, I also don't see how you can derive a criticism of academia out of those quotes when they mention 'researchers' only in passing, as a point of comparison to talk about their coders' skill level. Too much mental gymnastics for me.

Post reply on HN