8 ms·
So the current approach is providing some popular functions which would normally require generics to implement as built-ins?
by patates 10y ago
So the current approach is providing some popular functions which would normally require generics to implement as built-ins?
- giovannibajo1 10y agoI think they should at least implement a few builtin functions (that can be "real" generics) for common stuff that manipulate slices and/or maps. I'm thinking things like min/max, which are really distracting and are concepts that are more easily expressed as a concise function rather than an explicit loop.
- mattnewton 10y agoI understand the want to avoid over architected designs, but relying on a single party (who is not associated with your product or business need) to bless every abstraction you can use in your code base seems like a recipe for pain and awkwardness. Definitely limits me from wanting to make significant investments in go.
- limsup 10y agohttps://golang.org/LICENSE https://golang.org/LICENSE
- mattnewton 10y agoRight, so now I'm forking it and maintaining my own language to add a feature I just get for free in any number of reasonable competitors..
- karma_vaccum123 10y agoRust is ready, free, and open. Use it and stop complaining about Go.
- mattnewton 10y agoIn my case it's python, Rust has a bit more of a learning curve / productivity hit. I'm still complaining though because I like what Go is doing with concurrency and simplicity, but I think it would be almost perfect if it just trusted the user a bit more.
- woah 10y agoYou say you like the simplicity, yet you are complaining about it.
- mattnewton 10y agoBesides the fact that I think it's less simple to have ad-hoc compiler extensions for the standard library types that can't be replicated in userspace, so the alternatives are code generation and type erasure, it doesn't have to be an absolute principal! We can have generics without sliding towards some slippery slope of abstraction! You don't allow some kind of generics one day and wake up the next day with custom operators and monads. The buck really can stop at this one pain point.
- karma_vaccum123 10y agoOkay, that's nice, but the Go developers already picked their side in the debate many years ago. If you don't like it, use one of the many other tools available.
- stcredzero 10y agoI think it would be almost perfect if it just trusted the user a bit more. If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.
- mattnewton 10y agoI don't understand this attitude. I do use other languages, and I can tell you type polymorphism is not a mistake. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.
- quotemstr 10y agoWell, that's how C++ started. I'm honestly surprised nobody's forked Go or made a less obnoxiously opinionated front-end.
- j_s 10y agoOden: experimental, statically-typed functional language, built for Go ecosystem https://news.ycombinator.com/item?id=11183836 https://news.ycombinator.com/item?id=11183836
- mattnewton 10y agoThanks for the link, this looks pretty cool. Like Scala was on the JVM, this could be a sort of escape hatch for some people on the team.
- twblalock 10y agoI think you overestimate the number of people who care that much about Go. It's not very widely used. It would also be a massive effort to add generics to it at this point, because of the design choices the team made early on.
- giovannibajo1 10y agoNot sure what counts for "widely used", but it's now in the top20 TIOBE: http://www.tiobe.com/tiobe-index/ http://www.tiobe.com/tiobe-index/
- zzzcpan 10y ago> It would also be a massive effort to add generics to it at this point Not really. The easiest approach would take like a day for PoC.
- twblalock 10y agoWhat approach would that be?
- owaislone 10y agoSo you want other people to maintain something for you and do it the way you like? Obviously, it's not simple to just fork a project like Go and maintain it but the point is that it is not legally impossible. A group of people inclined enough to "fix" Go for themselves are completely free to do so. BTW, you might be interested in https://oden-lang.org/ https://oden-lang.org/
- mattnewton 10y agoNo, I want the language to have a standard way to extend it that's compatible with the core. Generics is a standard way to do type polymorphism without having the ship people another compiler.
- karma_vaccum123 10y agoWell, the Go developers and most of its real users (not bloggers who dabble) don't want to go this route. So seek your solution elsewhere.
- commentzorro 10y ago> So seek your solution elsewhere. Yeah, how dare he have an opinion that runs counter to the known truth. He has attacked the Body. He is not one with Landru.
- rectang 10y agoSomething we're slowly coming to terms with is the consequence of having open source without open governance. It's not clear to me that the language would be better if the project stewards accepted more feature requests, though. It is incredibly difficult to hold the line against feeping creatures and a noisy minority when the benefit of simplicity is diffuse.
- karma_vaccum123 10y agoforks are free, stop waiting for other people to do your work for you
- quotemstr 10y agoI was just ranting about this approach elsewhere. Go and QBasic are broken in the same way: both lack power in the core language and have special syntax for facilities that really ought to be normal calls into the standard library. In Go's case, we have goroutines, error flag omission, maps, and so on; in QBasic, we have LINE. A language's core syntax should not privilege its standard library above other libraries.
- stcredzero 10y agoA language's core syntax should not privilege its standard library above other libraries. I'm not so sure. Smalltalk had this in spades. There is a downside to this. Giving a bunch of 20-somethings the full power to basically change everything can result in code-bases which suffer from the chaos of over exuberant hubris. Go is deliberately favoring a certain set of conventions. To do this, they are also deliberately making it harder to change the language from within itself.
- sbov 10y agoIt's not about changing everything, it's about being able to make abstractions that aren't second class citizens. By giving this power, you also increase the consistency of the language.
- stcredzero 10y agoBy giving this power, you also increase the consistency of the language. Maybe. That's like the apocryphal story about the student asking a question if a particular proof step is really obvious, so the professor goes across the hall, derives stuff on the other blackboard for the next 30 minutes, then comes back into the lecture hall saying, "Yes, it's obvious." Maybe you increase the consistency of the language from one point of view, but what happens from the perspective of each individual project? What if this leads to projects where templates have been used to create 3 different template based "little languages" to make X, Y, and Z easier? You had 3 problems, but now you have 6. The oft written reply to that in these debates, is to limit the power of the template system -- but is that a robust goal under the group dynamics of the language community? I think not. One subliminal goal in the design of Go seems to be about privileging certain conventions to avoid a babel of roll-your-own conventions in large projects. This is all across the language and even in the toolchain.
- pjmlp 10y agoOr use code generation via the generate package. Go is a great C replacement for any use case where using a GC is an affordable option. Other than that, there are lots of other languages with AOT compilation to native code and better abstractions.
- pkaye 10y agoCan you give an example of what exactly generate does? All I can tell is that it me you call other programs like yacc to preprocess some files. So just a replacement for make?
- frou_dh 10y agoIt's basically the storing of a verbatim one-line command as a line comment in a .go source file rather than its traditional home of a line in a shell script or makefile. Imagine you found it intolerable to have an interpreter-dependant -- not even /bin/sh -- source file in your package directory (said another way, anything but .go source files in the package directory), but at the same time needed to somehow sneak in the functionality of a rudimentary shell script. The answer? Weave it into a .go source file and the Go toolchain will be able to pick up on and execute it (on demand, never automatically).
- wyager 10y agoIf I can use GC, why would I pick go over any of the other compiles-to-native languages with vastly friendlier type systems and language features? Rust, D, Haskell, etc. all offer similar performance profiles and are much nicer for the programmer.
- pcwalton 10y agoYes, that's the approach Go takes.