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

181–190 of 222 posts

Re: Go 1.17 Release Notes

#181

Post by throwaway894345 »

Blikkentrekker wrote: post #180
throwaway894345 wrote: post #174

Earlier quoted context omitted.

I really, really like type systems, but I’ve built enough software to know that the returns for most applications diminish after a Go-like type system is in place, and there are many other factors that are more important than type systems (and Rust gets a lot of these right too!) such as performance, productivity, tooling breadth and quality (especially build tooling and package management), ecosystem, deployment/dis…

It has nothing to do with catching bugs. It has to do with that one sometimes has to write 80 lines of code in Go to to the same as 3 lines of Rust code due to having to repeat oneself all the time.

That’s an even more superficial concern. No one is bottlenecked on the rate at which they can type.

Re: Go 1.17 Release Notes

#182

Post by zozbot234 »

kubb wrote: post #57

I’ve been using Go at a large software company for 4 years. It does the job, my biggest complaints are the low capacity for abstraction, verbosity and ergonomic pain points. It can do certain things well, but in a large enough project you’ll inevitably find that it doesn’t give you the best tools for certain types of problems. I don’t know what to think about the upcoming generics. It feels late to make such a big ch…

> an effort with similar funding but a more sound theoretical foundation than being Newsqueak 3.0 could have become an industry game changer.

That's a pretty good description of Rust 0.x. Might ring a bell.

Re: Go 1.17 Release Notes

#183

Post by the8472 »

ithkuil wrote: post #152
the8472 wrote: post #45

Earlier quoted context omitted.

> 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 tri…

Looks like I misunderstood, I was suggesting something more indirect than tracing calls to malloc. If you're already doing that then I'm not aware of any better low-overhead solutions. There are high-overhead options such as valgrind's dhat.

Re: Go 1.17 Release Notes

#184

Post by pgwhalen »

zz865 wrote: post #126
pgwhalen wrote: post #34

Earlier quoted context omitted.

I use (and enjoy using) both Go and Java at work, and Go is in my opinion very much a Java replacement more than it is, say, a Python or C++ replacement. It is absolutely suitable for business logic, and I've never been quite sure what its designers mean when they say it's a systems language. Yes, you can squeeze great performance out of it, but you can with Java as well. The way I see it, both Go and Java are crawli…

Thanks, that sounds about right. Throw Rust in there too, its an interesting time.

