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

211–220 of 222 posts

Re: Go 1.17 Release Notes

#211

Post by int_19h »

theshrike79 wrote: post #210
int_19h wrote: post #201

Earlier quoted context omitted.

I don't see how it forces you to ignore? You don't have to be explicit to ignore the returned error code.

That's what the underscore is for, explicit ignore. And it's a huge code smell. You instantly notice it because the if err != nil -template is missing after it =)

Sorry, I didn't word that well. What I meant is that you can ignore the returned value altogether, including the error.

https://github.com/golang/go/issues/20803

In contrast, e.g. Zig requires you to use _ if you want to ignore.

Re: Go 1.17 Release Notes

#212

Post by asadawadia »

DenseComet wrote: post #36
asadawadia wrote: post #31

Earlier quoted context omitted.

why though? some perf gains?

Go isn't low level in the same way that Rust is. Both languages have their places, but Go seems to be more of a better Python/JS, whereas Rust is a better C++.

That is not really a reason. What can I not build in Go that is easy to do in rust?

Re: Go 1.17 Release Notes

#213

Post by asadawadia »

zarzavat wrote: post #67
37ef_ced3 wrote: post #53

Earlier quoted context omitted.

Go should be understood as a replacement for C and C++. If you're writing a compiler, or some other project where extreme high performance is not necessary (e.g., if you're willing to be, say, a factor of 2 slower than C) then Go is a good choice. Go's performance is excellent, and should be sufficient for all but the most demanding applications. It's not a crummy scripting language like Python/JS.

Go is a replacement for a certain subset of C/C++ projects that are I/O heavy, e.g. web servers. However the GC precludes it from many uses of C/C++, e.g. you couldn't write an AAA game in it, or a kernel, or a toaster.

Yeah but how often do we meet toaster devs?

Re: Go 1.17 Release Notes

#214

Post by asadawadia »

KronisLV wrote: post #50
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.

That's just one of the ways to think about it. Java, .NET (I felt like adding these two to expand on the comparison), Python and JS are all languages with a relatively high level of abstraction and large and useful ecosystems surrounding them. They're pretty popular for all sorts of application development, but all suffer from certain problems: - Java has lots of brittle reflection in some libraries and JDK can be fi…

>systems level programming or embedded development

Like building what?

Re: Go 1.17 Release Notes

#215

Post by lanstin »

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.

Because in-place delete is slow and you want to avoid algorithms with a lot of in-place deletes. So it's ok to have it be awkard, it's like the names of rare elements being longer than the names of common elements, not an issue.

Re: Go 1.17 Release Notes

#216

Post by kccqzy »

yakubin wrote: post #162
kccqzy wrote: post #114

Earlier quoted context omitted.

This almost doesn't happen when your tools are good. At Google the Kythe tool ( https://kythe.io ) gracefully deals with templates, macros, and much more. Both "go to definition" and "find references" just work with 99.9% of C++ code, including within complicated macros and templates. (The one and only case I've ever found it doesn't work is to find references to a function that's only called via ADL in a widely used…

What about SFINAE?

Works. Because it uses the compiler to figure out what calls what, and so the compiler has already selected the right overload.

Re: Go 1.17 Release Notes

#217

Post by nyanpasu64 »

kouteiheika wrote: post #150
nyanpasu64 wrote: post #124

Earlier quoted context omitted.

How does this one compare to Heaptrack (which is a CLI/GUI memory profiler that supports C++ and probably Rust as well)?

There are many differences, but the main ones are that it has less overhead when profiling, more thorough analysis features (Heaptrack's GUI is relatively simple compared to it), and the next version will have scripting capabilities for analysis.

Hmm, took a look (it's called Bytehound now), it has no PKGBUILD nor a `cargo install` crate so I can't install it in systemwide or user PATH, and requires Yarn to download and build JS dependencies (likely hundreds or thousands).

I tried `cargo install --git https://github.com/koute/bytehound.git`, but that results in "error: multiple packages with binaries found: bytehound-cli, bytehound-gather, interrupt, linking, lz4-compress, simulation".

For the time being I'll stick with heaptrack.

Re: Go 1.17 Release Notes

#218

Post by gnubison »

kjksf wrote: post #76
cpeterso wrote: post #54

Earlier quoted context omitted.

> the design decisions leading to the existence of `time.IsZero()` are bordering on criminal. What's the rationale for Time.IsZero()? Seems like every use case for Time.IsZero() I think of is a code smell. The 1970 epoch is an implementation detail that should be hidden or configurable. People probably use IsZero() as a sentinel value to indicate "undefined time", even though the 1970 epoch is a valid point in time.

.IsZero() is a pragmatic solution given the constraints of the system (i.e. Go language). Go has a notion of "zero value". When you don't assign a value explicitly it'll be set by the compiler to "zero value" of that type. This is much better than C/C++ of "random value". For primitive types, the compiler decides what "zero value" is. For structs, each component is set to its zero value. For good reasons (language si…

It may be pragmatic, but it’s incorrect. “Is this time value an unset time value?” is not a question you can answer (using IsZero considers the epoch an unset time value, but it’s a perfectly valid set one too).

Re: Go 1.17 Release Notes

#219

Post by zarzavat »

asadawadia wrote: post #213
zarzavat wrote: post #67

Earlier quoted context omitted.

Go is a replacement for a certain subset of C/C++ projects that are I/O heavy, e.g. web servers. However the GC precludes it from many uses of C/C++, e.g. you couldn't write an AAA game in it, or a kernel, or a toaster.

Yeah but how often do we meet toaster devs?

The toaster industry has a big problem with burnout.

Re: Go 1.17 Release Notes

#220

Post by lizmat »

slownews45 wrote: post #198
int_19h wrote: post #189

Earlier quoted context omitted.

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

The level on intentional compatibility breaking was crazy. The fact that they went out of their way to break python 2 unicode when running on python 3 was just totally nuts. Especially after making such a big deal about unicode! I've never seen anything like it I don't think? Maybe the new Perl that never really landed?

That "new" Perl landed in 2015 as "Perl 6". It has been renamed to The Raku Programming Language in 2019 (https://raku.org #rakulang).
Post reply on HN