[HN Gopher] Go: Don't Change the Libraries in 1.18
___________________________________________________________________
Go: Don't Change the Libraries in 1.18
Author : dbattaglia
Score : 167 points
Date : 2021-10-17 10:41 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| crnkofe wrote:
| I was really looking forward to getting some basic generic
| standard library funcs. Guess what I'm getting now is a a ton of
| std libraries each with a slightly different approach, slightly
| different bugs and update cycles which will nicely inflate the
| amount of tech debt in existing codebases.
|
| I guess from the standpoint of a language designer it makes life
| a bit easier not to do anything and just cherry pick the winners
| of the various generic attempts that the community will create
| but as an app. developer I find this disturbing. Also I question
| the rush to a release all of a sudden. Generics took years to
| come to fruition. Another year for a decent stdlib won't really
| hurt anyone and for those that really really want it they can
| enable it through build constraints.
| cube2222 wrote:
| Also think this is a good call.
|
| Though the second comment has merit too, I think it would be good
| to have some common abstraction right away, like we had
| io.Writer, io.Reader, etc. so everybody doesn't define their own,
| as it'll take time to crawl out of that.
|
| Although in practice it did work out well with error wrapping
| which was first in libraries and then the stdlib defined an
| interface for them, which resulted in all libraries adopting
| that.
|
| > Similarly, if constraints isn't part of 1.18, there will be a
| lot of independent redefinitions of orderable types. I don't
| think we're going to learn from experience much that could change
| that package now.
| kubb wrote:
| What will likely happen is that the users will design generic
| libraries themselves. There will likely be a couple, and
| eventually they will converge on the most useful features. Then
| the Go team can just get inspiration from that I guess.
|
| I'm excited about the prospect of having iterators. It will
| enable a different, more consistent programming style.
|
| I'm also hoping for immutable collections, even though the lack
| of specialization will make it more difficult to implement them
| efficiently. They would enable a more robust way to build
| concurrent systems.
| IceWreck wrote:
| > What will likely happen is that the users will design generic
| libraries themselves
|
| the Go team has already made the libraries, theyre just
| publishing them in the /x/ namespace instead of the stdlib.
|
| /x/ has everything that's not under the Go compatibility
| promise, among other things from the Go project.
| cy_hauser wrote:
| Or, if history is a guide, there will be a few really nice
| generic libraries written and a sizable minority of developers
| will adopt them as pseudo standard to fill the void. Then the
| Go team will do what they want, fracture the community, and
| alienate those who expected your described path to be the one
| taken.
| chrsig wrote:
| I think they've been worse about this w.r.t. tooling (dep
| comes to mind. The closest thing I can think of along this
| path for the standard library would be how they've handled
| errors, and deciding to go their own way instead of adopting
| dave cheney's pkg/errors[0]
|
| they do definitely seem to have some NIH syndrome at times,
| but I can't say that as time has progressed that I haven't
| come to appreciate the decisions they've made that seemed
| controversial at the time.
|
| [0] https://github.com/pkg/errors
| SPascareli13 wrote:
| Wait, isn't Wrap and other pkg/errors proposals used in the
| current stdlib? I thought they officially accepted that
| package as the default errors package.
| chrsig wrote:
| No, they didn't adopt pkg/errors into the stdlib.
| pkg/errors did get updated to work nicely with the
| changes that they did incorporate
|
| https://pkg.go.dev/errors
| SPascareli13 wrote:
| Interesting, is there any discussion available to
| understand their decision?
| chrsig wrote:
| > What will likely happen is that the users will design generic
| libraries themselves. There will likely be a couple, and
| eventually they will converge on the most useful features. Then
| the Go team can just get inspiration from that I guess.
|
| Most likely yes, or as stated in the ticket, they'll take the
| existing proposal and implement it in golang.org/x/, where
| they've had some success fleshing out the design of new
| packages before incorporating into the standard library. It's
| worked out well, as early adopters can adopt and generally have
| a painless transition once included in the standard library.
|
| I agree with iterators and immutable collections -- it's been
| painful working with trees in go, so hopefully that gets a bit
| easier now.
|
| Honestly, I'm excited to see what will come of generic
| functions for channels. Being able to write a generic Dup(in
| chan T, out ...chan T), or a CtxRecv(context.Context, chan T)
| (T, error) to cut down on some boilerplate select statement.
| kubb wrote:
| +1 for channels, a simple task like duplicating a channel is
| surprisingly tricky, verbose and error prone
| dathinab wrote:
| Hm, shouldn't they first update the (most important/interesting)
| libraries in a fork before stabilizing generics?
|
| I mean designing a feature in a clean room is one think, but
| using it a the standard library would be a good way to know if
| they messed up the design in some way.
| spockz wrote:
| Yes that would be a good idea. However, they could already have
| a generic collection lib in the same place (branch/repo) where
| the generics feature is created.
| lbhdc wrote:
| This is what Rob proposes in this issue.
|
| > I propose we still design, build, test, and use new
| libraries for slices, maps, channels, and so on, but start by
| putting them in the golang/x/exp repository.
| 1_player wrote:
| tl;dr: We're shipping generics in 1.18, it's a huge release so
| let's wait a little bit until they stabilise and they're used in
| production before changing our stdlib.
|
| Good call in my book, and I'm extremely excited to have generics
| finally. I thought they were going to ship with 2.0, but the
| sooner the better!
|
| It's cool to hate on Go, it's taken over the system programming
| space for a reason, like it or not, and after working full time
| on Elixir it's hard not to think in map/reduce and other generic
| constructs, which were unreasonably verbose before in Go. Now the
| haters will have to focus on the "if err != nil" statement to
| pile on the language -- though to be fair I'll expect some
| ergonomic improvement on that aspect as well, eventually.
|
| With generics, Go will be my new Python, but with a decent
| dependency and deployment story, and I'll just need Zig for my
| low-level manual memory management needs. What's Rust?
|
| EDIT: indeed being a bit cheeky with HN's favourite language
| isn't well received in this place.
| pjmlp wrote:
| Go has taken over kuberbetes related stuff, that is all.
|
| Although I like it being used for systems programming stuff
| like TinyGo on embedded or F-Secure TamaGo unikernel, that is
| hardly taking over the domain where C and C++ still rule, and
| will keep to do so for decades to come, despite the increasing
| usage of Rust on the domain.
| paedubucher wrote:
| Brad Fitzpatrick stated in one of his talks, that a version of
| Go coming with generics will be called 2.0 eventually. Maybe
| they do the version jump if there are backward-incompatible
| changes done to the library in 1.19.
| leaveyou wrote:
| When was that ?
|
| IIRC that was the general feeling then but the impression has
| changed in the mean time ?
| cageface wrote:
| Lack of null safety is still a major shortcoming in my book
| compared to Rust/Swift/Typescript.
| everybodyknows wrote:
| null safety: Can you provide us a reference to a working
| definition of the term?
| cageface wrote:
| For example in Typescript, you can specify whether a
| parameter is allowed to be null in the signature of a
| function. If you do the compiler will make sure that you
| don't accidentally pass a null value to that function.
| function foo(x: number) { return x + 1; }
| let y = null; foo(y); // compiler will flag this
| drvd wrote:
| In Go func foo(x int) { return x + 1 }
| var y *int = nil foo(y) // compiler will flag thi
| cy_hauser wrote:
| That wasn't the greatest example as Go doesn't really
| have any way to represent it. If it did it might be
| something like this. type MyStruct struct
| { Name string } var-not-nil
| myStruct = &MyStruct{"Hello"} // this is a "not-nil"
| pointer variable myStruct = nil // compiler
| would catch this
|
| The idea being to allow variables to hold and pass
| pointers to structs like now but ensure they are never
| nil.
| Gwypaas wrote:
| Now add an error to foo and have x=0 as a valid return
| value, or even worse, having to deal differently with
| different errors.
| Macha wrote:
| null/nil can only occur in scoped use cases (Option<Foo>,
| Foo | null, Foo?) and so the compiler can warn you when
| something could be missing and you don't handle it without
| being incredibly noisy.
| EdwardDiego wrote:
| At least now we can write a generic set that supports all the
| things you want a set to do, instead of using map[T]interface{}
| and a lot of for loops.
| everybodyknows wrote:
| >map[T]interface{}
|
| If the semantics desired are merely those of a simple set,
| why instantiate storage for the value side of the map? An
| interface{} consumes 16 bytes. Instantiating a struct{}, i.e.
| with no fields inside, consumes 0 bytes.
| Shish2k wrote:
| Because when a language doesn't supply common features out
| of the box, users implement them for themselves, and
| inevitably a lot of them do a bad job of it :)
| the_duke wrote:
| > it's taken over the system programming space for a reason
|
| I'm curious what you define as systems programming, because Go
| certainly isn't a systems programming language by the classic
| definition.
|
| Go has a complicated runtime and GC. It's really not in the
| same category as C/C++/Rust, but more like Java/C# , just
| without a JIT.
|
| The only domain where Go is a go-to language is the Kubernetes
| ecosystem. It's also decently popular for networking heavy
| applications / microservices / server applications, because the
| runtime is well suited for those domains.
| Zababa wrote:
| Go is basically a systems programming language if you
| consider """the cloud""" a system, a big part of the
| ecosystem is built on it. It is basically between C/C++/Rust
| and Java/C#, which is "good enough".
| throw_m239339 wrote:
| > It's cool to hate on Go,
|
| criticism =/= hate
|
| Nobody "hates" on Go for the sake of it. If some people were
| not critical of that language, generics would have never been
| added at first place. I'm glad the Go team acknowledged the
| flaw instead of the gaslighting that has been going on for
| years in the go community from a few go users.
| 1_player wrote:
| Calling it "gaslighting" is exactly what a hater would do.
| It's not very constructive.
|
| Generics were a pain point, but people have been crapping on
| Go on this forum while people out there are using it to build
| stuff. It's not a perfect language, but if you read any HN
| thread about it it's like it's impossible for people to go
| past the lack of generics or the existence of nil.
| pjmlp wrote:
| I started coding in 1986, naturally I used plenty of
| languages without generics to build stuff, that doesn't
| mean it still makes sense in the 21st century to design
| strongly typed programming languages without generics.
| sanderjd wrote:
| It is a good use of the word "gaslighting", which I think
| can be defined as "an effort to convince someone that they
| do not know a thing that they do know". In this case, a lot
| of people know from lots of experience that writing type
| safe generic code is extremely useful, but the go community
| spent a long time arguing that people could not have had
| that experience because writing generic code isn't actually
| useful. This isn't really my impression of what the go
| _team_ was saying, which I interpreted as more like
| "parametric polymorphism is useful but we aren't sure it is
| a good fit with the simple language design we are seeking
| to maintain". That's totally reasonable, everything is
| trade offs, but that's not the prevailing pushback you
| would get from the go community, you'd instead hear a
| message more like "if you'd rather write generic code
| instead of copy pasting constantly, you're a bad programmer
| who doesn't get it", which is not helpful and yes, I think
| gaslighting is a reasonable description.
|
| The existence of nil is also a design flaw. But you're
| right that no language is perfect and neither of these
| flaws keeps people from building tons of useful stuff with
| the language.
|
| I think there is definitely gaslighting in the other
| direction too, which is what you're highlighting: lots of
| people know from experience that go is a super useful
| language, but then people come of as saying "your
| experience does not exist, it is not a useful language
| because of these big design flaws".
| skybrian wrote:
| Correct me if I'm wrong, but it sounds like you're not
| really claiming people say "your experience does not
| exist" or "you're a bad programmer who doesn't get it."
| It sounds like this is a bit of exaggeration for effect?
|
| I suspect you're talking about something I've seen, which
| is people will say that your experience in other
| languages isn't directly applicable to writing code in Go
| because it's a different language and ecosystem.
|
| This seems like something newcomers need to hear
| sometimes, and it's also somewhat irritating if in your
| case it doesn't seem like that kind of issue. When
| generic advice for beginners gets misdirected then it can
| seem insulting, but I usually just try to remember that
| they don't know me and beginner mistakes are worth
| checking for. I can choose not to be insulted.
|
| Getting people to actually hear what you're saying when
| they're pattern-matching on common questions can be
| difficult. I think we should still assume good faith,
| though, and "gaslighting" implies malice.
| sanderjd wrote:
| Those are summaries of responses I've gotten when
| discussing this a long time ago (before the language team
| decided to figure out how to incorporate generics). I'm
| not sure the exact actual wording, but that's very much
| how it came off to me, that there's no way to be both
| smart and experienced and simultaneously convinced that
| generics are an extremely useful language feature. These
| debates don't get so heated now, because even the go
| designers themselves conceded the point long ago.
|
| Your more nuanced version of the argument is also wrong
| though. Experience from other languages is always
| applicable. Even for beginners, it is obvious and correct
| to ask "wouldn't we save a lot of repetition if we could
| write a generic version of this function instead of
| tediously rewriting the same thing for a bunch of
| types?". The correct and very reasonable response is
| "yes, but the designers of this language chose not to
| support that functionality in an effort to maintain
| simplicity". The right answer is not "no, this language
| is unique such that that technique is not applicable to
| it". That's gaslighting, and much worse when directed
| toward beginners who will just conclude that they must be
| wrong, when they aren't.
|
| I agree with your last paragraph in general, but in this
| case that's not what was going on. Saying that the
| language would not actually benefit from polymorphism was
| not true, it was just a rationalization for leaving out a
| useful feature. It's the difference between "yeah that
| would be useful but we don't think the complexity it
| brings is worth it" vs. "that is not useful in this
| language for reasons you aren't wise enough to
| understand".
| djur wrote:
| Some people crapping on Go in this forum are also people
| who have been using it to build stuff, though. It's
| inaccurate to assume these are distinct groups.
| qaq wrote:
| Yes let's fracture the ecosystem with a bunch of libs doing
| generic map, slice etc. Cause there is no way to figure out how
| to do it right as this is a very novel feature that no other lang
| has
| chrsig wrote:
| the proposal isn't to not implement them at all, it's to not
| immediately incorporate them in a way that they're permanently
| frozen.
|
| they'll implement them in some versioned package that everyone
| can adopt and play with, and then incorporate them.
|
| fracturing could happen. but that could happen if they
| immediately included it in the standard library with warts,
| too. I can easily imagine people creating multiple packages to
| overcome shortcomings of a half baked stdlib package.
|
| ..so I don't want go to follow some fearful path because of
| some unquantifiable risk that may or may not come to pass, and
| could come to pass regardless of which path they take.
| Strom wrote:
| Go is not in the business of copy-pasting other language
| designs. That much should be obvious by now.
|
| The questions aren't around the algorithms. They're about Go
| specific things like how to deal with legacy std library parts
| that are made obsolete by generics.
| pjmlp wrote:
| Exactly, they make users of Go copy-paste their own code
| instead.
| qaq wrote:
| Yes NIH at Google is on the level of it's own. Look at any
| ecosystem that used this logic to push something off and you
| will see a badly fractured community that never fully
| reconsolidates. I'd rather depend on std lib with warts than
| have my deps depend on 3 incompatible versions of generic map
| from 3 dif. libs.
| marcus_holmes wrote:
| Simple solution: don't use a dep that uses generics until
| the fracturing is gone. Take the same approach as the Go
| team and let the use of generics mature and a consensus
| build on where/how they should be used.
|
| There's no _need_ for generics in the short term. We 've
| survived for 11 years without them, we can manage another
| couple while we work out how to best use them.
| qaq wrote:
| So you will drop any existing dep your project has that
| adopts generics ?
| yalue wrote:
| Fortunately, they fixed dependency management first, so
| you can simply stop updating any dependency that adopts
| generics!
| qaq wrote:
| Cool and what happens with security updates?
| sangnoir wrote:
| Libraries that don't do point-release security updates
| for major versions should not be trusted, or used in
| production.
|
| Libraries that do release security updates, but introduce
| new language features like generics in those point-
| releases also shouldn't be trusted, and have no place in
| production. Why should I upgrade my language version to
| get a security fix?
| marcus_holmes wrote:
| Yes. Because if the code works now then it doesn't need
| generics, so the only reason for adding generics
| immediately is because the author wants to play with the
| new toy. And I don't need that kind of attitude in code I
| rely on.
| jamesrr39 wrote:
| To be fair, Go has quite successfully (IMO) not implemented
| features, waited for the community to come up with several
| different implementations, and then implemented that feature in
| a way that they like, without fracturing the ecosystem.
| Examples that come to mind are `//go:embed` and dependency
| management via `go mod`.
| chrsig wrote:
| eh, go mod isn't the great example...the community was pretty
| fractured before that. I'd personally adopted dep right
| before they announced the intention to build modules...so
| that was kind of frustrating.
|
| in the long run i think it'll consolidate the community, but
| there's definitely a long tail to that timeline.
| pdmccormick wrote:
| But were Go modules a better solution in that space? Should
| we have stuck with a less better approach (not casting a
| judgement on dep necessarily) just because it was an
| earlier attempt to deal with the same problem?
| chrsig wrote:
| so far in my experience it's a bit meh on both fronts.
| modules got rid of GOPATH, which is kind of nice. i
| personally never cared much about the whole SAT vs
| ...whatever algorithm rsc implemented (I forget the
| details at this point, which may be an indicator of how
| important it is the the user base...or I'm just ignorant
| of the benefit's I'm getting/missing)
|
| having it be incorporated into the project is ultimately
| the real win, because it gives a target to consolidate
| round.
| nyanpasu64 wrote:
| C++17 introduced std::optional and std::variant, but they're not
| used by the standard library in 2021, as far as I've seen (unlike
| Rust which is better off for using them). It feels quite like a
| missed opportunity to produce more ergonomic APIs (though the
| inability to produce an optional<T&> is limiting, and
| std::variant is inefficient at compile and possibly runtime and
| apparently can't be fixed because ABI). I'm not a Go user, but I
| dislike multiple competing approaches to problems without clear
| guidance or fully embracing newer approaches.
| nine_k wrote:
| A good call, and probably the most reasonable decision in their
| situation.
|
| OTOH this removes much of the point to use generics, and makes
| working with stdlib from type-parametric code more painful.
|
| Still great to see things improving. It took mere 11 years.
| verdverm wrote:
| There is a path to upgrading library functions to generics, it
| will come in a later release. Looked like default generic type
| of the empty interface for those functions. See the other
| issues linked from the original.
| tonetheman wrote:
| It took that long because you do not NEED generics.
| colejohnson66 wrote:
| Well, no language ever _needs_ features. We could all write
| software in C or even assembly, but we don't because
| abstractions are nice. Generics are an abstraction.
|
| Take C# for example. The `System.Collections.Generic`
| namespace is full of generic collections (surprise!) that
| allow more type safe code. If I have a `List`, I can't
| guarantee there isn't something I don't want in there (that
| could cause a runtime exception I don't catch). But if I have
| a `List<IFeature>`, I _know_ that everything in the list
| implements `IFeature` (barring compiler bugs and unsafe
| code).
| closeparen wrote:
| To be fair, Go has typed maps and slices. You just can't
| implement your own generic collections, or generic
| operations over collections. Those two will get you
| decently far.
| BoorishBears wrote:
| I don't know how people were looking at these Java
| 2.0-esque kludges and still arguing generics were
| superfluous but I'm glad it's landed:
| https://github.com/elliotchance/pie
| vips7L wrote:
| But that's all go has. It doesn't have typed Sets, typed
| ordered maps, etc.
| grey-area wrote:
| Abstractions are not always nice.
|
| One of the nice things about go is it doesn't have many
| abstractions and most of them are carefully thought out. I
| don't want to have to inhabit somebody else's abstractions
| all day at work, I want the language to get out of the way,
| which go does quite well IMO.
| phillipcarter wrote:
| Go, like every language, has plenty of footguns and head-
| scratching behaviors as well. Don't confuse your
| familiarity and personal preferences for universal
| properties of the language.
| dnautics wrote:
| "and most of them are carefully thought out."
|
| Is this stockholm syndrome or something? For example,
| JSON.
|
| Also, the time abstraction is completely bonkers.
|
| If you want to multiply a 500 milliseconds with a user-
| given value (suppose I want some number of half-seconds),
| you must first cast the user value to milliseconds, then
| multiply, so you are multiplying 500 milliseconds times
| (say, 4 milliseconds) to obtain 2000 milliseconds.
|
| And don't get me started on goroutines/channels. You are
| supposed to "share state by communicating" and not
| "communicate by sharing state". That's great. But at some
| level, you must bootstrap knowledge about the state of
| the channel, which is fundamentally shared state by the
| low-level nature of the channel. When you've worked in
| systems which have really thought out carefully what it
| means to have a no-shared-state system, the go system
| looks like it's been put together by either amateurs or
| fools.
| grey-area wrote:
| There's certainly lots to criticise in Go, as in any
| language, that's why I said 'most', though I'd say it was
| peak HN hubris to say it was put together by 'amateurs or
| fools'.
|
| JSON is not related to go but perhaps you have some
| problem with the JSON parser? Works fine me... Personally
| I don't find the time constants a problem at all, I'm not
| keen on the time parsing layout, but that's relatively
| minor. Channels I don't have strong opinions about and
| goroutines if used sparingly I've found a nice balance of
| utility and simplicity for creating threads, but I
| recognise I'm not really qualified to argue about them.
| dnautics wrote:
| It's not hubris, if you've seen something else to compare
| it to. I'm not claiming to have made something better,
| I'm claiming to have used more well thought out systems.
| I know Rob pike isn't an "amateur" in the strictest sense
| (he might be, at "designing a pl"). I'm not convinced he
| isn't a fool.
| closeparen wrote:
| When I don't like how something was done in a Go
| codebase, I'm generally SOL, since it was repeated so
| many times that there aren't enough hours in the day to
| change them all.
|
| When extremely motivated, I'll script manipulation of the
| AST, but that's a pretty extreme thing to have to do.
| candiodari wrote:
| Abstractions add a great deal of "default", potentially
| very complex, behaviour. This is great when starting a
| greenfield application. Even in extreme cases like RoR
| they work and quickly get a whole lot of things running.
| Fantastic. My newfangled thingamabob does something!
|
| And then the application grew and you have the guys who
| have to watch and keep the application online when it's
| business critical. They _HATE_ abstractions. Because 7
| abstractions that are used throughout the application
| means there 's 127 cases the developer hasn't thought
| through, at least ten of them a ticking time bomb. That's
| 128 possible cases, one of which the developer has
| actually thought about, 5 they have verified to be
| reasonable.
|
| An easy case to show what's happening is the suggestion
| every new developer makes. "I'll just have a thread per
| connection, that's easy". And yes, it's very easy to get
| it running. It doesn't block during dev, it handles
| multiple connections and generally does the job. And it's
| absolutely guaranteed to crash you server for 10
| different reasons in production. And yet, every new
| developer will (and should) do it.
|
| There's just 2 camps developers in the world, who don't
| agree and this won't seriously change. Learn how the
| "other camp" thinks and you'll do better.
| dnautics wrote:
| I think you're confusing abstraction for framework.
| throw_m239339 wrote:
| > Still great to see things improving. It took mere 11 years.
|
| Took that much time because of little clique of people outside
| the go team had way too much influence in the Go community. Let
| see if they dump the language like they threatened to, as the
| result of adding generics. Of course they won't.
|
| Generics are there if one wants to, and they aren't like Java,
| but ADA. ADA got a lot of things right decades ago including
| the way tasks work from which Go routines should have taken a
| bit more inspiration .
|
| Congrats to the Go time anyhow.
| kubb wrote:
| Rob was opposing generics from the start. People were
| pointing out the need more than a decade ago, but he was
| firmly saying no. Now he left the team.
| 1_player wrote:
| He's left the team? He seems pretty active even in this
| recent github thread.
| [deleted]
| stevekemp wrote:
| I suspect a lot of people outside the go-team made comments,
| suggestions, and proposals. But honestly, thinking back damn
| few of them resulted in changes to the language.
|
| If you'll recall back in the day there were several different
| vendoring approaches, but ultimately the go-team proposed and
| implemented their preferred solution.
|
| Similarly there have been a million generics & error-handling
| suggestions but none of them were introduced. It's basically
| lots of distracting discussions, and it doesn't feel so much
| like a community project that is actually seeking outside
| discussion and ideas. (No shame in that, but the pretense is
| disappointing).
|
| Personally I'm waiting for the fuzzing-support to land in
| 1.18. Fuzz testing is basically magical, and amazing in
| reporting problems even in code with "high coverage". The
| generics might be nice, but off-hand I don't see that I'll be
| needing them in the immediate future in any of my personal
| projects - but I fuzz-test the hell out of a lot of my
| projects (which largely revolve around interpreters and
| compilers).
| gnfargbl wrote:
| I actually think this is one of the reasons I like go so
| much, and now write code in it almost exclusively -- it
| _isn 't_ really a community project, but rather a labour of
| love from a small number of genuine experts.
|
| If it actually were a community project, I think we would
| have more of the "x := make(someType) vs. x := someType{}"
| TMTOWTDI that you find in other mature languages, and go
| would be weaker for it.
| frosted-flakes wrote:
| TMTOWTDI = there's more than one way to do it
| ithkuil wrote:
| Those community efforts may have not been have adopted, but
| that doesn't mean their existence hasn't informed the Go
| team's solution
| cerved wrote:
| Go doesn't/didn't have generics? Why?
| jikbd wrote:
| Because features in software don't exist until someone adds
| them.
| chrsig wrote:
| this is a really underrated comment. there's always a lot
| of entitlement when it comes to software. why doesn't x
| have y?
|
| ...because x doesn't have y _yet_....this stuff doesn 't
| build itself, and it certainly doesn't get built
| overnight.
| Redoubts wrote:
| It's pretty overrated really (even if grey). Mature
| projects and PMs treat submitted code as liabilities to
| be maintained, not free benefits. And every project is at
| the whims of its maintainer, who can absolutely reject
| any contribution they wish.
|
| To suggest generics weren't here sooner because no one
| wanted to make the pull request it is just dumb.
| chrsig wrote:
| if someone's off on some tangent implementing a major
| feature without coordinating with the project maintainers
| and it subsequently gets rejected because it doesn't fit
| the constraints that they've stated for the
| feature...that's on them.
|
| the go project is pretty upfront with how they go about
| deciding what will/wont get into the project, what
| process to follow, etc.
|
| Posing it as "why doesn't go have generics" is bound to
| be reductionist, because it's too coarse of a question,
| and any real implementation winds up having a lot of
| nuance.
|
| the question winds up just sounding entitled and petulant
| though, so if someone can't be bothered to ask a well
| informed question about why go doesn't have generics
| _yet_ , the best answer really is "because it hasn't been
| added.", tautological as it may be.
| lifthrasiir wrote:
| It was commonly stated (or claimed) that they didn't know
| how to add generics without sacrificing both compilation
| time and runtime performance [1]. To my knowledge they
| ultimately didn't choose a particular implementation
| strategy and instead chose a design that allows multiple
| strategies as needed.
|
| [1] https://research.swtch.com/generic
| wwarner wrote:
| It also seemed like the original intent was to support
| generics and metaprogramming through code generation and
| AST manipulation, the argument being that code generation
| and AST manipulation are the most general way to build
| complexity and specialization from a simple set of
| primitives. I personally don't think that generics and
| generation are mutually exclusive, but if they were, I'd
| side with retaining simplicity over the new feature.
| nine_k wrote:
| I can only repeat the top comment from the "8 years of Go"
| thread [1]: the team made a different set of priorities, and
| was hugely successful in implemneting them, which also
| brought a ton of popularity. Golang is not my cup of tea, but
| I very much see the large and underserved niche it filled.
|
| [1]: https://news.ycombinator.com/item?id=15671676
| The_rationalist wrote:
| How can people still use this toy language..
| olingern wrote:
| JavaScript/TypeScript changes so much that a codebase will look
| very different from one year to the next. JS/TS has come a long
| way and needed to make substantial change, but I appreciate the
| slow moving, methodical nature in which the Go team moves the
| language and environment forward.
| Zababa wrote:
| > JavaScript/TypeScript changes so much that a codebase will
| look very different from one year to the next.
|
| Only if you want it to change. Our codebase is plain JS/TS, we
| don't use many recent features, and it's fine.
| dreyfan wrote:
| Are we just ceding Javascript to Microsoft at this point due to
| the ubiquity of Typescript?
| frosted-flakes wrote:
| TypeScript does not output obfuscated JS. The output is
| completely human-readable, even if certain things don't match
| the source exactly. TS explicitly tries to stay in line with
| JS, syntax-wise.
| IceDane wrote:
| This is just plain nonsense and is bordering on being
| paranoid and delusional behavior similar similar to what
| you'd see from conspiracy theorists.
|
| If you ever tried looking at the compiled code, or tried
| playing with the settings, you can see that typescript is
| able to output code which is nearly your original code
| copied, just without types. It all depends on which
| compilation target you choose. If you choose es3, it will be
| full of polyfills. If you choose esnext, it will be basically
| your code.
| IshKebab wrote:
| No. Typescript is really strict about being _only_ type
| annotations for JavaScript (except `enum`), so I 'm not sure
| why you'd think that makes them control JavaScript.
| eyelidlessness wrote:
| If anything, TypeScript is quite deferential to TC-39.
| Microsoft is part of the standardization process, but
| certainly not the main/only driver. I don't know where you
| got the impression that this is a MS issue, but TS changes
| _because_ JS changes not the other way around.
| threatofrain wrote:
| It's already mainstream to minify your JS anyway as part of a
| long build process. JS transparency is used by very few
| people.
| shp0ngle wrote:
| The negative is that some issues are really hard to fix,
| because you don't want to break the backwards compatibility
| guarantee.
|
| For example, there is a bug in go's built-in HTML templating,
| that it misrepresent javascript backticks.
|
| If you do
|
| <script> var string = `http://google.com` </script>
|
| in HTML template, it will interpret // as a comment and return
|
| <script>var string = `http:</script>
|
| This is now really hard to fix; it means either rewriting the
| JS parser from scratch, but that is a giant change (currently
| the JS parser is really simple, backticks are hard to do
| properly without reimplementing all from scratch); the more
| reasonable choice would be to just ban backticks in HTML
| templates, but that would break backward compat.
|
| So there is basically an unfixable bug sitting in go html
| templates.
|
| https://github.com/golang/go/issues/9200
| diogenesjunior wrote:
| Why can't they just make a new version of the library for
| fixes?
| rytill wrote:
| If it's bad enough, why not release a v2 of the library?
| jen20 wrote:
| The standard library seems to only be versioned with the
| language. An external v2 could work, but I'm not sure
| there's any precedent for a v2 of a standard library
| package.
| theli0nheart wrote:
| > _I'm not sure there's any precedent for a v2 of a
| standard library package._
|
| urllib/urllib2 in Python is one example. There are
| others; it's not really unprecedented.
| arp242 wrote:
| There is no precedent _in Go_. It 's been discussed a few
| times here and there, but real plans AFAIK.
| badsectoracula wrote:
| Can't they add an option or something that specifies how
| backticks are handled with the default setting to be the
| current (so nothing breaks) and any new code or existing code
| that knows about the issue can set it to a better value?
| eyelidlessness wrote:
| > the more reasonable choice would be to just ban backticks
| in HTML templates, but that would break backward compat.
|
| Given script tags are allowed, this seems like the least
| reasonable choice. What other arbitrary JS features should be
| disallowed because the parser isn't spec compliant?
___________________________________________________________________
(page generated 2021-10-17 23:01 UTC)