Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.17 Release Notes

golang.org

Post reply on HN
Print view View original

151–160 of 222 posts

Re: Go 1.17 Release Notes

#151

Post by readlikeasloth »

josephg wrote: post #69
throwaway894345 wrote: post #48

Earlier quoted context omitted.

I really like Rust, but in my mind it's still relegated to the periphery of tasks that must be super fast (like C/C++, to your point) and/or low-level. Rust has made impressive strides at reducing the toil involved in compile-time memory management, but there is still a big productivity gap between the borrow checker and GC. Frankly, people are making boatloads of money off of software written in Python and JS--langu…

> In this world, most errors are silly type errors I can’t speak to python, but typescript has basically fixed this problem overnight in the javascript ecosystem. The typescript compiler finds almost all small bugs like this while I’m coding. And as an added bonus, type hints allow the IDE to be much more helpful - adding to jump to function support, autocomplete, method parameter suggestions (or documentation on hov…

> I can imagine Go shining a lot more brightly when working with a team which has mixed skill levels.

Thank you for expressing that thought. However: I came quite to the opposite conclusion. I´m currently working in a small team with members that are not so versatile in coding, coming from a JavaScript background. It has been surprisingly easy to teach them Spring Boot. You follow a typical layout and everything falls into its place. I have my reservation that the same holds true for Go. It feels like there is much more room for confusion. Do I use global functions or receivers? How do I inject my dependencies and where do manage them? How do I build constructors and do I really need them? I found surprisingly little advice on those topics.

Re: Go 1.17 Release Notes

#152

Post by ithkuil »

the8472 wrote: post #45
ithkuil wrote: post #42

Earlier quoted context omitted.

I hate to be "that guy" too, but coming from somebody who really likes Rust and is using it more and more (also at $dayjob now) we must admit that Go tooling is one step ahead. CPU profiler, allocation and heap profiler, lock contention profiler. It all comes out of the box. Yes you have cargo flamegraph for profiling locally and you now have pprof-rs to mimick Go's embedded pprof support. But allocation heap profili…

> But allocation heap profiling is still something I struggle with. Switch to a dumb allocator and then profile mmap calls or page faults? That should get you large allocations at least. It's a pretty crude proxy. The other allocation profilers I'm aware of cause significant slowdowns.

Sorry I don't understand what you're suggesting.

I currently intercept calls to malloc/calloc/realloc/... and capture stack traces. This way I know how much memory gets allocated for each allocation site. Since allocations usually go through constructor calls, the presence of a constructor in the stack trace can let you infer how many structures of a given type are been allocated. Knowing how big they are is more tricky since allocation for the whole struct and its parts doesn't have to happen entirely in the constructor (some structures like vectors and hashmaps can grow, some structures can collect data from other sources and then hold onto them, etc)

Furthermore to know how the live memory is broken down between object type and allocation sites, you also need to track freed memory. This is significantly more tricky to do efficiently. I currently take an allocation sample every N bytes being allocated and use a poisson process estimator to scale the total allocated bytes.

The only ways I know to account for in use memory is to track every single allocation or to add some extra space for every allocation where we record whether a block had been sampled and of yes, what was its corresponding allocation event.

Can you please elaborate more on your suggestion?

Re: Go 1.17 Release Notes

#153

Post by _ph_ »

benhoyt wrote: post #46
benhoyt wrote: post #29

To me, the most interesting change is the performance improvement due to the new register-based calling convention. Your CPU-bound programs will magically get 5% faster when compiled with 1.17: > Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. Benchmarks for a representative set of Go packages and programs show performance improvements of about 5%, and a ty…

Wow, this update is awesome: my GoAWK interpreter ( https://github.com/benhoyt/goawk ) runs a simple CPU-bound AWK program 38% faster when compiled with Go 1.17 (compared to 1.16). $ time goawk_go1.16 'BEGIN { for (i=0; i I wonder why it's so much better than their advertised 5% perf improvement? Here's a quick CPU profile: https://i.imgur.com/csJyOYq.png ... I don't get too much out of it at a glance, just seems lik…

The speed gained depends a lot on the structure of the code benchmarked. Natively written Go code has more computation happening in local loops without many function calls, the optimization brings less effect. An interpreter often calls a function for every single directive executed. This means, you have a lot of function calls inside loops, sometimes for every single operation executed. This of course profits massively from this optimization.

Re: Go 1.17 Release Notes

#154

Post by _ph_ »

ridiculous_fish wrote: post #58
avl999 wrote: post #26

Go is my favorite language to write code in. I was very skeptical when I first started learning it for a new job with error handling that looked archaic in comparison to exceptions but once I got the hang of it it has quickly become my preferred language of choice for any project. Once generics are finally added the language should basically be a no-brainer for any serious production code.

From a distance it looks difficult to write in. For example, two recommended ways to delete from a slice: a = append(a[:i], a[i+1:]...) // or a = a[:i+copy(a[i:], a[i+1:])] Both seem harder than necessary. Is that code just idiomatic, and Go programmers recognize it instantly? Or maybe they don't deal with slices that often? https://github.com/golang/go/wiki/SliceTricks

This is an interesting point. On the first glance, it looks like a very obvious missing piece and having to hand-write such expressions feels like unnecessary painful.

On the second glance, one can see why probably it was left out: there are two fundamental different ways to implement the deletion. You can copy the last element into the slot of the deleted element, or you can move all elements after the deleted one place to the left. The latter is what you implemented and preserves the ordering, which often is desirable. The former is way more efficient, if you don't need to preserve the order. A default implementation would probably choose to preserve the order and thus introduce a systematic inefficiency which is easy to be avoided.

Fortunately, with the introduction of generics and especially the new slice package, this discussion becomes moot.

Re: Go 1.17 Release Notes

#155

Post by ithkuil »

theshrike79 wrote: post #132
systemvoltage wrote: post #128

Earlier quoted context omitted.

Not a GO dev, has the debugging experience improved?

Dunno, 20 years in the business and I still debug with print statements. It's enough in 95% of cases and it works every time in every environment. In the time it takes me to get a debugger running and attached to a process, I've print-debugged it and fixed it already =)

Same here. I very rarely reach for a debugger. Especially with Go where you can recompile the binary very quickly.

I tend to reach for a debugger when doing post mortem debugging or when I work with C where that's usually the easiest way to get a stack trace when a program crashes.

That said, time travel / reverse debuggers can be quite useful indeed: see http://choly.ca/post/debugging-go-with-rr/

Re: Go 1.17 Release Notes

#156

Post by ithkuil »

pjmlp wrote: post #122
pxue wrote: post #35

The go code I wrote in 2015 looks and works exactly the same way new Go code I'm writing today. Even with all the upgrades. You have no idea how amazing that feels.

My C and C++ code for Windows 3.1 written in 1995 would compile just fine today on Windows 10.

I heard this a lot but I wonder if it's still really true. I mean, can I literally open the latest visual studio and open an old project, hit build and it will just work?

Re: Go 1.17 Release Notes

#157

Post by flohofwoe »

umvi wrote: post #7

At first I didn't like Go because I thought it was too opinionated. But the more I used it, the more I found the tooling to be just heads and shoulders above similar languages like C/C++. I use VSCode a lot, and in VSCode you can press "F12" to jump to the location of a function definition. In Go I find myself deep diving into github libraries all the time just because F12 takes me there. That never happened with C/C…

Cross-platform Intellisense support in VSCode with the Microsoft C/C++ extension has improved a lot lately, especially in combination with the CMake Tool extension to automatically discover header search paths and other compilation settings (it used to be very brittle in the beginning on Linux and Mac).

But if you're coding C/C++ in a "proper" IDE like Visual Studio, CLion or Xcode, such features are expected to work out of the box. IME, Intellisense-like features are usually only a pain to setup in "non-integated" development environments like Vim or other text editors.

Re: Go 1.17 Release Notes

#158

Post by pjmlp »

ithkuil wrote: post #156
pjmlp wrote: post #122

Earlier quoted context omitted.

My C and C++ code for Windows 3.1 written in 1995 would compile just fine today on Windows 10.

I heard this a lot but I wonder if it's still really true. I mean, can I literally open the latest visual studio and open an old project, hit build and it will just work?

Naturally it depends on what you are doing, but for regular Win16/Win32 code that uses Windows type macros and no low level tricks pretty much so.

And even if you take Win16 out of the picture, Win32 exists since 1995.

Re: Go 1.17 Release Notes

#159

Post by pjmlp »

deathanatos wrote: post #148
pjmlp wrote: post #120

Earlier quoted context omitted.

That is a misconception, RAII like code can be achieved in two ways: - defer (possibly add a go vet check for when missing it) - when Go 1.18 brings generics, the withFunc pattern from FP where lambdas get given a resource released on function exist, thus having regions/arena like resource management

defer (/using/with) all require the programmer to remember, and write, O(use site) times, the code to release the resource. RAII destructors, on the other hand, do not permit the coder (at the use site of the type) to forget, as the destructor is invoked automatically when the variable goes out of scope. In my time reviewing Python (also GC, "with" provides a similar functionality), this is a very common error.

Apparently you missed my go vet reference on purpose, just make all of us aware of it not being the same.

Same applies to using on .NET, where forgetting to call using on an IDisposable type can trigger a compiler error, via Roslyn plugins.

Also seem to be unaware how closure based RAII works on FP languages.

RAII isn't triggered on heap allocated objects unless smart pointers are used everywhere.

Python doesn't have a static analysis tool for with, nor does it support value types with stack allocation. Not all GC languages were born equal.

Re: Go 1.17 Release Notes

#160

Post by ithkuil »

pjmlp wrote: post #158
ithkuil wrote: post #156

Earlier quoted context omitted.

I heard this a lot but I wonder if it's still really true. I mean, can I literally open the latest visual studio and open an old project, hit build and it will just work?

Naturally it depends on what you are doing, but for regular Win16/Win32 code that uses Windows type macros and no low level tricks pretty much so. And even if you take Win16 out of the picture, Win32 exists since 1995.

I'm not doubting that the windows API has remained stable. I'd like to try if the tooling (e.g. IDE config format or makefile equivalent) has also received the same amount of attention to backward compat
Post reply on HN