Re: [go-nuts] Re: Error checking in Go: The `try` keyword

Hi, I'd like to add that for this particular purpose, I find the keyword "try" quite inappropriate. It makes sense in other languages, either with a *catch* "counterpart" or not. But in those cases (at least those I'm aware of), you're not trying a value, which makes no sense to me. You try an

[go-nuts] Re: Error checking in Go: The `try` keyword

Hi, as I recently mentioned in another thread, you can already use this error handling stye without language changes: https://play.golang.org/p/nDnXxPXeb-- (The function is named "check", not "try".) See error decoration at the bottom. -- You received this message because you are subscribed

[go-nuts] Why Discord is switching from Go to Rust

I think Go is way better than Rust, but it is amusing to see why people pick one over another. "Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This

[go-nuts] Re: Error checking in Go: The `try` keyword

f, err := os.Open("file.dat") try errors.Wrap(err, "couldn't open file") You approach has some merits to it. In addition to that some error handling solution needs to provide a way how to figure out what error happened, e.g. openening a file could fail because it does not exist or because of

Re: [go-nuts] [ANN] GoLand 2020.1 EAP starts with Go Modules improvements and Go 1.14 support

Outstanding IDE! I was always impressed with JetBrains stuff but Goland really rocks! On Fri, Feb 7, 2020 at 10:20 AM Florin Pățan wrote: > Hi Gophers, > > I'd like to announce the start of the 2020.1 Early Access Program of > GoLand IDE, the JetBrains dedicated IDE for Go development. > A few

[go-nuts] Re: Error checking in Go: The `try` keyword

In case of multiple return values, it works similar to the original proposal. This should work with multiple return values. As I stated, this isn't a complete proposal. On Thursday, February 6, 2020 at 10:55:35 PM UTC-7, MUNGAI wrote: > > I agree, > Some of the proposals introduce more trouble

[go-nuts] [ANN] GoLand 2020.1 EAP starts with Go Modules improvements and Go 1.14 support

Hi Gophers, I'd like to announce the start of the 2020.1 Early Access Program of GoLand IDE, the JetBrains dedicated IDE for Go development. A few highlights from the release include: - support for Go 1.14 - improved support for Go Modules - improved code completion, Live Templates,

[go-nuts] Dependency hierarchy in go

Hello! Project A depends on B and B depends on C. A -> B -> C. When I create fork of C = C1 with new features I will add go.mod replace command like that "replace C => C1". But when I import B in project A got missing C1 replace command in go.mod is it intended feature or bug? As result my

Re: [go-nuts] OT: Gos Simplicty Re: Error checking in Go: The `try` keyword

On 2020-02-07 08:56, Michel Levieux wrote: > I'd like to add that for this particular purpose, I find the keyword "try" > quite > inappropriate. When I did "Systems Programming" they didn't even teach C itself but rather some C library functions, which wasn't very helpful when I look back on it.

Re: [go-nuts] Why Discord is switching from Go to Rust

> "Remarkably, we had only put very basic thought into optimization as the Rust > version was written. Even with just basic optimization, Rust was able to > outperform the hyper hand-tuned Go version. This is a huge testament to how > easy it is to write efficient programs with Rust compared to

[go-nuts] Re: Error checking in Go: The `try` keyword

[sorry, posted a half post before] You would want to have the error value at hand and do everything explicitly. Using the try keyword really feels like going back to some other languages where you would push everything up and then handle a bunch of errors/exceptions in a "all eggs in one

Re: [go-nuts] Why Discord is switching from Go to Rust

On Friday, February 7, 2020 at 5:13:45 PM UTC+1, Lutz Horn wrote: > > > "Remarkably, we had only put very basic thought into optimization as the > Rust version was written. Even with just basic optimization, Rust was able > to outperform the hyper hand-tuned Go version. This is a huge testament

[go-nuts] Re: Dependency hierarchy in go

On Friday, February 7, 2020 at 10:35:37 PM UTC+3, Jason Phillips wrote: > > Replace only works for the top-level go.mod. From the proposal doc (link > > ): > >> Minimal version selection gives the top-level module in

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

On my microbenchmarks I'm seeing a huge negative impact (ca. 15%) under the Linux ondemand governor. Under the performance governor its less than 1%. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Why Discord is switching from Go to Rust

