9 ms·
Three Minor Features in Go 1.18
- smaddox 5y agoIf the build time is being included in the binary by default, I guess that means builds are not reproducible by default? Is there any easy way to exclude or strip the build time to get a reproducible binary?
- cpuguy83 5y agoThey are already not reproducible. But build time is not included, it's the commit time of the commit the build comes from, from what I gather.
- neild 5y agoGo builds are, in general, reproducible by default. Build stamps do not change this.
- cpuguy83 5y ago"reproducible by default" if the system is setup a certain way. Build time injected into builds would absolutely break any reproducibility.
- neild 5y agoIt would, which is why the Go compiler and linker do not put the build time in binaries.
- cpuguy83 5y agoBut you literally said "build stamps do not change this", and it absolutely does. Of course as I mentioned it does not look like go is adding a build time to the binary.
- thiht 5y ago> "reproducible by default" if the system is setup a certain way What do you mean? Under what circumstances is a Go build not reproducible? From what I’ve observed, if you build your binary with a set of input, the same binary is produced. Is it sometimes not true?
- cpuguy83 5y agoBy default you need the same GOPATH and GOROOT. Compiler version must be identical (not a huge stretch). cgo reproducibility is not a guarantee.
- Laremere 5y agoThe investigation to justify the introduction of the Cut function was an interesting read. Really solid numbers on those data to show that the function, while redundant with other functionality provided, is an extremely common operation and worth special casing.
- ferdowsi 5y agoI enjoyed reading that too. It's great to see the amount of thought that the language maintainers put into design, especially for things like syntactic sugar (which can get overwhelming in other languages).
- yagizdegirmenci 5y agoGo 1.18 also includes the new net/netip package which is huge, now the Addr type holds less memory, it is comparable and immutable. There is also a great post(See: https://tailscale.com/blog/netaddr-new-ip-type-for-go/ https://tailscale.com/blog/netaddr-new-ip-type-for-go/) in Tailscale's blog which deep dives into why we needed a new IP type/library in Go.
- onphonenow 5y agoI'm far more excited by Addr / netip then generics :)
- lifty 5y agoIs this Tailscale’s library imported into Go’s stdlib?
- pphysch 5y agoYep
- benhoyt 5y agoYes, after some discussion and minor modifications (and removal of a few features): https://github.com/golang/go/discussions/47323 https://github.com/golang/go/discussions/47323 ... I understand the motivation for this new package, but it does seem like a large API surface to have imported into the stdlib.
- na85 5y agoIsn't that one of Go's main value propositions? A batteries-and-kitchen-sink-included stdlib?
- philosopher1234 5y agoKitchen sink seems too far. Batteries is part of it.
- pstuart 5y ago
- klodolph 5y agoI’ve been copy-pasting or re-writing a function much like strings.Cut, probably dozens of times, in different Go packages. It’s nice to see this function make it into the standard library!
- deleted 5y ago[deleted]
- hiptobecubic 5y agoCopy-pasting and rewriting is the Go Way.
- klodolph 5y agoHey, I'll take it, over the NPM left-pad way of doing things.
- pjmlp 5y agoYou could have written a package, but I guess copy-paste is more in line with Go's culture.
- klodolph 5y agoUsing a package is the NPM left-pad way of doing things. This function is like two lines long.
- pjmlp 5y agoSo? Keep it for yourself on an utilities package. I said nothing of using one package per function.
- klodolph 5y agoI used to do that. I had a "goutils" package or something like that. From use, I concluded that the utilities package contained only two things: functionality that was substantial enough to clean up and publish as its own package on GitHub, and minor functionality that was better off being copy/pasted between projects. So I abandoned my utility package and published a few minor packages on GitHub.
- howdydoo 5y agostrings.Cut is otherwise known in Rust as str::split_once. It's something I've always missed when writing Go. Nice to see it added to the stdlib
- tialaramex 5y agoYes, I use this much more often than the more powerful general split feature, it feels very "right-sized". split_once() and similar split features in Rust are interesting because Rust doesn't have overloading, yet you can split on a string, or a character. This relies on a Trait, Pattern, that is Nightly, so you can't Implement it yourself in stable Rust today, but eventually this factors out the commonality which is cleverer than overloading (because it applies everywhere automatically)
- IshKebab 5y agoYou can implement it yourself. You just have to use your own trait.
- tialaramex 5y agoI stared at this a few times and I don't get it. The point is you can't implement Pattern, because it's a nightly feature. If you just make your own, that isn't Pattern and provides none of the benefits. Yes, you can implement your own trait, and provide blanket implementations for it, but unlike Pattern yours is not part of the standard. The nice thing about Pattern is that if Rust added say split_exactly_six_times() to the standard library that would take separator: Pattern too and so things which implement Pattern qualify, I can't see a way to get that benefit for my own traits.
- awinter-py 5y agoagree -- ultra useful alternative to splitting would be neat to imagine a language where this was an optimizer feature rather than a decision the programmer made. many functions that return an array are ultimately using just one, or a few elements of it. the compiler can make a lot of decisions in the caller about how to reduce allocation or short-circuit array processing. I think, but am not sure, this is what the experimental parsing language 'wuffs' is about https://github.com/google/wuffs https://github.com/google/wuffs -- the language itself is aware of array lengths as a first-class citizen and can make decisions accordingly
- jaytaylor 5y agoI subscribed to GH activity for the Author's friendliness-enhancing utility library. It's for parsing build information from the debug pkg: https://github.com/carlmjohnson/versioninfo/ https://github.com/carlmjohnson/versioninfo/ The primary motivation curiousity to learn if this becomes "the [best/default] way" folks reach for when leveraging BuildInfo to implement binary versioning in Golang. It could be a nice benefit to the entire go ecosystem if there becomes a widely-used, de-facto, and consistent automatic versioning scheme (for the common cases, e.g. minor point release lineage).
- Scarbutt 5y agoFor those that have switched to Go from nodejs to serve json for a web app, how did it go? (excluding the possibility of needing something like react ssr which can be a big one for many apps).
- randomdata 5y ago> excluding the possibility of needing something like react ssr No need to exclude that possibility. I once worked on a Go app that rendered React (in Typescript) server-side. The Javascript could call Go API functions directly when rendering server-side and those calls would turn into gRPC-web calls after it was loaded in the client. It worked really well.
- kinjba11 5y ago> would turn into gRPC-web calls after it was loaded in the client Isn't the point of SSR to avoid needing to have the client make additional requests for the first render? If I return something like <div dangerouslySetInnerHTML={fetchWithGrpc(myGoFunc)} /> that's not SSR. Perhaps I'm missing something.
- randomdata 5y ago> Isn't the point of SSR to avoid needing to have the client make additional requests for the first render? Yes, hence why it was able to call the Go functions directly during SSR, the results of which were bundled with the payload delivered to the client. gRPC played no role during initial render. If the React app needed more information/updates as the user used the app then the function calls would transparently happen over gRPC instead. Consider: const MyReactComponent = () => { const [things, setThings] = useState() useEffect(() => { // In-memory call to Go GetThings function during SSR render; gRPC call // to Go GetThings function when running in the client. GetThings().then(setThings) }, []) return <div>{things}</div> } Architecturally, not a whole lot different to how you might build a SSR React app on Node. The backend was just written in Go instead and that backend had a built-in Javascript runtime to execute the frontend code for SSR purposes.
- AtNightWeCode 5y ago1. Antipattern. 2. Did it inside, I hope. 3. strings.Cut, where is the doc for this? How can this not be Googled? Anyway, easily solved in many ways.
- philosopher1234 5y agoWhy is it an anti pattern?
- LukeShu 5y ago> strings.Cut, where is the doc for this? How can this not be Googled? https://pkg.go.dev/strings@master#Cut https://pkg.go.dev/strings@master#Cut
- adamrt 5y agoIs this just drive by negativity? 1. Care to elaborate? 2. What does this even mean? 3. It’s in the pending release notes with all the other new features and further information in the post you’re commenting on. https://tip.golang.org/doc/go1.18 https://tip.golang.org/doc/go1.18 Try to be more constructive if you want a conversation please.
- AtNightWeCode 5y ago
- onei 5y agoFor your criticism regarding reproducible builds, I'm not sure it's entirely correct. The impression I got from a skim was that version control metadata was being embedded, such as the git commit hash or maybe a tag. Both of which are static within the constraints that builds are generally reproducible across. However, if it includes timestamps or some generated metadata, then I wholeheartedly agree with your concerns.
- aniforprez 5y agoI think the guarantee of downvotes is for your absolutely awful attitude
- dimgl 5y agoI like Go, but I'm finding array operations leave a lot to be desired. It feels weird to use global functions (like append) to perform operations on array, and I miss having easy map, reduce and filter functions that are accessible from within the array itself. I guess things are getting better, but idk.
- lsferreira42 5y agoThis is really annoying, every time i code in go i miss python's list.append method
- mariusor 5y agoThat is weird because append is one of the five associated helper functions on slices that's actually in the Go specification. https://go.dev/ref/spec#Appending_and_copying_slices https://go.dev/ref/spec#Appending_and_copying_slices
- lsferreira42 5y agoYes, it's a helper function, not a list method like it is in python. The result is the same, its just weird
- mariusor 5y agoOh, I understand what you mean now. I thought you meant the functionality, not the idiom of calling it as a method. I dare say that it didn't occur to me that this difference would be great enough for someone to complain about it on the internet. :P
- IshKebab 5y agoPython also puts what should be methods as global functions, e.g. len, filter, reduce.
- hsn915 5y agoWhenever I read "modern" javascript code, I'm irritated by the prolifiration of map/filter/reduce. It makes code harder to read and modify. A straight for loop is infinitely better in every way.