Re: [go-nuts] what is the origin of Go's reference time system?

> > -rob > > > On Thu, Oct 27, 2022 at 5:15 PM Alex Besogonov <mailto:alex.besogo...@gmail.com>> wrote: >> Can we perhaps get a bit more unambiguous reference date for it? >> >> On Wednesday, October 26, 2022 at 1:06:36 PM UTC-7 Rob 'Commander' Pike >&

Re: [go-nuts] what is the origin of Go's reference time system?

Can we perhaps get a bit more unambiguous reference date for it? On Wednesday, October 26, 2022 at 1:06:36 PM UTC-7 Rob 'Commander' Pike wrote: > I believe it's unique. I thought of it one day while walking home. It is > inspired by the way Cobol picture clauses represent number formats. (That

[go-nuts] Detachable context.Context?

Hi! Let me give you some context. context.Context in Go serves two main purposes: 1. Cancellation and timeout support. 2. A carrier of values, as a de-facto replacement for thread-local variables. I have a problem with the first item. Cancellation and timeouts automatically propagate to child

Re: [go-nuts] IsNil check. How?

> The reflect code panics, because you are comparing a struct value to nil. >> Struct values can not be nil. >> >> No. I’m comparing AN INTERFACE, not a struct. >> > You are using `reflect` to inspect the dynamic value of that interface. > That dynamic value is a struct. > No. It should be a

Re: [go-nuts] IsNil check. How?

> Here's a simplified version of the real code: > https://go.dev/play/p/8LfgIGhd8GR - it > compiles without any issues. > > Yes it compiles. Plenty of buggy Go code will compile. Here is another > example of buggy

Re: [go-nuts] IsNil check. How?

On Wednesday, March 16, 2022 at 12:29:07 PM UTC-7 axel.wa...@googlemail.com wrote: > On Wed, Mar 16, 2022 at 7:02 PM Alex Besogonov > wrote: > >> Nope. Your solution doesn't work either: >> https://go.dev/play/p/DSik2kJ-gg4 (it doesn't crash, just falsely >> re

Re: [go-nuts] IsNil check. How?

e language and there's no good justification why this hasn't been yet fixed. On Wednesday, March 16, 2022 at 10:36:48 AM UTC-7 axel.wa...@googlemail.com wrote: > On Wed, Mar 16, 2022 at 6:21 PM Alex Besogonov > wrote: > >> I'm trying to solve the eternal "interface == nil" prob

[go-nuts] IsNil check. How?

Hi! I'm trying to solve the eternal "interface == nil" problem and I can't find a solution in this case: https://go.dev/play/p/DSik2kJ-gg4 It looks like casting to the base pointer type confuses the reflection package. Is there a way to solve this? PS: PLEASE do add "nilptr" to the language

[go-nuts] [ANN] Pure Go NFSv4 client

Hi! Here's my pure Go NFSv4 client. It's designed to work with Amazon EFS (Elastic FileSystem) but also can work against Linux kNFSD or Ganesha (in fact, Ganesha is used for integration testing). Enjoy: https://github.com/Cyberax/go-nfs-client -- You received this message because you are

[go-nuts] Re: Profiling goroutines

