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

[Bakul Shah]

> 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 having GC moves from bein convenient to an essential tool
> for holding dowb your defect rate.

Did you consider using nim? It is much closer to python. You could've even
selectively replaced python bits with nim bits based on profiling.

https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

In the past I have "rewritten" programs by simply observing their
behavior and modeling in a toy program, taking care to keep the code
as simple as possible. This allows quick evolution and pretty soon
the toy can do most everything the original program does. Not really
surprising since the new program didn't have to make the mistakes
the old program made and has the old program as a reference. I found
literal translation to be much more painful. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4EB79AC2-D0D1-4A18-9B31-2438149462A7%40bitblocks.com.

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

[addi t0t08]

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 
to pass them.


The keyword 'try' may be misleading if our focus is just a simple way to 
pass errors.
I think the keyword we are looking for is `pass`. Similarly, `pass` only 
needs to return if err != nil.

func writeSomething() error {
   f, err := os.Open("file.dat")
   pass err
   defer f.Close()

   f.WriteString("...")
}
---
passing a wrapped error(using the Wrap function above which returns nil if 
err is nil (not a special function) ):


func writeSomething() error {
   f, err := os.Open("file.dat")
   pass errors.Wrap(err, "couldn't open file")
   defer f.Close()

   f.WriteString("...")
}


The following points from your reply still/or should work with `pass` 
(modified):


   -  It is explicit, not hidden
   - The default idiom highlights "error is being passed here" (Go 
   developers learn to look for lines "pass err".)
   - It is possible to set breakpoints (should work similar to a return 
   statement)
   - Code coverage of unit tests reports when the error case has been 
   exercised.
   - Support for Wrapping errors
   - Supports multiple returns with zero values.
   - It is straightforward to parse / analyze.


The following drawbacks are no longer there:

   -  Vertical space: Even in complex cases, the error handling inside the 
   "if" block can be reduced to at most two statements. One line for 
   "handling" the error, and a second line for returning it (or a modified / 
   wrapped version of it). With two additional vertical lines of boilerplate, 
   that's either a 100% or 200% increase in vertical space (the "if" 
   statement, and the closing brace). This limits the amount of code that can 
   fit on my screen, which constrains my ability to comprehend larger 
   functions.
   -  Verbosity: The moment we're know we're checking for errors, the "if 
   err != nil {", the "return", and the "}" are usually just extra syntax.
   - Scanning complexity: What if the check is not err != nil, but err != 
   NotFound? Is this an error case, or an expected case? The current construct 
   hides that distinction. We have to look to the next line to see how it is 
   handled to know that it is an error return.
   - When there are multiple returns on a function, the error handling must 
   specify them all, even though the common case is to return a "zero" value.


The following however is not within the scope for 'pass':


   - If you want to log errors, you're handling it. 'pass' is only for 
   passing errors.
   - If you want to check for a specific error. 'pass' is only for passing 
   errors.
   - If you have a more complicated case.  'pass' is only for passing 
   errors.


pass should work with 100% of the cases within its limited scope. 

I would like to submit a proposal for 'pass', but I'm not sure if it's 
something that would be considered.