Rust is a great language too (I'm in the process of learning it), but I would definitely not put it in the same category as Java and Go in terms of the problems it is good at solving. It fits much more with C/C++.

There is a huge class of problems that don't need the precision (especially around memory) that Rust demands from the programmer.

Re: Go 1.17 Release Notes

#185

Post by nemetroid »

pjmlp wrote: post #178
nemetroid wrote: post #161

Earlier quoted context omitted.

> RAII isn't triggered on heap allocated objects unless smart pointers are used everywhere. It's triggered unless you have memory leaks.

So it isn't.

Correct, but except in very special cases, memory leaks are themselves considered bugs. Using memory leaks as an example of RAII not always working is, in my mind, similar to saying Rust doesn't prevent memory errors since it has the "unsafe" keyword.

Re: Go 1.17 Release Notes

#186

Post by dilyevsky »

pjmlp wrote: post #121
atombender wrote: post #55

Earlier quoted context omitted.

And yet Go seems to have not captured many C++ developers, but rather developers from languages like Python, Ruby, and JavaScript. The Go team originally wanted to replace C++, especially inside Google, but they didn't succeed. According to googlers on Hacker News, very few projects inside Google actually use Go. The reason Go attracted these kinds of developers is precisely that it isn't a systems programming langua…

Lack of generics kept most of us away. You don't return to 1992 C++, thinking nah this is fine. Companies like F-Secure are using Go for real system programming just fine. https://www.f-secure.com/en/consulting/foundry/usb-armory

Under wider definition of “system software” you can consider db tech (etcd, cockroachdb, digraph) and compute management software (kubernetes, nomad, docker) to be included into that. Which is where Go is doing just fine. Lower level stuff is harder but because of gc not lack of generics

Re: Go 1.17 Release Notes

#187

Post by tialaramex »

pjmlp wrote: post #177
tialaramex wrote: post #166

Earlier quoted context omitted.

The description for go vet says, "it should be used as guidance only". Go vet is in fact a linter (go lint is also a linter, but one focused on style). So what you're doing there is adding a control to try to mitigate the consequences of a language failing. Go doesn't actually prevent you from getting this wrong, but a linter such as go vet can flag cases where it suspects you screwed up, and maybe you'll catch the w…

Just like you need to use clang tidy to fix all the issues with writing proper C++ code.

Fair. However, there continues to be an unresolved tension in the C++ community about whether they want C++ to focus on its considerable legacy by ensuring enduring compatibility ("No ABI breaks, ever!") or to continue growing and changing even if that means not everybody can follow ("Performance trumps compatibility, ship it!"). Although we can anticipate some sort of compromise, it just isn't possible to have a C++ 2x that delivers everything the modernizers want yet still runs people's technically conforming C++ 11 code unchanged with that binary DLL they've got no source code for. Some people will be unhappy, maybe everybody in the C++ community will end up unhappy.

In the "no breaking changes" case I agree that C++ objects that live in the free store are in the same place as Go, the programmer has a responsible which they may not fulfil, to manage this resource and a linter can only help mitigate this problem.

But plenty of people including Stroustrup want to do lifetime management, despite potential breaking changes from that, and under lifetime management the compiler has visibility into your object lifetimes and can reject programs which inadvertently leak.

Now, that doesn't (can't) make leaks impossible, but it means any leak is now in some sense "on purpose" and would happen for GC'd resources too, it isn't just an accident. For example Rust's mem::forget will prevent the drop happening for the object you're forgetting, but it's not as though you type mem::forget() by mistake. You clearly wanted to achieve that (e.g. you stole the underlying Unix file descriptor from a File and sent it over a socket to a separate process, so now cleaning up that descriptor is the Wrong Thing™) and incorrect usage is not the same category of error as forgetting a with clause in Python.

Re: Go 1.17 Release Notes

#188

Post by int_19h »

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…

This is more a limitation of VSCode than C++. Go to Definition for C++ works just fine in Visual Studio proper for many years now.

Re: Go 1.17 Release Notes

#189

Post by int_19h »

slownews45 wrote: post #49
rowanG077 wrote: post #43

Earlier quoted context omitted.

Isn't that the case for the vast majority of languages though? The python,c,Haskell,js,language x code from 2015 works the same now as it did 5 years ago.

python 2 -> 3 was not easy (aka a total nightmare). By 3.6 it was pretty good though and even migrations and dual code bases were easier because they went back and allowed things like u"" for unicode strings to continue to mean unicode strings in python 3 - before that they'd actually blocked unicode in 3 that was working well in 2.x code bases! It was a total in your face move to break the ecosystem even though supp…

Python 3 should be considered a different language from Python 2, pretty much.

Re: Go 1.17 Release Notes

#190

Post by int_19h »

theshrike79 wrote: post #131
37ef_ced3 wrote: post #11

My appreciation for Go has been monotonically increasing for years. The more Go code I write, the more I like the language, the tools, and the standard library. Low-friction, high-quality software development. If only I could use it professionally, instead of C++.

Go is the choice of professionals IMO. When you have a team of varying skill levels who need to deliver shit that works on a schedule and still have some kind of performance, you use Go. Even more so if you need to hand off the maintenance to a team of randoms from god knows where and THEY need to be able to keep it running and add new features. It doesn't have the fanciest new EXPRESSIVE operators or anything exciti…

I would argue that e.g. decent error handling is not "fancy shit".
Post reply on HN