6 ms·
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 ch
by jrs95 10y ago
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.
- greg7mdp 10y agoHow can you write an efficient container without generics?
- deleted 10y ago[deleted]
- labrador 10y agoI keep reading this and I keep wondering what's stopping someone familiar with language design from writing generics code
- Zach_the_Lizard 10y agoThey 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/ 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 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.
- stefantalpalaru 10y agoYou 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 https://github.com/stefantalpalaru/golib-nim
- randomdata 10y agoI 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.
- algesten 10y agoHow can a google backed project not have the resources?
- randomdata 10y agoI 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.
- Buttons840 10y agoI'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.
- zzzcpan 10y agoIt is very much possible, there are already DSLs that generate Go code. I'm even doing that myself.
- solidsnack9000 10y agoCan you link some examples?
- pjmlp 10y agoIt 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.
- deleted 10y ago[deleted]
- Zach_the_Lizard 10y agoBy 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.
- bboreham 10y agoContainer as in "Docker container"
- prodigal_erik 10y agoThat'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.
- jrs95 10y agoWell 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
- jpgvm 10y agogRPC 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.
- bsg75 10y agoUse 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.
- sidlls 10y agoI'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.
- jrs95 10y agoThat 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.
- Cthulhu_ 10y agoToday'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.
- sidlls 10y agoToday'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.
- jpgvm 10y agoAnd 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.