What I'd like to see in Go 2.0 • Hacker News Board

Re: What I'd like to see in Go 2.0

#221

Post by jerf » Sat, Feb 05, 2022, 1:37 PM UTC

015a wrote: post #141

jerf wrote: post #57

Earlier quoted context omitted.

You don't need official Go support for JSON5. Same for templating. The templating library in the standard library isn't anything special, it's just in the standard library. If you don't like it, go get one of the dozens of others on offer. I think there's a number of language communities you can "grow up" in that teach you that things in the standard library are faster than anything else and have had more attention p…

I disagree with this stance. To me, the community take on "stdlib vs libraries" is a cyclical thing; we're coming out of a cycle led by JavaScript/NPM, where everything is a library due in no small part to how HORRIBLE JS/NodeJS's standard library is. Go back further, and you run into the Python/Java world which had far more comprehensive stdlibs, and today Go's (and to a lesser degree, Rust's) rising popularity is b…

My point isn't really an argument about what does and does not need to be in the standard library, as much fun as that may be to argue about. My point is really in that first sentence: "You don't need official Go support for JSON5."

Whether the Go team agrees with you or not about any particular library, you do not need to wait around. The standard library does not get any particular special access, with the exception of a couple of very special packages (unsafe, reflect). Things outside of the standard library can have all the properties you're talking about being good, and they're available now, without needing to get an entire language team to sign off on it.

Re: What I'd like to see in Go 2.0

#222

Post by crnkofe » Sat, Feb 05, 2022, 3:02 PM UTC

Oddly enough the list doesn't resonate much with me.

I'd love to see better mocking support. Doing mock.On("fun name", ...) is so backwards, confusing and brittle. It's also a great source of confusion for teammates when tests fail.

I miss better transaction management. I regularly juggle db, transactions and related interfaces and it's a continuous pain.

Then there's the "workaround" for enforcing interface implementation: _ InterfaceType = &struct . This could be easily part of struct def. rather than having it in var section.

As was mentioned by others doing x := 5 only to later do JsonField: &x is just a waste of intellectual firepower. Maybe this can be alleviated by generics but the lang should be able to make this a one liner.

Re: What I'd like to see in Go 2.0

#223

Post by Strom » Sat, Feb 05, 2022, 5:23 PM UTC

hpx7 wrote: post #150

> Go's templating packages should support compile time type checking. Does anyone know of a decent type safe templating package out there (for any language)?

React with TypeScript. Very popular and unlike Go's templates has proper type checking.