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

171–180 of 222 posts

Re: Go 1.17 Release Notes

#171

Post by vips7L »

atombender wrote: post #55
dilyevsky wrote: post #39

Earlier quoted context omitted.

Python/Js are interpreted by default and not good system programming choices. Go is compiled. This comparison totally misses the mark. In fact Go was developed mostly as C++ but sometimes Python replacement at Google.

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…

In my opinion they should have pushed for D instead of Go. It’s leagues better as a systems language if you can tolerate GC or if you can’t you just don’t use the GC.

Re: Go 1.17 Release Notes

#172

Post by throwaway894345 »

throwaway34241 wrote: post #99
tialaramex wrote: post #92

Earlier quoted context omitted.

> but there is still a big productivity gap between the borrow checker and GC. The borrow checker and GC aren't really doing the same thing though. One very important distinction in some fields (but unimportant in others) is that GC only really cares about memory resources. So you are (or should be) doing explicit manual cleanup for all non-memory resources in a GC language. Rust isn't, in Rust we don't write explici…

> Go doesn't even bother providing a means to do this automatically for your non-memory resources when they're garbage collected (Java does, but again, no promises it ever fires, so, don't rely on this). It sounds like you are talking about finalizers? If so, they exist in Go in a similar way to the Java feature [1]. [1] https://pkg.go.dev/runtime#SetFinalizer

Finalizers aren’t quite the same. They run when memory pressure exceeds some threshold, but the GC analog for borrow-checking is something that will clean up a resource when the pressure on the resource in question exceeds some threshold (e.g., file handles). And even then I’m not sure if that ticks all requirements for resource management.

Re: Go 1.17 Release Notes

#173

Post by azth »

xwdv wrote: post #24
candiddevmike wrote: post #8

Earlier quoted context omitted.

Generics are hopefully coming February 2022 with 1.18.

This will be when I finally use Go for something then.

Even with generics, it has so many issues:

* Error handling is error prone and awkward.

* No proper enums

* No sum types/pattern matching

* Null pointers exist

* Its interfaces are very awkward. There are superior implementations of what they tried to do in other languages.

* Subpar IDE experience, made worse by how interfaces are implemented. You need an IDE for any non-trivial project.

* Very awkward choice to have visibility be determined by the case of the first letter in the function or variable. Simple changing of visibility to public will require larger diffs if it's used a lot.

* No private visibility, only package private.

* Very crude import mechanism. Try to rename a package and see how the IDE fails to figure out what to change.

Re: Go 1.17 Release Notes

#174

Post by throwaway894345 »

Blikkentrekker wrote: post #94
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…

> 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. Even if it weren't for the performance I would use Rust over Go due to the lack of generics…

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/distribution story, learning curve, readability, etc. Ultimately I’m of the opinion that as cool as type systems are, for most software they need to exist in service of productivity which means you need a basic type system that helps you but gets out of your way. Type systems can’t catch many classes of bugs that are increasingly prevalent in a world where our services are getting increasingly smaller (or rather, where more infrastructure and networking are being put in between the logical components of our application) and we’re often able to detect bug fixes before they impact a significant number of users (progressive deployments, automated rollbacks, continuous deployment, etc) but the discourse around type systems hasn’t caught up yet.

Re: Go 1.17 Release Notes

#175

Post by azth »

benhoyt wrote: post #70
ridiculous_fish wrote: post #58

Earlier quoted context omitted.

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

With the introduction of generics in Go 1.18 and the accompanying "slices" package ( https://github.com/golang/go/issues/45955 ), we might soon write that as: a = slices.Delete(a, i, i+1) That said, in code I write, I rarely need to do an in-place delete from a slice. I think it's rare enough that recognizing the idiom is okay.

It's so weird why they're adding a slices package instead of making them functions on the slice itself. They did the same with strings.

Compare

    strings.ToUpper(strings.Replace(strings.Trim(s), "a", "b")))
Instead of

    s.Trim().Replace("a, "b").ToUpper()

Re: Go 1.17 Release Notes

#176

Post by pjmlp »

ithkuil wrote: post #160
pjmlp wrote: post #158

Earlier quoted context omitted.

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

Again, depends on what you were using.

Borland C++ or Watcom, probably not much help.

Delphi, C++ Builder, Visual C++ for Windows 95/2000 mostly work, naturally you might need to use the IDE wizards to upgrade project files, or fix tooling paths on the makefiles.

Re: Go 1.17 Release Notes

#177

Post by pjmlp »

tialaramex wrote: post #166
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

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.

Re: Go 1.17 Release Notes

#178

Post by pjmlp »

nemetroid wrote: post #161
pjmlp wrote: post #159

Earlier quoted context omitted.

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…

> 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.

Re: Go 1.17 Release Notes

#179

Post by josephg »

throwaway894345 wrote: post #168
zozbot234 wrote: post #136

Earlier quoted context omitted.

> Rust is very expressive, but it also makes some tasks that are relatively simple in other languages much harder (anything involving tree structures, for instance) Much harder, not really. Rust lets you add mutability, reference counting and thread safety to your data structures, you just need to know when to use these features. Yes, Go has fully general GC but very few problem domains have a real need for general G…

> Yes, Go has fully general GC but very few problem domains have a real need for general GC. No, no one needs a GC, but many problem domains need productivity, and GC is the most productive way to manage memory to date. As previously mentioned, Rust has made truly impressive strides in improving productivity of borrow-checking, but it still remains quite far behind GC.

Yes, having written a b-tree in rust recently I can confirm this. My child node pointers look like this:

    enum Node> {
        Internal(Pin>>),
        Leaf(Pin>>),
    }
Yikes. I could probably clean this up a little, but not a lot.

I've been working on this code for months and I still have no idea if my internal b-tree functions should be taking a &mut self, self: Pin or a NonNull or something else. The compiled code is blazing fast, and being able to control behaviour so clearly with a few parametric type parameters is amazing.

But the process of figuring out the best way to code it up is awful, and it requires all of my attention and capacity. I doubt Rust will ever gain the sort of mainstream usage that javascript & Go have because of how complicated otherwise simple problems can become. Its a great language for the linux kernel and web browsers. But I can't imagine many normal programmers will want to build regular websites and apps in rust.

GC languages are slower, but credit where its due - they make it so much easier to just dive in and spend all your braincells thinking about your problem domain.

Re: Go 1.17 Release Notes

#180

Post by Blikkentrekker »

throwaway894345 wrote: post #174
Blikkentrekker wrote: post #94

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. Even if it weren't for the performance I would use Rust over Go due to the lack of generics…

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.

Post reply on HN