10 ms·
I wish they would just freeze the language and not add anything. I like it the way it is. I feel like the general attitude of software developers is: if it isn’
by marcrosoft 6y ago
I wish they would just freeze the language and not add anything. I like it the way it is. I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stable unchanging software.
- deanCommie 6y agoMeanwhile I will never use Go until it has generics. I wonder if there is more of people like me or people like you...
- leafboi 6y agoChange and human progress is an inevitability. More people are like you. Mind you, change is not necessarily always for the better but it always occurs no matter what. Adapt or die.
- axaxs 6y agoBased on the popularity of the language alone, I can say rather definitely the latter.
- MereInterest 6y agoI'm sure that being backed by the largest software/advertising company in the world has nothing to do with its adoption rate, and that popularity is a direct mapping of quality of a programming language.
- shirro 6y agoThe Google backing and hype kept me away from Go for years. After being stuck with a succession of scripting languages that weren't doing it for me and being frustrated at the time it takes to be as productive in something like c, Go is really the sweet spot of readability, reliability and productivity for me. I think the Google backing may not be as advantageous as some people think. Dart did not become a popular language and would probably have died out if Flutter hadn't come along.
- pansa2 6y agoYeah, Go being from Google is not necessarily a good thing. It means the language is under the control of a single company and, what's more, a company that is well-known for giving up on many of its projects.
- dhagz 6y agoAnd the open-source aspect of Go's development is managed entirely in Google services (the dev mailing list is a Google Group, you can't contribute without a Gmail address...the list is long). Sure it's hosted on GitHub, but the majority of the real conversations are elsewhere.
- Ericson2314 6y ago> frustrated at the time it takes to be as productive in something like c Don't worry, no is productive in something like c > After being stuck with a succession of scripting languages that weren't doing it for me I am saddened yet also consoled everyone that likes Go comes from the scripting languages. That's such a low bar to beat!
- geodel 6y agoRight. Programing languages by advertising companies have high adoption rate.
- coldtea 6y agoWell, dev-oriented projects by Google and Facebook fair well...
- takeda 6y agoYou're saying that as if it's not true How many languages are there released by advertising companies? Just to show the influence, python was an obscure programming language until Google started using it.
- albertsondev 6y agoA good example lies in Kotlin, as well.
- pjmlp 6y agoActually no, Zope was quite famous during the first .com wave. But Python has had many interesting sponsors throughout the years, not only Google.
- scarface74 6y agoI would think that would be a knock against it with the reputation of Google abandoning projects.
- ori_b 6y agoYeah. That's why it's about as successful as Dart.
- pjmlp 6y agoI guess the political wars of JavaScript vs Dart, ChromiumVM and Chrome team dropping Dart on the floor, causing the departure of the original design team, kind of helped to Dart's success. The political wars at Google with Dart are quite visible from outside, with Fuchsia picking up Flutter, and strangely the future of Android UI looks pretty much like Flutter, after too many times asking Android team about what was their opinion on Flutter for Android development at IO Fireside, meanwhile the developers' survey has had questions about how much we cared to see it supported on Kotlin multi-platform. So yeah, had Chrome decided to push Chromium VM no matter what, Dart would be as successful as Go by now, after all younger generations don't seem to have any problem being Chrome developers.
- imtringued 6y agoDart is an example of what happens to a language when corporate support is taken away. People lose confidence in the language.
- coldtea 6y agoThe popularity compared to what? How do the numbers stack up?
- axaxs 6y agoOh, I'm not by any means saying it's the most popular language. I'm just comparing strictly based on the comment, people who like go vs people who will never use it because of its lack of generics.
- mantap 6y agoJava has genetics and it is many times more popular than Go. I'm not sure absolute adoption of Go is a good way of divining programmers opinions on genetics.
- dpc_pw 6y agoTo be fair I will probably not use it even if it has generics, at least not if I can avoid it. It will still have nulls, lack sum types, have messed up dependency management and so on. Though in times when I have to use (because it was not in my control), I would rather have them.
- GolDDranks 6y agoYou summarised almost perfectly my gripes with Go. Thank you. Just to add one: any type has a "zero values" as a default value, and the compiler doesn't force you to initialize stuff. That single misfeature caused basically all of my grey hair, and I'm still young.
- marwan-nwh 6y agoWhat do you like to use?
- Diesel555 6y agoVisual Basic, strict mode.
- kerkeslager 6y agoI'm not a stickler for any specific features: it's more about having a group of features that synergize with each other. So far I've not found a language that does this perfectly, but I've found a few that I think do better than Go: 1. Elixir: Pros: Erlang threading model is clearly the best I've come across, expressive syntax, strong data structures and algorithms in standard library. Cons: Slow for some things, anemic standard library for common problem domains, small community. 2. Python: Pros: Strong standard library for common problem domains, supplemented by a strong community set of libraries. Generally intuitive. Cons: Slow for some things, poor threading, inconsistencies in syntax, general dominance of configuration-oriented programming frameworks rather than libraries in the community, types are just not quite strong enough. 3. C#: Pros: strong type system, speed. Cons: dependency injection hell, MS walled garden. I'd like to add Rust and/or OCaml, to this list, but I don't know either well enough to be confident.
- bcrosby95 6y agoA language can't be everything to everyone. Given its age it is very widely used. So I'm not sure the lack of genetics is really hurting adoption. You run the risk of driving away existing users but not attracting people that already wrote the language off. I say this as someone that doesn't use it for similar reasons as you. But I have ran into the above trap before.
- deanCommie 6y agoI don't know, in any production system without generics, the code just looks amateurish...
- pansa2 6y agoThe thing is, for people who want generics, sum types, non-nullability etc, there are plenty of other languages to choose from. For those who specifically want a simple language, Go is (was?) one of very few options.
- Ericson2314 6y agosum types and non-nullability are not complex.
- sa46 6y agoSure they are. Sum types usually mean a pattern matching syntax, destructuring, and a different declaration syntax. Rust’s match keyword, for example, is a powerful construct covering guards, destructuring, and different types of binding. Non-nullability requires generics for a result type which is a huge source of complexity. Generics impact parsing, code gen and runtime efficiency.
- entha_saava 6y ago1) Non nullability can be implemented in language without generics, and for all types instead of just pointer types. That can be used to enforce null checking with pattern like: if let var_name = nullable_var { // use var_name as non nullable } else { // nullable_var in null, handle null case } And any tagged union can be reduced to nullable of member type without pattern matching, with some specific syntax. It is not hard with an imperative language. 2) Without generics, you are probably reinventing the same code, or using reflection which is not even type safe, or worse, using code generation. For instance D has generics AND good compile times. I guess Nim compiles fairly well too. Or you can choose partially type erasure based generics with a different tradeoff. There is no point in not having useful generic functions on generic data structures in a language that came in 2000s. Once write Python or ruby or something and come back to Go. People without knowledge of other languages with generics tend to think you are writing for loop in while loop in if - else break monstrosity because native compilation and performance come with a cost in expressiveness, while it need not be.
- gjs278 6y agoI don’t know what a generic is and nobody can explain it correctly. the language is fine as is and can do anything you want. if it takes a bit more code to cover what generics would have done, I don’t care. if it’s preventing someone like you from using it, maybe that’s a good thing.
- badrequest 6y agoAs we all know, the only true value a programming language has is whether or not a majority of programmers align with its ethos.
- qtplatypus 6y agoGiven the Polls of go programmers have consistently shown that the lack of generics is a problem.
- lkramer 6y agoWhere do I participate in those polls? I'd like to put my voice against.
- zeroxfe 6y agoI think the team is doing an excellent job with carefully and methodically evolving the language.
- nkozyra 6y agoLet's be fair, they held out against a very vocal community for a very long time. They used that time to carefully evaluate the utility and ethos compatibility of generics. And they're taking time thoughtfully implementing them. This is what you want out of a language. Thoughtful design and responsiveness.
- ed25519FUUU 6y agoThis is a fair comment. Even the article we’re reading is basically the thought behind why square brackets is the best way to signify a generic. There’s mentions of parsers and that kind of design thought is important in a language.
- hota_mazi 6y agoAnd I bet that if Go ever gets generics, they will look extremely similar to everything everyone has been telling them for years, even though they dismissed that feedback for years as silly. The switch from parentheses to square brackets is just the first step toward that admission.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- pjmlp 6y agoSomething interesting happened when comparing the history of systems programming languages from the early 60s, throughout the 70 and 80's. The resistance of C's design adopting anything that was already considered good practices in designing secure OSes outside Bell Labs, has a very familiar feeling.
- Jach 6y agoIt's amazing how we got here... Your comment immediately reminded me of Tony Hoare's Turing Award lecture (https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf) which contains (among other fun/depressing gems to reflect on) a bit on the obvious-even-to-customers sanity of avoiding core dumps or worse due to a lack of bounds-checking. "A consequence of this principle [of security] is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to -- they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
- D_B_Koopa 6y agoI think the go authors have had a reasonable balance of this when adding new features. Generics are quite useful.
- deleted 6y ago[deleted]
- coldtea 6y ago>I wish they would just freeze the language and not add anything. I like it the way it is. And a big share of users wishes they add generics - judging from it being the #1 voted feature in the annual Golang polls. Not to mention the potential users that are put off because it doesn't have Generics...
- lostmsu 6y agoOnce they add generics, I will stop laughing at the language, but still probably won't use it. There's very little if anything it adds over C# or modern Java.
- geodel 6y agoTrue. I think really a lot of people who are clamoring for generics in Go would already be working with more productive languages. Generics is mainly for users who have committed to Go and new productive language features could possibly help them.
- coldtea 6y agoOn the other hand, programmers don't always pick which languages they get to work with. If I'm forced to use a language, it might as well have Generics than not...
- pjmlp 6y agoUntil Docker or Kubernetes fad doesn't go away, having to deal with Go is something that those of us that rather use C# or modern Java have to face, so it will help if the language catches up with modern times.
- pas 6y agoBut those large codebases will not be updated for some time. Or do you mean that at least new features could be written using generics?
- takeda 6y agoYou can always stop upgrading and join the python2.7 crowd (apparently not as big as it appeared it would be a few years ago).
- marcrosoft 6y agoPython 3 upgrade was a complete disaster that took over a decade. They should have just called it a different language name and started at 1.0. Edit: And, if Go doesn’t learn from Perl and Python’s mistakes it is going to suffer greatly.
- takeda 6y agoI disagree, Python is now stronger than it was years ago. Now all companies that I interact with are magically on Python 3. They were also estimating that it will take this long. IMO they should give shorter time to upgrade, because everyone was waiting to absolute last minute to migrate.
- Spartan-S63 6y agoAs it stand today, there is some elegance in its simplicity, but the lack of generics makes it unergonomic to write libraries. It's a good language to build applications, though. This is less to do with the language and more about the standard library, but it has tons of cross-platform quirks that I feel aren't handled well. For example, Rust's standard library makes cross-platform work less footgun-filled, IMO.
- gonzo41 6y agoHas there been discussion on just creating a golang managed collections library that's generic and not adding general generics into the language?
- coronadisaster 6y ago> I think we should start putting weight on stable unchanging software. I think that they are just afraid of the income to stop coming in... so they keep working.
- pansa2 6y agoI'm reminded of this Rob Pike quote from 2015 about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] [0] https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
- entha_saava 6y agoAs opposed to us who only use features developed by Bell labs.
- Jach 6y agoI still find the most insightful Rob Pike statement (and the one that maybe induces a bit of forgiveness) that can give an idea for why Go is the way it is to be from this slightly older talk: "The key point here is our programmers are Googlers, they're not researchers. They're typically fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to be able to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... at 20:33
- perryizgr8 6y agoWow that's really condescending.
- kerkeslager 6y ago> I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stable unchanging software. I agree with this. However, the key is to stop once you've implemented the right set of features. Minimalism is about implementing the minimum necessary and no less. I firmly believe that generics are in the right set of features for a statically-typed programming language. The problem is that Go has already implemented some features which clearly aren't in the right set of features--such as `go generate`--which already allow you to implement a crappy version of generics. So now you're starting to move toward the problem that C++ and (to a lesser extent) JavaScript have, which is that there are 5 different ways to do the same thing, which don't necessarily interoperate well with each other. If go were being implemented from scratch, it would be better to have generics and not `go generate`, but given the language already has `go generate`, there's certainly some downside to adding generics. It's not a simple choice.
- pjmlp 6y agoThe irony of go generate is that a similar approach was taken by C++ compilers back in the early days. To give a proper example, Borland C++ 1.0 for MS-DOS had BIDS, so their own collections library with safe strings and vectors, as it happened with all major C++ vendors back in the day. Well BIDS 1.0 used pre-processor tricks to generate the desired code, basically you would define the desired types and then include the data structure you cared about, and do this multiple times. Eventually templates came into the picture and BIDS 2.0 shipped with a template version, based on the ongoing discussions at ISO. We are talking about 1990 here. As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away.
- kerkeslager 6y agoThe basic problem I see with Go is that its users are ignorant of how other languages have solved (or failed to solve) problems. > As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away. Well, that's somewhat true, but there are two ways to adapt while avoiding the problem of having 5 slightly different and incompatible ways to do the same thing: 1. Pick a good set of language features up front and stick to them, devoting further development efforts to a strong standard library rather than language features. Example: Erlang. 2. Break reverse compatibility and remove things. Example: Python.
- Jach 6y agoErik Naggum: "… if you think in terms of the imminent end of the world, _everything_ is soon food for the great garbage collector in the sky and whoever is not scrambling in panic looks like they aren't moving and have been passed by or are dying. … like, if you aren't using today's fad language in the very latest version of the IDE, you'll be left behind. aaaugh! but it's good that some people run like they are scared out of their wits. if they suddenly disappear over the edge of a cliff, a good number of people will notice in time and _not_ follow them." Of course, this was part of an email thread around Common Lisp's popularity in 1999 (https://www.xach.com/naggum/articles/3141310154691952@naggum.no.html https://www.xach.com/naggum/articles/3141310154691952@naggum...) but I think it's more broadly applicable and still relevant two decades later. Anyway, if you really want a "static" language target, perhaps push hard for official standardization (ANSI, ISO...). Standards encourage a lot of nice things, which admittedly are possible without standards, but less incentivized... For example, I can still write ANSI C as the gods intended, compile other ANSI C written decades ago, using a plethora of compilers across time (including the current year with the latest optimizations) so long as they claim to implement that standard and so long as the code is actually ANSI compliant. Such compilers might implement later standards too, or custom extensions -- but that's ok because it tends to be that I can easily make use of such code and such code can easily make use of mine à la carte! No jihad must be waged on all old code to update it under threat of being relegated to time-capsuled VMs. But regardless, things will change, even if you have an island of stability from your standard. This isn't necessarily bad, because in order for there to be any improvement, there must be change. "Not every change is an improvement, but every improvement is necessarily a change."
- pjmlp 6y agoWith the little detail that ANSI C written decades ago most likely contain UB that a modern C compiler will gladly take advantage of, with all the nice consequences that it entails.
- tomjen3 6y agoThen hopefully the language will be forked and we can have go++, with generics, the ability to build cross platform gui apps and much more rejoicing.
- dunefox 6y ago> I wish they would just freeze the language and not add anything > I think we should start putting weight on stable unchanging software You would probably like CL then.