Hacker News Reader

Comment by jrs95 | Hacker News Reader

It's used very heavily for everything container related. It seems to be an excellent fit there, at the very least. It's also becoming an increasingly popular choice for startups when they need performance, which used to be something Java or C++ were typically used for.

Personally I've had a lot of fun using it, but prior to starting with it I'd mostly done Java and Node, so that may have something to do with it.

View on HN

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.

That is a good point, and it definitely is. But in this particular case I think it makes sense, although there's probably a "shiny" factor to it as well.

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 its forward-facing things)

I don't know how maintainable 10-year old Ruby code is though, on the other hand.

Today's startups are, mostly, tomorrow's failed businesses. The majority of the most successful startups of the last 15 years have generally used tried-and-true battle tested technologies in their successes: Java, C, C++ and PHP.

This isn't to say Go doesn't belong in that list, but simply to reinforce my point that what startups are using today shouldn't be an indicator of high quality technology that can (or should) gain more traction and use in the future.

And Ruby. Ruby is basically the new Java. As in it's no longer cool but is considered battletested and is now at the core of 10+ year old companies with code bases just as old that noone enjoys working on anymore.

That may be, in which case Python belongs in the same bucket. I'm not convinced, actually. Most of the "ruby shops" I know use it only for the most trivial of applications, being essentially rest-like proxies between clients and Java (or other language) services. But I don't know everything and anecdotes aren't data for sure.

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.

How can you write an efficient container without generics?

I keep reading this and I keep wondering what's stopping someone familiar with language design from writing generics code

They seem to take a lazy approach to feature development. Generics are complicated and bad, but having makeIntMap or makeStringSlice is...not great for developer productivity.

So let's special case `make()`, slices, channels, etc. so that some productivity is possible.

Then as they add library features they violate their own tenants as they find utility in these verboten constructs. Exceptions are bad...But we have panics which are in no way the same thing renamed. Never expose them outside a package...But closing an already closed channel panics. Random number generator functions panic on mundane and expected things, just like Java checked exceptions.

Example:

https://golang.org/pkg/math/rand/

``` func (Rand) Int31n

func (r Rand) Int31n(n int32) int32 Int31n returns, as an int32, a non-negative pseudo-random number in [0,n). It panics if n <= 0. ```

Standard behavior would be returning an error, not panicking,

See this:

https://blog.golang.org/defer-panic-and-recover

``` The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. ```

It's just an inconsistent and, quite frankly, disappointing language outside of goroutines and its interfaces. Those two make it possible to be productive, but with generics for instance a whole slew of new possibilities will emerge.

The simplicity is nice, but it's too simple and too inconsistent. All the verbosity of Java combined with the impenetrable inconsistency and abbreviations of C.

You can have your generics and many other nice things combined with the gccgo goroutines, channels and garbage collector by switching to Nim: https://github.com/stefantalpalaru/golib-nim

I wonder this too. For how important generics are claimed to be, it does seem strange that nobody has stepped up and helped out the core team in this capacity. They have been quite open about wanting generics, but do not have the resources to dedicate to implementing them in an acceptable fashion. But being an open source project, anyone can step up to fill that void.

How can a google backed project not have the resources?

I don't know, but Google does frequently complain about not being able to find talent. Some of this is through fault of their own, but it is easy to imagine that they have not found suitable developers to fill the spot, for whatever reason it may be. They have lots of other business goals for what developers they do have. Putting their people on generics at the cost of some other business function may not be a good choice, even if it is theoretically possible.

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?

It would be wasted work, because no one in the community would take it.

So better spend that time contributing to other parts of the Go ecosystem, or another programming language project.

By copy and pasting or code generation, as we've unfortunately had to do. Makes for messy things like DateRange paired with DateRangeInterval tree vs. a generic Range that works with an IntervalTree.

Container as in "Docker container"

That's just a jailed process. There's no reason to need a completely different language, especially one without any specific support for running untrusted code.

Well clearly that isn't a requirement, it just so happens that Docker, rkt, and most related technologies are all built with Go. etcd even uses grpc

gRPC isn't Go specific in any way. In fact I would imagine it's main implementation would be in C++, secondly Java and then maybe Go.

Use a language that has generics.

Snarky, but its such a tiresome argument. If you need something Go does not supply, use a language that fits your needs. There are a lot of programmers happy in Go, and thus happy without generics.

There are programmers who are happy using generics, thus write in Rust, Java, etc.

There is no language to bind them all.

Reply on news.ycombinator.com