On Friday, February 7, 2020 at 5:38:56 PM UTC-7, Eric Johnson wrote:
>
> 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 set breakpoints on the error case
>- Code coverage of unit tests reports when the error case has been 
>exercised.
>- It has the full flexibility of identifying the failure scenario, not 
>limited to err != nil (although that is the overwhelming use)
>- It has the full power and flexibility of the language for handling 
>the error - it can be logged, returned, recovered from, sent to a channel, 
>etc.
>- If wrapping my error extends to multiple lines (due to longer 
>messages, number of parameters in the error, etc., that works using 
>existing language constructs.
>- It supports arbitrary return statement complexity, including 
>multiple return values.
>- It is straightforward to parse / analyze.
>
> That said, it has some drawbacks, particularly in the most common cases.
>
>- Vertical space: Even in complex cases, the error handling inside the 
>"if" block can be reduced to at most two statements. One line for 
>"handling" the error, and a second line for returning it (or a modified / 
>wrapped version of it). With two additional vertical lines of boilerplate, 
>that's either a 100% or 200% increase in vertical space (the "if" 
>statement, and the closing brace). This limits the amount of code that can 
>fit on my screen, which constrains my ability to comprehend larger 
>functions.
>- Verbosity: The moment we're know we're checking for errors, the "if 
>err != nil {", the 

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

[Eric S. Raymond]

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 where you get to
> express more about the life-cycle of these objects should perform better. I
> say this as someone that knows very little about Rust, so I'm probably
> greatly oversimplifying.

I had a good hard swing at learning Rust, and I don't think you are
oversimplifying at all. It's a better fit for that deployment, no question,
and nothing in that article surprised me even a little.

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 having GC moves from bein convenient to an essential tool
for holding dowb your defect rate.

Different jobs, different tools. Engineering is like that.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20200208064449.GA130072%40thyrsus.com.

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

['Eric Johnson' via golang-nuts]

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 set breakpoints on the error case
   - Code coverage of unit tests reports when the error case has been 
   exercised.
   - It has the full flexibility of identifying the failure scenario, not 
   limited to err != nil (although that is the overwhelming use)
   - It has the full power and flexibility of the language for handling the 
   error - it can be logged, returned, recovered from, sent to a channel, etc.
   - If wrapping my error extends to multiple lines (due to longer 
   messages, number of parameters in the error, etc., that works using 
   existing language constructs.
   - It supports arbitrary return statement complexity, including multiple 
   return values.
   - It is straightforward to parse / analyze.

That said, it has some drawbacks, particularly in the most common cases.

   - Vertical space: Even in complex cases, the error handling inside the 
   "if" block can be reduced to at most two statements. One line for 
   "handling" the error, and a second line for returning it (or a modified / 
   wrapped version of it). With two additional vertical lines of boilerplate, 
   that's either a 100% or 200% increase in vertical space (the "if" 
   statement, and the closing brace). This limits the amount of code that can 
   fit on my screen, which constrains my ability to comprehend larger 
   functions.
   - Verbosity: The moment we're know we're checking for errors, the "if 
   err != nil {", the "return", and the "}" are usually just extra syntax.
   - Scanning complexity: What if the check is not err != nil, but err != 
   NotFound? Is this an error case, or an expected case? The current construct 
   hides that distinction. We have to look to the next line to see how it is 
   handled to know that it is an error return.
   - When there are multiple returns on a function, the error handling must 
   specify them all, even though the common case is to return a "zero" value.

For language design purposes, the most common scenario for handling an 
error is a single-line error return. When it comes to error handling, there 
are two paths to choosing a new solution:

   - Identify a solution that captures the 80-90% case of if err != nil { 
   return ... }
   - Identify a solution that can be used for *all* error handling, where 
   the existing if err != nil then becomes a legacy code base choice, because 
   it does not use the new construct which more clearly conveys "error 
   handling here".

For the benefit of the language, I would prefer a solution that fits the 
second category, not one that fits the first category. Due to the fact that 
this proposed solution does not address the arbitrary response complexity, 
it seems like it fits the first category. If there's a way to tweak the 
proposal so that it can be used for *every* error handling case, then that 
would be better.

Go has a long history of implementing orthogonal solutions that happen to 
combine well. It is possible that error handling is one of those places 
that could benefit from teasing this question apart a little more.

Eric


On Thursday, February 6, 2020 at 7:28:24 PM UTC-8, addi...@gmail.com wrote:
>
> Error checking in Go: The try keyword.
>
> This isn’t a complete proposal it only describes basic idea and the 
> changes suggested.
> The following are modifications that deals with some of the problems 
> introduced in the original proposal 
> 
> .
>
> (I apologize if something very similar that uses a simple method to deal 
> with adding context has been posted before but I could not find it.)
>
> First, try is a keyword not a function builtin.
>
> Here’s how error handling with the try keyword works:
>
> try err
>
> is equivalent to:
>
> if err != nil {
> return err
> } 
>
> That’s it.
>
> Example:
>
> f, err := os.Open("file.dat")
> try err
> defer f.Close()
>
> f.WriteString("...")
>
> But, how to add context to errors?
>
>  because try only returns if err != nil.
> You can create a function that returns nil if an error is nil.
>
> In fact, a function like this already exists in the errors package here.
> https://github.com/pkg/errors/blob/master/errors.go
>
> // Wrap returns an error annotating err with a stack trace
> // at the point Wrap is called, and the supplied message.
> // If err is nil, Wrap returns nil.
> func Wrap(err error, message string) error {
> if err == nil {
> return nil
> }
> err = {
> cause: err,
> msg:   message,
> }
> return {
> err,
> callers(),
> }
> }
>
> Example using it with try
>
> f, err := os.Open("file.dat")
> try errors.Wrap(err, "couldn't open 

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

[Robert Engels]

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

It can also be attributed to more underlying lock contention -causing 
deschedules - which would be a bad thing. 

> On Feb 7, 2020, at 5:30 PM, Ian Lance Taylor  wrote:
> 
> 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 Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV2CkgiPm1%3DbWtVUA2ra71N9BkYvaAOfCACMVzALOvY2w%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/51EADAE3-8664-4C8E-AAA9-6CBB20A29BCC%40ix.netcom.com.

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

[Ian Lance Taylor]

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 Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV2CkgiPm1%3DbWtVUA2ra71N9BkYvaAOfCACMVzALOvY2w%40mail.gmail.com.

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

[Robert Engels]

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 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. 
>> 
> 
> I've been running Go, Java, C++ and Python code in wide scale production for 
> years, so have some background for comparison here. Java's garbage collector 
> is not great either. Pretty much the biggest challenge of running Java 
> services is constantly tuning JVM args to keep it from either taking down 
> your machine, or sabotaging its own performance. It's a never ending battle. 
> A non-GC language app can have a memory leak, but it's obvious, and it's a 
> bug, while with Java's GC, and to a much lesser extent Go, you can have 
> runaway memory usage which isn't necessarily the result of a bug, but a 
> language behavior. Currently, I'm predominantly running services in Java, 
> which interact with Hadoop, and Go, which make REST API's backed by databases 
> and some limited interaction with Hadoop. With the Go services, most of our 
> engineers time is spent writing the initial code and tests. With Java, most 
> of their time is spent chasing Java memory allocation issues. I think the 
> place the effort goes speaks volumes about how well the GC works in both 
> languages.
>  
 On Feb 7, 2020, at 12:57 PM, Marcin Romaszewicz  wrote:
 
>>> 
>>> 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 
>>> programmer work and performance is phenomenal, but where latency or 
>>> throughput really matter, it's still a compiled language without generic 
>>> garbage collection. I'm sure there are many things that Rust will perform 
>>> at better than Go, but that's not a statement about one language being in 
>>> any way better than the other, just different.
>>> 
 On Fri, Feb 7, 2020 at 10:40 AM Tyler Compton  wrote:
 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 
 express more about the life-cycle of these objects should perform better. 
 I say this as someone that knows very little about Rust, so I'm probably 
 greatly oversimplifying.
 
> On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
>  wrote:
> 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 is a huge 
> testament to how easy it is to write efficient programs with Rust 
> compared to the deep dive we had to do with Go."
> 
> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to golang-nuts+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com.
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lu6RNc8XssP58y3EVk8idGo%3D%3D3YdOToOVdzH--AkknGbg%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from 

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

[Marcin Romaszewicz]

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 their heap would be very long lived objects.
>
>
I've been running Go, Java, C++ and Python code in wide scale production
for years, so have some background for comparison here. Java's garbage
collector is not great either. Pretty much the biggest challenge of running
Java services is constantly tuning JVM args to keep it from either taking
down your machine, or sabotaging its own performance. It's a never ending
battle. A non-GC language app can have a memory leak, but it's obvious, and
it's a bug, while with Java's GC, and to a much lesser extent Go, you can
have runaway memory usage which isn't necessarily the result of a bug, but
a language behavior. Currently, I'm predominantly running services in Java,
which interact with Hadoop, and Go, which make REST API's backed by
databases and some limited interaction with Hadoop. With the Go services,
most of our engineers time is spent writing the initial code and tests.
With Java, most of their time is spent chasing Java memory allocation
issues. I think the place the effort goes speaks volumes about how well the
GC works in both languages.


> On Feb 7, 2020, at 12:57 PM, Marcin Romaszewicz  wrote:
>
> 
> 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
> programmer work and performance is phenomenal, but where latency or
> throughput really matter, it's still a compiled language without generic
> garbage collection. I'm sure there are many things that Rust will perform
> at better than Go, but that's not a statement about one language being in
> any way better than the other, just different.
>
> On Fri, Feb 7, 2020 at 10:40 AM Tyler Compton  wrote:
>
>> 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 express more about the life-cycle of these objects should perform
>> better. I say this as someone that knows very little about Rust, so I'm
>> probably greatly oversimplifying.
>>
>> On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
>> wrote:
>>
>>> 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 is a huge testament to
>>> how easy it is to write efficient programs with Rust compared to the deep
>>> dive we had to do with Go."
>>>
>>>
>>> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lu6RNc8XssP58y3EVk8idGo%3D%3D3YdOToOVdzH--AkknGbg%40mail.gmail.com
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

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

[Uli Kunitz]

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 receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/93dd241f-4bfa-45ba-842e-ded094867137%40googlegroups.com.

[go-nuts] Re: Dependency hierarchy in go

[kuznetsov . alexey]

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 the build 
>> additional control, allowing it to exclude specific module versions or 
>> replace others with different code, but those exclusions and replacements 
>> only apply when found in the top-level module, not when the module is a 
>> dependency in a larger build. 
>
> A module author is therefore in complete control of that module‘s build 
>> when it is the main program being built, but not in complete control of 
>> other users’ builds that depend on the module. I believe this distinction 
>> will make this proposal scale to much larger, more distributed code bases 
>> than the Bundler/Cargo/Dep approach.
>
>
>
Thank you for explaining. Looks like bad by design, since I can not create 
patched libraries. Like mine: https://gitlab.com/axet/libtorrent

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/127983cb-cbea-437d-9d54-2d1c2d729523%40googlegroups.com.

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

[Robert Engels]

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, 2020, at 12:57 PM, Marcin Romaszewicz  wrote:
> 
> 
> 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 programmer 
> work and performance is phenomenal, but where latency or throughput really 
> matter, it's still a compiled language without generic garbage collection. 
> I'm sure there are many things that Rust will perform at better than Go, but 
> that's not a statement about one language being in any way better than the 
> other, just different.
> 
>> On Fri, Feb 7, 2020 at 10:40 AM Tyler Compton  wrote:
>> 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 
>> express more about the life-cycle of these objects should perform better. I 
>> say this as someone that knows very little about Rust, so I'm probably 
>> greatly oversimplifying.
>> 
>>> On Fri, Feb 7, 2020 at 4:25 AM Everton Marques  
>>> wrote:
>>> 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 is a huge testament to 
>>> how easy it is to write efficient programs with Rust compared to the deep 
>>> dive we had to do with Go."
>>> 
>>> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lu6RNc8XssP58y3EVk8idGo%3D%3D3YdOToOVdzH--AkknGbg%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/663AB15C-61CE-4C3B-BF6A-E1F35B59809C%40ix.netcom.com.

[go-nuts] Re: Dependency hierarchy in go

[Jason Phillips]

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 
> replace others with different code, but those exclusions and replacements 
> only apply when found in the top-level module, not when the module is a 
> dependency in a larger build. 

A module author is therefore in complete control of that module‘s build 
> when it is the main program being built, but not in complete control of 
> other users’ builds that depend on the module. I believe this distinction 
> will make this proposal scale to much larger, more distributed code bases 
> than the Bundler/Cargo/Dep approach.


And from the GoWiki module page (link 

):

> replace allows the top-level module control over the exact version used 
> for a dependency 


On Friday, February 7, 2020 at 2:01:19 PM UTC-5, kuznets...@gmail.com wrote:
>
> 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?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0ede0c67-46c4-45ba-8095-74d7d08d3a16%40googlegroups.com.

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

[Klaus Post]

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%  +4.14%  (p=0.008 
n=5+5)
DecodeDigitsSpeed1e6-12   8.97ms ± 0%9.40ms ± 1%  +4.80%  (p=0.008 
n=5+5)
DecodeDigitsDefault1e4-12 93.2µs ± 0%95.0µs ± 1%  +1.97%  (p=0.008 
n=5+5)
DecodeDigitsDefault1e5-12  855µs ± 0% 882µs ± 2%  +3.15%  (p=0.008 
n=5+5)
DecodeDigitsDefault1e6-12 8.58ms ± 0%8.94ms ± 2%  +4.28%  (p=0.008 
n=5+5)
DecodeDigitsCompress1e4-1293.3µs ± 0%94.6µs ± 1%  +1.37%  (p=0.016 
n=4+5)
DecodeDigitsCompress1e5-12 976µs ± 0% 992µs ± 1%  +1.60%  (p=0.008 
n=5+5)
DecodeDigitsCompress1e6-129.85ms ± 0%9.97ms ± 1%  +1.21%  (p=0.016 
n=4+5)
DecodeTwainSpeed1e4-1293.7µs ± 0%98.0µs ± 2%  +4.60%  (p=0.008 
n=5+5)
DecodeTwainSpeed1e5-12 896µs ± 0% 902µs ± 0%  +0.68%  (p=0.008 
n=5+5)
DecodeTwainDefault1e4-12  93.0µs ± 0%95.1µs ± 1%  +2.32%  (p=0.008 
n=5+5)
DecodeTwainDefault1e5-12   832µs ± 0% 840µs ± 0%  +0.88%  (p=0.008 
n=5+5)
DecodeTwainDefault1e6-12  8.17ms ± 0%8.22ms ± 0%  +0.68%  (p=0.008 
n=5+5)
DecodeTwainCompress1e4-12 90.4µs ± 1%93.1µs ± 1%  +2.99%  (p=0.008 
n=5+5)
DecodeTwainCompress1e5-12  790µs ± 0% 802µs ± 0%  +1.55%  (p=0.008 
n=5+5)
DecodeRandomSpeed1e4-12288ns ± 2% 305ns ± 1%  +5.91%  (p=0.008 
n=5+5)
DecodeRandomSpeed1e5-12   2.30µs ± 2%2.24µs ± 1%  -2.40%  (p=0.008 
n=5+5)
_tokens_EstimatedBits-12   651ns ± 0% 707ns ± 2%  +8.67%  (p=0.008 
n=5+5)
EncodeDigitsConstant1e4-1228.4µs ± 0%29.4µs ± 0%  +3.41%  (p=0.016 
n=5+4)
EncodeDigitsConstant1e5-12 307µs ± 0% 314µs ± 2%  +2.41%  (p=0.008 
n=5+5)
EncodeDigitsConstant1e6-122.70ms ± 0%2.77ms ± 1%  +2.47%  (p=0.008 
n=5+5)
EncodeDigitsSpeed1e5-12966µs ± 0% 988µs ± 0%  +2.34%  (p=0.008 
n=5+5)
EncodeDigitsSpeed1e6-12   9.07ms ± 1%9.22ms ± 1%  +1.67%  (p=0.032 
n=5+5)
EncodeDigitsDefault1e5-12 1.63ms ± 0%1.65ms ± 1%  +1.17%  (p=0.008 
n=5+5)
EncodeDigitsCompress1e5-123.70ms ± 1%3.64ms ± 1%  -1.65%  (p=0.008 
n=5+5)
EncodeDigitsCompress1e6-1240.1ms ± 0%39.4ms ± 2%  -1.61%  (p=0.008 
n=5+5)
EncodeDigitsSL1e5-12   955µs ± 0% 992µs ± 1%  +3.79%  (p=0.008 
n=5+5)
EncodeDigitsSL1e6-12  9.34ms ± 0%9.99ms ± 1%  +6.92%  (p=0.008 
n=5+5)
EncodeTwainConstant1e4-12 37.6µs ± 2%38.9µs ± 2%  +3.51%  (p=0.008 
n=5+5)
EncodeTwainConstant1e5-12  337µs ± 0% 345µs ± 1%  +2.38%  (p=0.008 
n=5+5)
EncodeTwainSpeed1e4-12 101µs ± 0% 102µs ± 0%  +0.62%  (p=0.024 
n=5+5)
EncodeTwainSpeed1e5-12 955µs ± 0% 968µs ± 1%  +1.35%  (p=0.008 
n=5+5)
EncodeTwainSpeed1e6-128.92ms ± 1%9.09ms ± 1%  +1.94%  (p=0.032 
n=5+5)
EncodeTwainDefault1e4-12   152µs ± 1% 160µs ± 1%  +4.69%  (p=0.008 
n=5+5)
EncodeTwainDefault1e5-12  1.44ms ± 1%1.49ms ± 1%  +3.69%  (p=0.008 
n=5+5)
EncodeTwainDefault1e6-12  13.7ms ± 1%14.2ms ± 2%  +3.43%  (p=0.008 
n=5+5)
EncodeTwainCompress1e4-12  267µs ± 1% 272µs ± 2%  +1.97%  (p=0.008 
n=5+5)
EncodeTwainCompress1e5-12 4.76ms ± 0%4.81ms ± 0%  +1.11%  (p=0.008 
n=5+5)
EncodeTwainCompress1e6-12 52.4ms ± 0%53.0ms ± 1%  +1.04%  (p=0.008 
n=5+5)
EncodeTwainSL1e4-12101µs ± 1% 105µs ± 1%  +4.48%  (p=0.008 
n=5+5)
EncodeTwainSL1e5-12925µs ± 1% 949µs ± 1%  +2.59%  (p=0.008 
n=5+5)
EncodeTwainSL1e6-12   8.86ms ± 1%9.24ms ± 0%  +4.28%  (p=0.008 
n=5+5)

`_tokens_EstimatedBits` is a microbenchmark and will probably be easier to 
identify. I will add an issue for that.

Running benchmarks on my zstd package gives a less clear, but still 
trending towards a performance loss:

nameold time/opnew time/op
delta
Decoder_DecoderSmall/kppkn.gtb.zst-12 5.76ms ± 1%5.87ms ± 2%  
 +1.98%  (p=0.016 n=5+5)
Decoder_DecoderSmall/geo.protodata.zst-12 1.53ms ± 0%1.62ms ± 1%  
 +5.86%  (p=0.008 n=5+5)
Decoder_DecoderSmall/plrabn12.txt.zst-12  19.1ms ± 0%18.7ms ± 1%  
 -2.25%  (p=0.008 n=5+5)
Decoder_DecoderSmall/lcet10.txt.zst-1214.4ms ± 1%13.6ms ± 0%  
 -5.65%  (p=0.008 n=5+5)
Decoder_DecoderSmall/html_x_4.zst-12  2.94ms ± 2%3.00ms ± 0%  
 +2.21%  (p=0.008 n=5+5)
Decoder_DecoderSmall/paper-100k.pdf.zst-12 473µs ± 1% 511µs ± 1%  
 +7.94%  (p=0.008 n=5+5)
Decoder_DecoderSmall/fireworks.jpeg.zst-12 485µs ± 2% 511µs ± 4%  
 +5.29%  (p=0.008 n=5+5)
Decoder_DecoderSmall/html.zst-12  1.65ms ± 1%1.71ms ± 1%  
 +4.01%  (p=0.008 n=5+5)
Decoder_DecoderSmall/comp-data.bin.zst-12  191µs ± 1% 206µs ± 1%  
 +7.70%  (p=0.008 n=5+5)
Decoder_DecodeAll/plrabn12.txt.zst-12 2.21ms ± 1%2.19ms ± 

[go-nuts] Re: Dependency hierarchy in go

[kuznetsov . alexey]

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?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d1bdf9d2-eef9-4b72-b0e0-6154398ab7d9%40googlegroups.com.

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

[Marcin Romaszewicz]

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
programmer work and performance is phenomenal, but where latency or
throughput really matter, it's still a compiled language without generic
garbage collection. I'm sure there are many things that Rust will perform
at better than Go, but that's not a statement about one language being in
any way better than the other, just different.

On Fri, Feb 7, 2020 at 10:40 AM Tyler Compton  wrote:

> 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
> express more about the life-cycle of these objects should perform better. I
> say this as someone that knows very little about Rust, so I'm probably
> greatly oversimplifying.
>
> On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
> wrote:
>
>> 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 is a huge testament to
>> how easy it is to write efficient programs with Rust compared to the deep
>> dive we had to do with Go."
>>
>>
>> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lu6RNc8XssP58y3EVk8idGo%3D%3D3YdOToOVdzH--AkknGbg%40mail.gmail.com.

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 where you get to
express more about the life-cycle of these objects should perform better. I
say this as someone that knows very little about Rust, so I'm probably
greatly oversimplifying.

On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
wrote:

> 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 is a huge testament to
> how easy it is to write efficient programs with Rust compared to the deep
> dive we had to do with Go."
>
>
> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com.

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

[Manlio Perillo]

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 to 
> how easy it is to write efficient programs with Rust compared to the deep 
> dive we had to do with Go." 
>
> This article does not tell use when the switch from Go to Rust was made. 
> But it is interesting to see that they compare the ancient Go version 1.9 
> with bleeding endge Rust. I am no expert for GC in Go but I would strongly 
> assume that since Go 1.9 much has been improved to handle situations like 
> those described in the article. 
>
>
The article also does not tell us how many years of experience with Go they 
had when they started the project.
And how many years of experience with Rust they had when they started the 
reimplementation. 

 
Manlio

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f9d9d9af-8ae8-43a8-bb62-631738725c99%40googlegroups.com.

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

[Amnon Baron Cohen]

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, 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 the deep 
> dive we had to do with Go."
>
>
> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f4481ae5-5e26-48ca-be1c-1cd1f929917f%40googlegroups.com.

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

[Lutz Horn]

> "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 the deep dive we 
> had to do with Go."

This article does not tell use when the switch from Go to Rust was made. But it 
is interesting to see that they compare the ancient Go version 1.9 with 
bleeding endge Rust. I am no expert for GC in Go but I would strongly assume 
that since Go 1.9 much has been improved to handle situations like those 
described in the article.

Lutz

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2051487124.89895.1581080343939%40webmail.strato.com.

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

[Magnus Kokk]

[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 basket" fashion. It's a 
strength of go to have such granular value and interface semantics
available for dealing with any kind of values.



reede, 7. veebruar 2020 5:28.24 UTC+2 kirjutas addi...@gmail.com:
>
>
> Example using it with try
>
> f, err := os.Open("file.dat")
> try errors.Wrap(err, "couldn't open file")
> defer f.Close()
>
> f.WriteString("...")
>
> That’s it.
>
> This should reduce repetitiveness with error handling in most cases.
>
> It is very simple to understand, and it feels like Go.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/69f5d1db-1197-4647-8131-28369f6b32e8%40googlegroups.com.

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

[Everton Marques]

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 is a huge testament to how 
easy it is to write efficient programs with Rust compared to the deep dive we 
had to do with Go."

https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com.

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

[addi t0t08]

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 than the problem they are 
> solving. For example, the proposed try works only iff you are returning a 
> single value of type error. If you have more return values what happens?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e3bb7dd9-e5a1-4b6a-b758-e0e9b4933119%40googlegroups.com.

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

[Kevin Chadwick]

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.

I worry that Go may become convoluted over time. I guess I am fairly new to Go
and with a C background but I still see methods and even error unwrapping as
needless complexity even though they are simple constructs. In C, I avoid
function pointers for security reasons and if the line isn't too long I shall
even avoid |= because it provides less clarity, so one liners with multiple
methods, irritate, rather than please me.

In Linux you have multiple bridge tools and IP tools and some say this is good
as people can choose but the older brctl with a man page that enabled me to do
what I needed quickly, is deprecated. Competition is good but it should compete
against the existing tool.

So having multiple tools might please everyone theoretically but that doesn't
mean that it isn't adding complexity or causing issues, and pointless learning
curves should carry weight in decisions.

Being able to return multiple things and an error and having the line logged for
you without even writing an error function as I would in C has been perfect and
a no-brainer.

I am just hoping that wanting to import something or using the std lib doesn't
mean you have to waste time learning another obfuscation (personally, I see
methods as unnecessary already).

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/84fd0066-550e-5d3e-193f-f9b1928e61b2%40gmail.com.

[go-nuts] Dependency hierarchy in go

[kuznetsov . alexey]

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 project wont 
compiling until I understand what is going in and manually add "replace C 
=> C1" in project A.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2ad15c09-e6f7-4475-9558-6050f978feea%40googlegroups.com.

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

[pboampong5]

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 to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7d5b40ba-c2ab-49da-a9d0-f56e5106a54b%40googlegroups.com.

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

[Henrik Johansson]

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 highlights from the release include:
>
>- support for Go 1.14
>- improved support for Go Modules
>- improved code completion, Live Templates, and Postfix templates
>- performance improvements
>
> You can find more information about our release on the dedicated blog page
> 
> .
>
> We'd like to hear your feedback on how to improve the product and deliver
> a stable and exceptional experience for Go developers.
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b08aae9f-f0ed-4af1-a59d-c941e0d36213%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKOF694Cn89xEGhN9dbDWJtV_7UVoD3sSy_Ty_x8J80GAhC%2BoQ%40mail.gmail.com.

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

[ffm2002]

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 missing 
read permissions. How do you figure that out in a elegent way without 
lengthy if-then-else blocks?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1147a5ff-a2b9-493b-9162-bea0176fb84c%40googlegroups.com.

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

[Florin Pățan]

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, and Postfix templates
   - performance improvements

You can find more information about our release on the dedicated blog page 

.

We'd like to hear your feedback on how to improve the product and deliver a 
stable and exceptional experience for Go developers.

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b08aae9f-f0ed-4af1-a59d-c941e0d36213%40googlegroups.com.

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

[Michel Levieux]

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
action, a process, a set of computations, and *those* actions, processes or
computations throw - return - something if they fail. So it makes sense in
those cases to use "try". "Trying an error", on the other hand, clearly is
just wanting to have the same keyword for the same - approximate? - purpose
(I'm not saying it's wrong or right, I'm just saying).

I know that most of the suggested keywords in proposals are not *really*
part of the proposal itself and most often are just used as a means of
showing practical examples to the reader. I'm just stating my opinion here.
Try seems a bad choice for me here because it focuses the attention on a
single - irrelevant - point where the real value of the proposal would lie
somewhere else (which does not imply that the proposal has value or it has
not, *again*, this is not my point).

Le ven. 7 févr. 2020 à 06:55, MUNGAI  a écrit :

> I agree,
> Some of the proposals introduce more trouble than the problem they are
> solving. For example, the proposed try works only iff you are returning a
> single value of type error. If you have more return values what happens?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8584ff0d-deb1-483a-b152-45639a4ce088%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANgi335%3D%2BRPOTRXAqS_CeTcCOJNAaMyUMF_8VGTsqgqLatahog%40mail.gmail.com.