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

131–140 of 222 posts

Re: Go 1.17 Release Notes

#131

Post by theshrike79 »

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 exciting really. It just does the job, albeit verbosely.

You can do fancy shit on your own time.

Re: Go 1.17 Release Notes

#132

Post by theshrike79 »

systemvoltage wrote: post #128
_008_jb_ wrote: post #110

When I started using Go I was more than sceptical. I had to mirgrate a CLI tool written in Kotlin (still my favorite language) because the memory consumption was to high. After a while I actually understood why Go is such a successful language / ecosystem: Go's priority is to make projects easier. It is doing so by all it's smaller and larger features respectivly skipped features. But one soon understands the big pic…

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 =)

Re: Go 1.17 Release Notes

#133

Post by theshrike79 »

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.

The difference between Java, Go and Rust is that you can teach the first two to any fresh out of school CS grad in a week or two and have them be productive.

Not so much with Rust.

Re: Go 1.17 Release Notes

#134

Post by theshrike79 »

nwmcsween wrote: post #33
Techasura wrote: post #4

Never tried to write Go before, maybe it’s time that I stop by.

It's meh for a language, it's simple which is what they are trying to achieve but it all comes with trade offs like all programming languages. I would say a large portion of a language is how you mesh with the syntax and tooling around it.

Go being "meh" is one of its best parts.

It doesn't encourage you to do fancy language tricks, it kindly directs you to get your shit done, compiled and delivered.

Re: Go 1.17 Release Notes

#135

Post by eweise »

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…

"you can press "F12" to jump to the location of a function definition" Seems like standard IDE functionality for at least 20 years.

Re: Go 1.17 Release Notes

#136

Post by zozbot234 »

tptacek wrote: post #106
josephg wrote: post #69

Earlier quoted context omitted.

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

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), and some of what it gives you expressive control over is stuff you usually don't need to think about at all in other languages. Rust can do some things Go simply isn't suited for right now; for instance, there is no way we're getting kernel Go in the fores…

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

Re: Go 1.17 Release Notes

#137

Post by erik_seaberg »

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…

> feels late to make such a big change

This is recoverable. The Java world was also saddled with a decade of awful pre-generic code, but we burned almost all of it to the ground and started over.

Re: Go 1.17 Release Notes

#138

Post by Groxx »

yakubin wrote: post #89
initplus wrote: post #47

Earlier quoted context omitted.

If you use C++ tools where your dependencies get pulled in and built from source like Go does, you get the same experience. If you only have prebuilt system libraries obviously this doesn't work. It's not like Go's tooling is that much better than the best modern C++ tools, but the ecosystem is so much more unified by having 1 blessed set of tooling. Rather than 20 different package managers/(meta)build systems. No n…

In C++, preprocessor and template magic in dependencies tends to break such IDE convenience features as "go to definition" or "find all references".

tbh I've had dramatically worse type-aware IDE features with Go than almost any other mainstream language. gopls routinely misses trivial things in the same file. Goland does substantially better, but it still has major problems gathering a complete call hierarchy, and basic things like moving a file to a different package (with no compilation issues, just import rewrites) still don't work reliably.

Re: Go 1.17 Release Notes

#140

Post by pjmlp »

steren wrote: post #129
systemvoltage wrote: post #125

Earlier quoted context omitted.

As a person that gets anxiety from JS projects and how fast things move, I love this aspect of C. It puts the soul to ease.

The JS code you wrote 20 years ago still runs today (and much much faster) The problem is not JS, more the dependencies you decided to take for your project.

Indeed. Going back to my example, stuff written with OWL won't compile today.
Post reply on HN