You're not oversimplifying. GC incurs a price, and that's performance. If you have a program which manages its own memory optimally for its usage pattern, it will be more efficient than a generic GC that has to handle all usage patterns. I use Go everywhere I can, since the tradeoff between

[go-nuts] Re: Why Discord is switching from Go to Rust

https://twitter.com/_rsc/status/1224802726774812672?s=20 https://twitter.com/_rsc/status/1224802727773065221?s=20 On Friday, 7 February 2020 12:24:50 UTC, Everton Marques wrote: > > I think Go is way better than Rust, but it is amusing to see why people > pick one over another. > > "Remarkably,

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

Hi! I am seeing a generally negative impact of Go 1.13 -> 1.14-RC1 in terms of speed. Running benchmarks in my deflate package - and removing the "no change" entries: nameold time/opnew time/opdelta DecodeDigitsSpeed1e5-12903µs ± 0% 940µs ± 1%

[go-nuts] Re: Dependency hierarchy in go

I'm I bad at explaining? Simple form: A (go.mod = require B) -> B (go.mod = require C; replace C=>C1) -> C1 'A' failed to compile because it does not see C=>C1 replace in child project. Does GO require to copy all replace commands from all child projects in main go.mod manually or is it a bug?

Re: [go-nuts] Why Discord is switching from Go to Rust

I didn’t look into the project but reading between the lines here I am betting that Java would perform as well as Rust in this case. This is an example of where not having generational GC hurts badly - since it appears that most of their heap would be very long lived objects. > On Feb 7,

Re: [go-nuts] Why Discord is switching from Go to Rust

It would have been nice to see performance measurements from a more recent Go version. That said, it makes sense to me that Rust would be a better choice for this kind of application, where the main performance bottleneck is the sheer number of objects in memory. A language where you get to

[go-nuts] Re: Dependency hierarchy in go

Replace only works for the top-level go.mod. From the proposal doc (link ): > Minimal version selection gives the top-level module in the build > additional control, allowing it to exclude specific module versions or

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

I would caution that reduced performance with ondemand might be a good thing. If the job is doing lots of IO this means the process has little/less overhead so less drain on the cpu meaning it takes a while to spin back up. If both governors show the serious degradation I would be far more

[go-nuts] Re: Error checking in Go: The `try` keyword

To make an attempt at articulating why the error handling in Go is valuable as-is, I note the following points: - It is explicit, not hidden - The default idiom highlights "error checking being done here" (Go developers learn to look for lines "if err != nil".) - It is possible to

Re: [go-nuts] Why Discord is switching from Go to Rust

On Fri, Feb 7, 2020 at 11:43 AM Robert Engels wrote: > I didn’t look into the project but reading between the lines here I am > betting that Java would perform as well as Rust in this case. This is an > example of where not having generational GC hurts badly - since it appears > that most of

Re: [go-nuts] Why Discord is switching from Go to Rust

I think if you look into Zing or Shenandoah you’ll find a different experience. Literally zero tuning required. > On Feb 7, 2020, at 3:29 PM, Marcin Romaszewicz wrote: > >  > > >> On Fri, Feb 7, 2020 at 11:43 AM Robert Engels wrote: >> I didn’t look into the project but reading between

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

On Fri, Feb 7, 2020 at 11:01 AM Klaus Post wrote: > > I am seeing a generally negative impact of Go 1.13 -> 1.14-RC1 in terms of > speed. Thanks. Would you mind opening an issue about this (if you haven't already)? Ian -- You received this message because you are subscribed to the Google

Re: [go-nuts] Why Discord is switching from Go to Rust

Tyler Compton : > It would have been nice to see performance measurements from a more recent > Go version. That said, it makes sense to me that Rust would be a better > choice for this kind of application, where the main performance bottleneck > is the sheer number of objects in memory. A language

[go-nuts] Re: Error checking in Go: The `try` keyword

I see your point. I think it may be better to* narrow the scope* of what should be improved. For the most part, I like the simplicity of error handling in Go, but I would very much like a less verbose way to pass errors. Technically we are not talking about handling the errors but we just want

Re: [go-nuts] Why Discord is switching from Go to Rust

> On Feb 7, 2020, at 10:44 PM, Eric S. Raymond wrote: > > On the other hand, for me to have tried to port reposurgeon to Rust > would have been a mind-numbingly stupid idea. And that will be true of > any application above a certain complexity of internal data-structure > management, where