Use pprof labels to mark goroutines. This provides way more context than anonymous goroutine IDs. On Friday, September 3, 2021 at 1:19:55 PM UTC-7 peppy...@gmail.com wrote: > Hey guys, > > I am trying to get a full picture using a pprof of a highly paralelised > binary (read many goroutines

[go-nuts] Re: Setting the Don't Fragment (DF) bit on OSX

DF bit is needed to discover the MTU on the application level, exactly because MTU discovery can be broken on lower levels of the network stack. QUIC specifies this procedure here: https://tools.ietf.org/html/draft-ietf-quic-transport-05#page-53 On Saturday, April 24, 2021 at 1:37:26 PM UTC-7

Re: [go-nuts] Generics, please go away!

> On Dec 31, 2020, at 15:10, Axel Wagner wrote: > > On Thu, Dec 31, 2020 at 9:27 PM Alex Besogonov <mailto:alex.besogo...@gmail.com>> wrote: > Moreover, Go has inheritance as well (struct embedding and interface > inheritance), making it a fairly typical example. >

[go-nuts] Re: Generics - please provide real life problems

On Wednesday, December 23, 2020 at 10:16:00 PM UTC-8 Martin Hanson wrote: > If all we're presented are these small theoretical examples of sorting > lists, etc., then clearly this is nothing but hype that needs to go > away. > My personal example: ordered containers. My code works with

[go-nuts] Re: Generics, please go away!

at 4:27:15 AM UTC-8 Space A. wrote: >> >>> Go doesn't have classes and is not an OOP language. >>> >>> Classes (like in Java) vs structs (like in Go) is about inheritance vs >>> composition, not about attaching fields and methods. Inheritance implies >>> t

[go-nuts] Re: Generics, please go away!

Please, stop being so condescending to newcomers and non-professional developers. Generics as uses by end-users will improve their experience, not make it harder. (And what is this obsession with "classes"? Go has them - structs with methods are classes). On Tuesday, December 29, 2020 at

[go-nuts] Re: Generics, please go away!

On Sunday, December 20, 2020 at 11:38:54 AM UTC-8 Martin Hanson wrote: > I think people who want generics added to Go should go and program in Java > or C++. > Perhaps you should switch to Python if you don't want generics? > Adding generics to Go will ruin the beautiful simplicity of the

Re: [go-nuts] global goroutine data / thread local storage?

On Saturday, September 26, 2020 at 12:34:37 PM UTC-7 Ian Lance Taylor wrote: > > A Go-style goroutine-local system can be thought as a context.Context > that is transparently assigned to a goroutine and its children. Thus if you > want to change the value, you'd do something like "c := >

Re: [go-nuts] global goroutine data / thread local storage?

On Saturday, September 26, 2020 at 12:33:40 PM UTC-7 Ian Lance Taylor wrote: > On Fri, Sep 25, 2020 at 6:29 PM Alex Besogonov > wrote: > > If you mutate the value, then only the current goroutine is affected > (not even its existing children). Basically, the goroutin

Re: [go-nuts] global goroutine data / thread local storage?

On Saturday, September 26, 2020 at 5:41:54 AM UTC-7 rog wrote: > A Go-style goroutine-local system can be thought as a context.Context that >> is transparently assigned to a goroutine and its children. Thus if you want >> to change the value, you'd do something like "c := >>

Re: [go-nuts] global goroutine data / thread local storage?

On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote: > On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov > wrote: > > > > Inheritable goroutine-locals would actually work just fine in Go. > Moreover, Go actually has them in the form of pprof labels.

Re: [go-nuts] global goroutine data / thread local storage?

: > On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov > wrote: > > > > Inheritable goroutine-locals would actually work just fine in Go. > Moreover, Go actually has them in the form of pprof labels. > > What should happen if one goroutine changes an inherited > gor

Re: [go-nuts] global goroutine data / thread local storage?

Inheritable goroutine-locals would actually work just fine in Go. Moreover, Go actually has them in the form of pprof labels. On Wednesday, September 23, 2020 at 5:55:50 PM UTC-7 Ian Lance Taylor wrote: > On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wrote: > > > > There appears to be a way to

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

Can we at least move with the https://github.com/golang/go/issues/22729 , please? Anything will help with the current mess. On Sunday, August 23, 2020 at 8:52:30 PM UTC-7, Ian Lance Taylor wrote: > > On Sun, Aug 23, 2020 at 1:16 PM Denis Cheremisov > > wrote: > > > > You may use something

[go-nuts] Re: Dynamic include path in cgo?

On Sunday, August 9, 2020 at 9:56:43 AM UTC-7, Miki Tebeka wrote: > > Is there a way to pass include path dynamically to cgo? > The easiest way is to generate the include file and just reference it from cgo. It looks like your code needs to have a Makefile anyway. -- You received this message

Re: [go-nuts] Go without garbage collector

No, you do not. In C++ you would put object values in the vector, rather than pointers to objects. > On Feb 14, 2020, at 08:57, Robert Engels wrote: > > If you have a container of objects, you still need to free each object. If it > is an "container" of value objects (one reference to a block

Re: [go-nuts] Go without garbage collector

bit, and some more research would be helpful. > > -Original Message- > From: Alex Besogonov > Sent: Feb 13, 2020 12:18 PM > To: Robert Engels > Cc: golang-nuts > Subject: Re: [go-nuts] Go without garbage collector > > No. It doesn’t prove anything. The C++ code is

Re: [go-nuts] Go without garbage collector

No. It doesn’t prove anything. The C++ code is badly written, as it creates completely superfluous objects (probably optimized away) and does an indirect lookup (which will NOT be). This needs to be fixed even if the code is a faithful translation of Java code. So in practice all the supposed

Re: [go-nuts] Go without garbage collector

I actually remember another actual example of a code that does non-trivial work and is written in multiple languages: https://github.com/ixy-languages/ixy-languages It's pretty clear that C or Rust still easily beat any GC-based language. Go and C# come close because the code for the driver

Re: [go-nuts] Go without garbage collector

The evidence is very disputable. For example, I don't know who was writing your paper, but they were NOT expert C++ programmers. As an example: > for (MaoCFG::NodeMap::iterator bb_iter = CFG_->GetBasicBlocks()->begin(); > bb_iter != CFG_->GetBasicBlocks()->end(); ++bb_iter) { >

Re: [go-nuts] Go without garbage collector

I understand how Zing works quite well, thank you. And no, it's still horrible. "Longer pauses in malloc" are fairy tales for children. No real allocator these days (including the slow glibc allocator) gets "fragmented". On Wednesday, February 12, 2020 at 8:18:34 PM UTC-8, robert engels wrote:

Re: [go-nuts] Go without garbage collector

Nope. G1GC actually dates back to 2004 (see doi 10.1.1.63.6386) with Metronome even earlier (2002, I think). Zing has actually even less throughput than the good old CMS and way more memory overhead on massively-parallel systems. However, it does guarantee realtime performance that is

Re: [go-nuts] Go without garbage collector

Honestly, typical Go programs don't use that many complicated concurrent primitives. Typical patterns are "work fanout" and "overseer thread", both of which have very simple lifetime rules. That's why a lot of typical server Go code can be ported to Rust rather easily. On Wednesday, February

Re: [go-nuts] Go without garbage collector

I'm very familiar with this paper. It's not the first one that uses oracular memory management for comparison, the earlier one used ML as its langauge. The problem with these papers is that they're using very artificial benchmarks, not really representative of real workloads. They additionally

Re: [go-nuts] Go without garbage collector

Actually, it was not proven. And in practice manual memory management seems to be outperforming GC in majority of cases. On Tuesday, February 11, 2020 at 5:59:26 PM UTC-8, robert engels wrote: > > It’s been PROVEN that GC outperforms all manual memory management except > in EXTREMELY isolated

Re: [go-nuts] Golang library for - ORM & Schema Migration

First, nobody thinks that knowing ORM's query language absolves one from knowing SQL. But the main issue is that Go SQL interface SUCKS. It's verbose, hard to use and is difficult to integrate with additional tooling (try adding generic tracing support, I dare you!). So often your SQL code is

Re: [go-nuts] what is the use of context in golang RESTful apis?

On Wednesday, January 16, 2019 at 1:33:57 PM UTC-8, Ian Lance Taylor wrote: > In particular everybody understands that the new thread will not have > access to any of the thread local > variables of the parent thread. > To be fair, Java does have InheritableThreadLocal variables that are

Re: [go-nuts] what is the use of context in golang RESTful apis?

No. Just no. TLS is just another form of global variables and suffers from the same problems. I.e. the "magic action at a distance" - it's impossible to understand what changes it without checking the whole program. In particular, transactions, current users and other crap should NEVER go

Re: [go-nuts] what is the use of context in golang RESTful apis?

TLS most certainly does not make stuff easier. It just obscures it. The decision to remove TLS from Go was right. Explicit is better than implicit, even if it does make logging quite a bit clumsier. That being said, Context API could use a re-design. On Monday, January 14, 2019 at 7:37:25 AM

Re: [go-nuts] Code coverage for a project

I actually have a similar request. I have an application that I want to test with integration tests and right now there's no real way to get coverage except by running everything using a unit test launcher. On Wednesday, January 9, 2019 at 6:22:23 AM UTC-8, Ian Lance Taylor wrote: > > On Tue,

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

Please note, that the FAQ doesn't really apply to my proposal. If you can set a name but not read it (without resorting to stack trace parsing or CGO) then you can't use it to create implicit thread-local contexts. On Sunday, November 25, 2018 at 4:17:28 PM UTC-8, Bruno Albuquerque wrote: > >

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

Debugging. For example, if I have a deadlocked request I might want to attach with a debugger and find where exactly it's stuck. Right now this is complicated, you have to examine stacks of all goroutines to find the correct one. On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

For example, you might want to annotate the goroutine with a request ID. On Friday, November 23, 2018 at 1:07:49 AM UTC-8, Jan Mercl wrote: > > On Fri, Nov 23, 2018 at 8:53 AM > > wrote: > > > That won't work if you want to create the name dynamically. > > Please explain what "to create the

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

That won't work if you want to create the name dynamically. It's also not very useful if you're in a debugger and want to navigate to a different goroutine. I'm actually thinking about writing an RFC for a SetGoroutineName function to allow to customize the name. It will be strictly accessible

[go-nuts] Re: [Proposal] Goroutine Scoped Context

Historically Go developers resist any attempts to add goroutine-local storage. Unless they change their opinion, this proposal is DOA. -- 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