Re: [go-nuts] Draining http response bodies
On Oct 7, 2021, at 3:36 AM, Amnon wrote: > > Is it necessary for a http client to fully read the http response body? > > Opinion on the Go forums seems divided > https://forum.golangbridge.org/t/do-i-need-to-read-the-body-before-close-it/5594 > > But a simple benchmark https://play.golang.org/p/5JDWYbRe0lD > suggests that leaving unread data in the response body will prevent > the connection being reused, and much slower performance. > > The documentation https://pkg.go.dev/net/http states: > "The client must close the response body when finished with it:" > > The following example does include a call to io.ReadAll(resp.Body) > but it does not spell out whether there would be a performance penalty > for failing to read the entire body. > > It would be good if the standard library documentation was a bit more > explicit here. I suspect a lot of this actually comes down to operating system level handling of TCP sockets, which is something that it would be hard for the docs to address other than maybe offering a warning that your OS *might* not release the port for reuse if the body isn't fully drained. I could be wrong, though, there's half a chance it's really a GC thing instead. I'd have to look at the source to be sure. - Dave -- 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/03EA0EA9-45BA-454E-B991-9AF8FFC84111%40gmail.com.
Re: [go-nuts] Re: Makefiles for Go Programs
On Aug 23, 2021, at 12:48, Roland Müller wrote: > > What are the alternatives to Makefile that are used by Go developers? Please > comment :-) Well, there’s mage, which aims to more or less replace the functionality of Make for Go. I’m not really sold on *needing* a replacement for Make, and if you’re doing CI builds, it still adds an external dependency, but it is an interesting project: https://magefile.org/ > I know Make from old C/C++ times. Therefore, my picture is that it is not > very portable and requires for quite many operations the usage of external > tools that again differ between the platforms. Basically Makefiles are > somehow enhanced shell scripts (Linux/Unix) or batch files (Windows). Makefiles are quite portable, at least assuming you’re using GNU Make (which is at least available nearly everywhere). It may not be the most ideal option with Windows, but nearly everywhere else it’s pretty solid. If you have problems with external tools behaving differently across platforms (the behavior of “which” on Solaris vs. Linux or BSD being a particular sticking point I’ve run across in scripts), I would argue that there’s not much out there that’s going to solve that problem. > Currently, at work I deal a lot with Maven, that is a bit too Java -oriented > in spite of being capable in principle to build and compile other things too. > Another, issue is the XML syntax that's makes editing without tool support > very hard. Most of the newer build tools like Maven, Gradle and Bazel seem to be more oriented towards either IDEs or large-scale projects. Make scales quite nicely to small, and moderately well to large. Recursive builds tend to be a problem, but fortunately with Go, you don’t tend to need those. I would say Go tooling goes along rather well with Make if you’re following the semi-canonical repo structure, because you can tell Go to just build a list of executables from the ./cmd directory and the build tool takes care of caching, figuring out dependencies, etc. Not much in the way of portability issues there. > Gradle would be another candidate. I am just began to explore it. It's a bit > like Maven with human syntax, but lacks again on lifecycle support that I > like with Maven. I feel like Gradle is another very Java-oriented tool, and as a consequence seems to have inherited the very Byzantine nature of nearly every other Java ecosystem tool. I haven’t tried to use it for non-Java stuff, but I wouldn’t, personally. Not least because in a CI environment, I tend to try to stick to things either native to the language I’m using (so, the native Go build tools, *maybe* mage), or things present or easily installed in the host Docker image (both Bourne shell and Make fit this bill nicely). The other benefit here is that in the projects I work on for work, not everyone wants to use Make (some folks have a pathological aversion to it), but it’s easy for us to make sure that Make is only ever a convenience method for things that can otherwise be easily done from the command-line (e.g. “go test ./…”). Make then becomes a) a convenience for running basic things (e.g. make test, make cover, make docker-test-race, that sort of thing) and b) a method for making sure our developers are running the same commands locally that the CI process does (don’t underestimate the importance of that for avoiding difficult-to-diagnose problems). It’s also nothing you can’t do with plain shell scripts, but you’ll find yourself reinventing a lot of things that Make does for you quite nicely out of the box, like default parameters, list handling, target dependencies, etc. - Dave -- 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/6FC5892A-BB6A-4A59-93CC-942C2AA5105F%40gmail.com.
Re: [go-nuts] Makefiles for Go Programs
On Aug 22, 2021, at 23:11, jlfo...@berkeley.edu wrote: > > > I've noticed that few, if any, Go programs use Makefiles. Is that because the > overhead of using make is greater than the overhead of just always compiling > and linking everything? > One piece of evidence for this is that the Go compiler leaves no artifacts, > like object files, so as is make wouldn't fit into the current build method. I use Makefiles in our own internal projects because it allows me to establish a lot of good tooling around them, especially for repos which build a lot of binaries, Dockerize them, etc. It’s quite useful, despite the lack of intermediate files which Make tends to rely on to determine whether to rebuild things. Among other things, Make deals a lot better with lists of files and the concept of prerequisite steps than e.g. Bourne shell, and the Make package is actually considerably smaller than Bash in most tiny distros like Alpine, which is a consideration for Dockerfiles. Unfortunately, to make Make worth the effort in Go projects, you need to understand it, otherwise you’ll just wind up with a lot of independent targets with a lot of repetitive code. Many developers these days (especially newer ones) have never been exposed to Make other than just running it and aren’t aware of what it can do, and so tend not to understand why you might not use it instead of e.g. Bash (they also tend not to understand why it might not be a good idea to use Bashisms instead of vanilla Bourne shell, but that’s a conversation for another time). Basically, Make can make your Go projects a lot more intuitive to build, especially when it comes to things like default flags and consistency with CI, but you do have to put some effort into it, and you have to get people over the “Make is hard” mindset or they will “fix” your project by getting rid of it, IME. FWIW, our default “make test” target generally just does “go test -race ./…”, with some optional coverage arguments spliced in when you “make cover”. “make cover-report” is where Make starts to shine; there’s a file prerequisite rule defined for the coverage file as well as for the HTML coverage report, and “make cover-report” just says to build the report file and Make’s dependency resolution magically takes care of the rest. It’s actually a pretty good basic demonstration of capabilities that used to be considered standard knowledge. - Dave -- 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/052168C4-EFE0-49AA-AEDC-8B3557025C81%40gmail.com.
Re: [go-nuts] Why isn't go more popular?
On Aug 5, 2021, at 10:27 PM, Ian Lance Taylor wrote: > > On Thu, Aug 5, 2021 at 7:20 PM Santi Ferra > wrote: >> >> When you see the ranking of the most liked programming languages, go is near >> c++, a really "hated app". But since is efficient and produces really clean >> code, why no wants like it ? > > What rankings are you looking at? Seconded. I would question those rankings, at least for code that's used for forward-looking purposes; in my experience, Go is rapidly replacing Java and in a number of cases Python for backend applications, and it has a lot of first-party support for things like API clients, telemetry, etc. that comes before those languages in many cases as well. I feel like most people who dislike Go generally haven't used it. Having used it quite a bit, there are things I don't like a lot about it, but they're things that I feel like I can easily overlook given all the things it improves for me. Those are the things people who haven't really given it much use tend to seize on, in my experience (e.g. "Go doesn't have generics", "Go doesn't really have a good way to make an iterator", etc.). Rankings aren't generally very useful because they try to turn a massive vector quantity into a scalar for everyone's purposes, when in reality different people put different weights on things. It's much more likely that you're seeing the effects of "which language is most used", and Go is a lot younger than most of the other languages in those rankings. - Dave -- 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/92091078-2F36-4606-B3ED-BBA74957E17B%40gmail.com.
Re: [go-nuts] Go and GPUs
On Jun 25, 2021, at 10:23 PM, Robert Engels wrote: > > There is also a LOT of support for Java and CUDA/OpenCL. You can essentially > reimplement them Java portion in Go. There are multiple open source projects > in this area. > > Might be a lot easier than starting from scratch. Yes, CGo is going to be similar to JNI in this context. - Dave -- 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/70F2856D-0640-490F-BFAC-366A17A991AD%40gmail.com.
Re: [go-nuts] Go and GPUs
On Jun 25, 2021, at 1:32 PM, Robert Engels wrote: > > Why not develop a Go <> CUDA binding using CGo? This (ditto for OpenCL, Vulkan, etc) is more likely the path you'll have to go down. Generally all of these interfaces rely on pretty massive libraries from NVIDIA, AMD, Intel, etc. which are only going to have a C ABI because basically every other language on the planet uses the C ABI (with exceptions for interpreted languages like Java or Pythons, which contain adaptations like JNI to the C ABI, whose purpose is fulfilled by CGo here). You're not going to get a non-CGo interface to any mainstream GPU programming interface unless you happen to have enough money to convince Intel, AMD and NVIDIA to go to the trouble of writing them, at which point you will also be involving massive industry committees. You don't want that. CGo is an acceptable tradeoff here, IMO, because the overhead of bus transactions to the GPU is likely to be much worse than any overhead CGo adds unless you're doing something terribly wrong. You want large, infrequent transactions that you can queue up, otherwise you'll eat up all your time waiting for transactions anyway. Consider that plenty of high performance GPU computation is done using plain Python interfaced to CUDA. The interface to the library isn't what matters, it's what you do with it. These interfaces already exist in various states of maintenance, FWIW: https://github.com/gorgonia/cu (last updated a year or so ago) https://github.com/rafaelescrich/cuda-go (last updated about half a year ago) - Dave -- 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/7786F4DE-CF75-471B-9709-EE1C9A4DAF1D%40gmail.com.
Re: [go-nuts] Golang language specification Document: Composite Literals example is not understandable
On Jun 22, 2021, at 12:42, Axel Wagner wrote: > > > Oh and also: > >> Likewise, I think this only works for array literals; I don’t think (though >> again have not tried it) that you can declare slice literals with only >> selected members initialized. > > Works fine too: https://play.golang.org/p/ANw54ShkTvY :) Yeah, I re-read the doc and realized my assumption was erroneous shortly after I sent the last one… this is why I put the disclaimer on things I have not tried yet. :-) - Dave -- 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/C0E9CFB3-0B02-49A8-8EE0-8CB9CA19681E%40gmail.com.
Re: [go-nuts] Golang language specification Document: Composite Literals example is not understandable
On Jun 22, 2021, at 11:39, Vaibhav Maurya wrote:
>
> Hi,
>
> Please help me to understand the following syntax mentioned in the Golang
> language specification document.
>
> https://golang.org/ref/spec#Composite_literals
>
> following is the search string for CTRL + F
> // vowels[ch] is true if ch is a vowel \
>
> Following declaration and initialization is confusing.
> vowels := [128]bool{'a': true, 'e': true, 'i': true, 'o': true, 'u': true,
> 'y': true}
>
> Here one can see the vowels is an array. Where in the array initialization
> syntax, there is a key value pair. I believe bool is the primitive type, so
> the array values should be either true or false.
> Why there are key value pair separated by colon in the initialization.
In this case, it is because the single quotes create a literal rune, which
ultimately is an integer; this is creating an array 128 wide of bools, of which
only the values indexed by those character values are initialized (everything
else is the zero value, or false).
This example only works for characters in the 7-bit ASCII subset of UTF-8; if
you were to put other characters in which had rune values greater than 127,
this would break (I assume with a runtime rather than a compiler error, but I
haven’t tried it). Likewise, I think this only works for array literals; I
don’t think (though again have not tried it) that you can declare slice
literals with only selected members initialized.
- Dave
--
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/2564C639-E055-4DD9-97A2-9B6061F83006%40gmail.com.
Re: [go-nuts] Go: pointer bit stealing technique
On May 6, 2021, at 7:16 AM, Vitaly Isaev wrote: > > There is no similar type in C/C++/Go stdlib, but at least in C++ it's > possible to model it using bit stealing approach (see C++ example). On x86_64 > arch only 48 bits of 64 bits are actually used, so one can store arbitrary > data in the remaining 16 bits, and work with the whole pointer and the data > atomically. I would strongly recommend that you not do this, because this has a nasty way of breaking a LOT of things in the future. The original Macintosh system software and ROMs used this "clever" technique almost exactly, because the 68000 only had a 24-bit address bus. When the 68020 came out and people wanted to use more than 16 MB of address space, it created BIG problems which took many years to resolve (and many things were not completely resolved until Apple moved to the PowerPC). History is littered with examples of why you should not do naughty things with "unused" pointer bits (see also ARM's Thumb instruction set, which used the unused LSB of the instruction counter to signify Thumb mode, causing headaches for compiler, debugger and disassembler writers to this day). - Dave -- 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/CAF81D0A-9AD0-4412-9013-76FEB6C13C27%40gmail.com.
Re: [go-nuts] Go Create
On Jan 12, 2021, at 5:40 AM, Kevin Chadwick wrote: > > On 1/12/21 9:43 AM, Axel Wagner wrote: >> git init >> go mod init >> >> I guess you *could* safe the `git init` part, but is that really worth the >> added >> complexity? > > > I usually init git from within vscode afterwards. I wonder if doing it pre > would > save me any trouble. > > AFAICT go mod init works great, if you use remote git. > > If you work locally then you have to manually edit the .mod files. For me > with a > replace directive to bring in general libraries. That is the likely scenario > of > a new user. I have noticed that GoPATH is more prominent again in the docs. Truthfully, "git init" isn't required at all if you're not going to share. You can name your module whatever you want in go.mod and as long as you're consistent with it elsewhere in your local project, it works fine. I understand the need for the domain as part of the module namespacing, but it does make a certain assumption that all of these things are going to be on resolvable domains, which isn't true for everyone. This is particularly a hassle when building with additional local resources so that you can test new library changes without having to do a full push to a remote git server, update go.sum, etc. And I've still got a bit of a bee in my bonnet about the lack of workable relative imports, but I'm not interested in relitigating that right now. What I wonder might be useful is if go.[mod,sum] were able to pick up additional local overrides (e.g. a go.mod.local file to do the replace directives to point to local variants, with go.sum.local taking the corresponding changes so they don't wind up in go.sum). We've run into this problem quite a bit at work where people point at their local workspaces and then accidentally commit the modified go.mod (often when they've made an actual change to go.mod that needs to be committed and they forget to temporarily remove it). That way, go.mod.local would be easy enough to add to .gitignore, .dockerignore, etc. so that it doesn't escape into the wild. - Dave -- 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/7AF6EBB3-7E69-4180-BF2C-8E2C7446D4E8%40gmail.com.
Re: [go-nuts] Advice, please
This particular problem is akin to the way GPUs work; in GPU computing, you generally marshal all your inputs into one buffer and have the outputs from a single kernel written to an output buffer (obviously there can be more on either side). The execution overhead of a single invocation is large, so batching things up to run massively in parallel in one run is essential. On a CPU, you'll also get benefits from this sort of arrangement due to things such as data locality (for caching purposes) and reduced IPC overhead. Barriers can be reasonably simple to implement, depending on your use case (this may not describe yours); thinking about an event-driven simulator such as a VHDL/Verilog simulator, pushing your new events keyed by their scheduled time into a priority queue (generally a heap, so O(log(n)) time per insertion) and popping them (pre-execution) into your batch per time slice until you've reached the end of a given time slice (assuming events cannot push back into their own timeslice, which is usually bad behavior anyway) will let you simulate one "clock" at a time without having to worry about the actual clock, and will also let you simulate things like propagation delay without having to do weird special-casing for that sort of thing. In any case, this approach doesn't require barriers so much as just managing work batches. And, using this approach, if you ever do decide to do computation on something like OpenCL, you'll be lined up to process it that way. - Dave > On Jan 17, 2021, at 10:11 AM, Pete Wilson wrote: > > The problem is that N or so channel communications twice per simulated clock > seems to take much longer than the time spent doing useful work. > > go isn’t designed for this sort of work, so it’s not a complaint to note it’s > not as good as I’d like it to be. But the other problem is that processors > are still architected as if most code is sequential and synchronisations (and > communications) are extremely rare and so no problem if they’re as slow as > molasses (which atomic operations are) > > Your description is basically what I’m trying to do, except that I’m using > local storage rather than the array elements. It’s not clear that exchanging > array pointers is any quicker than having a 2-phase loop; the problem is > still the barriers. > > P > > >> On Jan 16, 2021, at 11:14 PM, Bakul Shah wrote: >> >> You may be better off maintaining two state *arrays*: one that has the >> current values as input and one for writing the computed outputs. At >> "negtive" clock edge you swap the arrays. Since the input array is never >> modified during the half clock cycle when you compute, you can divide it up >> in N concurrent computations, provided a given output cell is written by >> just one thread. So theen the synchronization point is when all the threads >> are done with they computing. That is when you swap I/O state arrays, >> advance the clock and unblock all the threads to compute again. You can do >> this with N+1 channels. The tricky part may be in partitioning the >> computation in more or less equal N parts. >> > > > > WARNING / LEGAL TEXT: This message is intended only for the use of the > individual or entity to which it is addressed and may contain information > which is privileged, confidential, proprietary, or exempt from disclosure > under applicable law. If you are not the intended recipient or the person > responsible for delivering the message to the intended recipient, you are > strictly prohibited from disclosing, distributing, copying, or in any way > using this message. If you have received this communication in error, please > notify the sender and destroy and delete any copies you may have received. > > http://www.bsc.es/disclaimer > > > > > > > WARNING / LEGAL TEXT: This message is intended only for the use of the > individual or entity to which it is addressed and may contain information > which is privileged, confidential, proprietary, or exempt from disclosure > under applicable law. If you are not the intended recipient or the person > responsible for delivering the message to the intended recipient, you are > strictly prohibited from disclosing, distributing, copying, or in any way > using this message. If you have received this communication in error, please > notify the sender and destroy and delete any copies you may have received. > > http://www.bsc.es/disclaimer > > -- > 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/FE3D2098-6E4A-4A84-BF9B-2CA04B343AA6%40bsc.es. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and st
Re: [go-nuts] Advice, please
On Jan 13, 2021, at 7:21 PM, Peter Wilson wrote: > So, after a long ramble, given that I am happy to waste CPU time in busy > waits (rather than have the overhead of scheduling blocked goroutines), what > is the recommendation for the signalling mechanism when all is done in go and > everything's a goroutine, not a thread? This is similar to something I'm working on for logic simulation, and I'd been thinking about the clocked simulation as well. I'll be interested in your results; since I'm also considering remote computation (and GPU computation, which might as well be remote) I'm currently going with the idea of futures driven by either channels or sync.Cond. That may not be as efficient for your use case. > My guess is that creating specialist blocking 'barriers' using sync/atomic > (atomic.Operation seems to be around 4nsec on my Mac Mini) is the highest > performance mechanism. There's a dearth of performance information on channel > communication, waitgroup, mutex etc use, but those I have seen seem to > suggest that sending/receiving on a channel might be over the order of > 100nsec; since in C we iterate twice through the list in 30-40nsec, this is a > tad high (yes, fixeable by modeling a bigger system, but) My advice would be to implement the easiest method possible that's not likely to box you in and profile it and see where your bottlenecks are. In my case, so far, the delays introduced by IPC mechanisms (and also allocations) is absolutely dwarfed by just the "business logic" crunching the logical primitives. So far it's not worth trying to improve the IPC on the order of nanoseconds (would be a nice problem to have) because the work done in each "chunk" is big enough that it's not worth worrying about. This also leads me to the next part, which is that if you have lots of little operations and you're worried about the time spent on IPC for each little thing, you'll probably get the easiest and best performance gains by trying to batch them so that you can burn through lots of similar operations at once before trying to send a slice over a channel or something. As always, do a POC implementation and then profile it. That's the only productive way to optimize things at this scale, and Go has EXCELLENT profiling capabilities built in. - Dave -- 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/24427C92-66CF-4515-ADB4-A3E96059380C%40gmail.com.
Re: [go-nuts] Generics - please provide real life problems
On Dec 31, 2020, at 11:54 AM, 'Axel Wagner' via golang-nuts
wrote:
>
> On Thu, Dec 31, 2020 at 5:46 PM robert engels wrote:
> I’ll state for the record again, I was originally very dismayed that Go did
> not offer generics - after developing with it for a while that is far less of
> an issue to me than the error handling.
>
> Just to illustrate that the plural of "anecdote" isn't "data": I was
> originally very vehemently opposed to generics in Go, but after using Go for
> a bunch of years, I've been missing them often enough that I think they
> provide a net-benefit (despite my criticism of this specific design).
>
> Generics just isn't a "if you use Go long enough you learn they are not
> important" thing.
This is more or less my position on it as well. From time to time, I find
myself thinking "I could do this easier and more elegantly in C++", which is
never a great place to be. The lack of generics mostly causes me to create
repeated, identical code for things that are almost the same (e.g. bitfield
code for uint32 and uint64 variants) which is invariably more error prone and
just isn't great.
I've been programming in C and C++ for about 25 years, which is not nearly as
long as some people here, but it's enough to say that I understand the
tradeoffs involved with preprocessor macros and templating. C++ is not
generally worth using without the STL, and Java usability was honestly greatly
improved with the addition of generics (until this year, I hadn't done any
serious Java work since before they were added, and I find myself liking it a
lot better; recall that before generics, Java used an interface{}-like or void
*-like approach with Object, which was not very fun).
I'm not going to waste any more time with the increasingly hostile folks who
are denying the existence of real-world use cases in the face of real-world use
cases, but I will gladly discuss the ways in which a generics scheme will make
my real-world problems a lot smaller.
- Dave
--
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/67FC3C39-496B-4931-9789-61BFAC5D9777%40gmail.com.
Re: [go-nuts] Generics - please provide real life problems
This topic has shown little other than that a few people here are unwilling to consider points of view other than their own and declare that very real problems are not real. You should listen to people who have been doing this much longer than you have before discarding all their points as "bullshit", and you should probably review the community code of conduct. If you've got nothing constructive to contribute, why bother? - Dave > On Dec 30, 2020, at 3:53 PM, Space A. wrote: > > "runtime type-casting" > "type safety something" > "boilerplate" > "amount of code" > "benefit something" > "greatly simplified" (for whom?) > > This topic has clearly shown that most people pro-generic have no *real > world* problems that they struggle to solve, yet most of them don't even > understand what *real world* problems are. -- 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/DA26E9B9-7B96-4730-BDBB-F2F52EF510FF%40gmail.com.
Re: [go-nuts] Generics - please provide real life problems
Indeed. I'm working on a boolean logic package that has a number of different bitfield oriented backends, all of which will have a lot of very needlessly repetitive code without generics. If generics weren't coming "soon" I'd consider writing a generator to build it, but generics are the much more elegant solution. This is absolutely a real-world problem that I am having, right now, in the real world. - Dave > On Dec 24, 2020, at 5:20 AM, 'Dan Kortschak' via golang-nuts > wrote: > > I agree. > > A lot of Gonum code would be greatly simplified with the availability > of generics, particularly the linear algebra part. The graph packages > would be richer and we could do more things with tensor-like > operations. -- 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/D9FC4D9B-BB55-4AA8-A9D5-6238E0C1FF84%40gmail.com.
Re: [go-nuts] Golang slow performance inside for loop MySQL Queries
On Oct 21, 2020, at 6:41 AM, Bill wrote:
>
> Hello,
> I created the sql to fetch all info in one call instead of multiple calls per
> each row.
>
> One thing I noticed about golang is that when I ping my Remote DB from
> localhost (running in vscode) I get ping -> 1.573826274s. So I think this is
> the reason that all my calls to db are delayed.
> Have you any idea what can be the issue? Maybe a clean install of Golang in
> MacOSX could fix this issue? If I test the code in server (upload the binary)
> the response time is normal (200ms - 300ms).
>
> My Code to ping:
>
> begin := time.Now()
> err := Config.DB.Ping()
> log.Printf("Ping in %s (%v)", time.Since(begin), err)
So Ping() just gets a response from the server, but it's not really defined how
simple an operation that is. If you have a high latency connection (e.g.
international distances, slow/lossy connection, etc) to your database, it might
only take a few round trips to reach over a second. Honestly, 200 ms sounds
excessively long for an on-server response if it's just going to localhost,
though I suppose it depends on how loaded the database is.
In any case, if a simple database ping is taking a second and a half, it's
reasonable to assume that a number of transactions which depend on each other
could easily amount to 10s. This is where joins are handy, because the
database is actually generally really good at shuffling all that data around on
its own before sending it back to you in one lump. A good join (especially if
you've done your indexing right) will improve both your latency and your code
complexity immensely. It sounds like you may have already done that, in which
case I assume you've seen some improvement.
As to why it takes so long in the first place: where are you located relative
to where the database server is located? What's the response time from a
regular command-line database ping? If you're, say, on the other side of the
world, it's going to take a while for each round trip, and there's not much way
around that other than trying to keep things somewhat closer together where
possible (and also reduce or parallelize the round trips where possible).
There are fundamental limitations in re: the speed of light when it comes to
latency, no matter what your bandwidth.
- Dave
--
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/BD2B7CCD-73B9-4540-B7E5-7F413F16BC47%40gmail.com.
Re: [go-nuts] Golang slow performance inside for loop MySQL Queries
On Oct 20, 2020, at 1:18 PM, Marcin Romaszewicz wrote: > > Go's database layer is generally pretty quick, I use it a lot, but your code > immediately sets off my DB alarms, because you are doing queries within the > body of another query loop, which means you're opening up lots of > connections, which could be slow. > > I'd reorganize as followd. > > - Cache the results of your first query into an array, it's only 6 results. > - Create two prepared statements, one for each query inside the loop. > - Loop over your array of 6 results, and execute each prepared statement > instead of parsing the query each time. > I would also add that this seems like an excellent candidate for a join, not multiple queries, though I admit to not having looked *terribly* closely at the query structure. That should cut down on overhead and complexity a lot. - Dave -- 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/79681751-275B-4FD4-A9E8-F69ABC6C0F5B%40gmail.com. signature.asc Description: Message signed with OpenPGP
Re: [go-nuts] gccgo problem compiling go from source
On Oct 20, 2020, at 2:38 AM, fge...@gmail.com wrote: > > After looking at the list of supported platforms on build.golang.org > and looking at the golang-nuts and golang-dev mailing list archives, I > can't see the ppc e500 as a supported hardware platform for the go > compiler (available on golang.org/dl or github.com/golang/go .) > Getting a compiler to support a new platform or porting a compiler to > a new platform are usually non-trivial processes. > At this stage you'll probably want to use the gccgo compiler if that's > working. > (Also you'll maybe find this useful: > https://github.com/golang/go/wiki/PortingPolicy ) Yes, the biggest thing you'll run into is that support for 32-bit (and, IIRC, big-endian) PowerPC is long gone from the Go compiler. Someone else on the golang-dev list was working on a port to a different embedded-ish 32-bit PPC implementation (440, if memory serves, but it often doesn't). You might want to check there to see if you can collaborate. There is also this tracking issue, which you may find instructive: https://github.com/golang/go/issues/22885 Of note to non-PPC people: the eXXX cores are generally similar to older commercial PowerPCs (i.e. the e300 was a derivative of the 603e, the e500 is somewhat similar to the 750/G3, but is more advanced). Support for specific cores is not quite as important as support for the overall ISA unless you are building an operating system, where they can differ greatly on the low-level details. Personally, I'd love to see 32-bit PPC support reinstated because I have a few boards I'd love to use with Net/OpenBSD and Go, but I don't have the time right now and it's not of commercial interest to me, so I can't get funding for it. - Dave -- 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/A70DB211-2CDF-479B-8434-93D92E7A0901%40gmail.com.
Re: [go-nuts] [ generics] Moving forward with the generics design draft
On Aug 21, 2020, at 00:56, Ian Lance Taylor wrote:
>
> No, the intent is that you would switch on the type parameter itself,
> not a value.
>
> func g[T C](v T) T {
> switch T {
>// the rest is the same
> }
> }
>
> Thanks for asking.
Oh, this clarifies my remaining murkiness about the type switches quite nicely.
Thanks!
- Dave
--
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/863C3CE1-E027-42C8-9200-2DEBF8D0B966%40gmail.com.
Re: [go-nuts] [ generics] Moving forward with the generics design draft
On Aug 20, 2020, at 20:27, Ian Lance Taylor wrote:
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary parameter list. To avoid the ambiguity with
> array declarations, we will require that all type parameters provide a
> constraint. This has the advantage of giving type parameter lists the
> exact same syntax as ordinary parameter lists (other than using square
> brackets). To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.
>
> The result is declarations that look like this:
>
> type Vector[T any] []T
> func Print[T any](s []T) { … }
> func Index[T comparable](s []T, e T) { … }
>
> We feel that the cost of the new predeclared identifier “any” is
> outweighed by the simplification achieved by making all parameter
> lists syntactically the same: as each regular parameter always has a
> type, each type parameter always has a constraint (its meta-type).
>
> Changing “[type T]” to “[T any]” seems about equally readable and
> saves one character. We’ll be able to streamline a lot of existing
> code in the standard library and elsewhere by replacing “interface{}”
> with “any”.
Resounding “yes” from me. I like this a lot. Good choice.
The rest also sounds good (I think; I may be misunderstanding some of the bits
about type switches but I think it sounds good), but #1 in particular should
hopefully end the bikeshedding because it seems a good all-around compromise to
me.
- DavE
--
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/87B9E6D2-EC30-42A3-9E1F-FFA1942D9250%40gmail.com.
Re: [go-nuts] Port to powerpc 440fpu
On Aug 10, 2020, at 4:59 AM, Hugo Cornelis wrote: > > > Hi, > > Bottom line: Docker works reliably on powerpc 440fpu 32 bit using gccgo as > the compiler. We will likely soon start working on powerpc e6500 in 32bit > mode. > > After a fix in the structures used by the epoll system calls, the problem > disappeared. I assume the problem was a starvation similar to > > https://github.com/moby/moby/issues/39461 > > We had to correct the used system call numbers for the fstat system call > family, for sendfile, fadvise, ftruncate, truncate and fcntl. > > We also had to fix the alignment of some of the structures used by these > functions and for the EpollEvent structure (ie. the generator did not always > generate correct structures). The fix for EpollEvent also fixed the I/O > starvation problem. > > It remains unclear why the generator did not generate correct structures. We > updated the post processor mkpost.go to fix the structures (alignment + > member names), but did not look further into the underlying problem. Glad to see updates! I hope there's a chance to mainline this, I would welcome running Go in 32-bit PPC on my Net/OpenBSD machines that run on that platform. - Dave -- 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/9E061F1B-2197-4A68-8B5A-9359C28DBA8F%40gmail.com.
Re: [go-nuts] First git commit for Go was in 1972? 🤯
> On Aug 5, 2020, at 5:16 AM, Amarjeet Anand > wrote: > > How come the first git commit for Go was in 1972? > > Anybody want to share the story behind the first 4 commits of Go project by > Brian Kernighan? > > > https://github.com/golang/go/commits/master?after=188b2ac839f828254678d0f05a3ea953dc5d0621+4764&branch=master I had not noticed these, but they are brilliant. Note the history in the commit logs as well (which look like somewhat like SCCS delta messages to me). A small glossary, and you can piece the rest together yourself: ken = Ken Thompson, co-originator of Unix and Go dmr = Dennis Ritchie (RIP), co-originator of Unix and C Go has a distinct lineage from the Bell Labs folks that gave us C and Unix and Plan9, so these are a lovely homage to Go's ancestors. - Dave -- 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/4ACDD9F1-5950-4DB9-8B52-2789A7C35A3E%40gmail.com.
Re: [go-nuts] Generic symbol metaproposal
On Jul 24, 2020, at 5:50 PM, Ian Lance Taylor wrote: > > On Fri, Jul 24, 2020 at 2:22 PM wrote: > > > > On 7/23/20, Michael Jones wrote: > > ... > > > Another delight is the uppercase signal for external. > > > > > > Maybe the “how to signal it” aspect of type instantiation could look to > > > these approaches as well—make the automatic understanding so magical that > > > the complete specification is unnecessary in most all cases, or the > > > signaling so intrinsic to the variables that no identification Symbol or > > > BracketedPair is necessary. > > > > Maybe braille? > > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙ > > https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG > > > > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽ > > I've always felt that color is underused in modern programming languages. > > func Max(T)(s []T) T Perhaps there could be some cross-pollination with ColorForth, wherein color actually is semantically meaningful. https://colorforth.github.io - Dave -- 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/5C8F0D0D-0D9D-45E4-8B68-E78C59505550%40gmail.com.
Re: [go-nuts] Generics and parentheses
On Jul 22, 2020, at 8:02 PM, Russ Cox wrote: > > So it sounds like everyone is in favor of the entire generics proposal and > all the semantics, and all we have left to hammer out is the bracket > characters? Do I have that right? We haven't covered what the bike shed roof is going to be made from, but other than that, assuming things like type switches are planned to be solved in the end, I'm happy with it. - Dave -- 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/71B4F56E-471C-4AD3-9B24-7BF3BE136BCE%40gmail.com.
Re: [go-nuts] Generics and parentheses
On Jul 15, 2020, at 4:59 PM, Ian Lance Taylor wrote: > > On Wed, Jul 15, 2020 at 5:44 AM Jan Mercl <0xj...@gmail.com> wrote: >> >> My 2c - Alternative type parameters syntax (ab)using @$: >> https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing > > Thanks for the detailed writeup. I'm a bit concerned about name > scoping. Also about the fact that constraints can apparently show up > anywhere; is that always going to work? And I don't think that > Vector@$T is going to be all that intuitive for anybody to read. Well, it should make the VMS programmers happier. - Dave -- 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/262C2302-3FA7-4A43-B535-C402D3BA7626%40gmail.com.
Re: [go-nuts] Generics and parentheses
On Jul 15, 2020, at 2:48 PM, Ian Lance Taylor wrote: > > More seriously, though, let's look closely at Robert's example: > > a, b = w < x, y > (z) TBH, I think a big argument in favor of square brackets over angle brackets is that they ascend above the center line in most typefaces, which makes them much more visually distinct from the shorter operators and many lowercase letters. This is similar to parens and curly braces while still being visually distinct from both. As something that is essentially a metaparameter which is similar to, but distinct in function to the arguments in parens, there's a lot of good consistency going on there that I personally find easier to visually scan without syntax highlighting than I do angle brackets. But that could be just me, and it does depend on typeface, so take it with whatever grains of salt you need to. - Dave -- 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/51B8F207-955C-4C9C-88C6-A0FD605C6ACA%40gmail.com.
Re: [go-nuts] Generics and parentheses
On Jul 15, 2020, at 4:47 AM, Nick Craig-Wood wrote: > > In my mind the use of [ ] clashes horribly with the array declaration > syntax. When I see [int] in particular my brain says, ah array declaration of > size int, what, no wait... On the other hand, this is already how maps are declared (e.g. map[int]string). It's fairly consistent with that, actually. - Dave -- 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/A93735EA-52DB-4505-BF8F-4BFD22CC0D73%40gmail.com.
Re: [go-nuts] Re: Generics and parentheses
On Jul 15, 2020, at 12:13 AM, Ian Lance Taylor wrote: > > The disadvantage of guillemets is that they are hard to type on many > keyboards. So to me either square brackets or angle brackets would be > better than guillemets. Not to mention that, while Go *is* officially in UTF-8, the chance of an output device or editor mis-formatting something that isn't 7-bit ASCII is still reasonably significant even in 2020, and that has much graver consequences for delimiters than for, say, identifiers or string contents. I'm curious about how screen readers react as well; I know we have one or two folks on this list who could probably offer some perspective there. > The disadvantage of a two character sequence such as <: :> is that it > is more typing. So again either square brackets or angle brackets > seem to me to be better. > > An example of a reason that square brackets might be a poor choice > would be ambiguous parsing, or cases where the code is harder to read. > > It's true that some other languages use angle brackets, but Go already > does many things differently. That is only a minor advantage for > angle brackets. To me at least it does not outweigh the > disadvantages. I think square brackets do the job of visually disambiguating the syntax from the other uses of parentheses on the same lines well enough, and it sounds like with the "type" keyword they do the job well enough for the parser as well. Personally, I have no horse in the race for square vs. angle brackets (other than I think it would be foolish to do something technically infeasible or problematic just because it subjectively looks nicer), but then, I also like Objective-C's visual styling, so YMMV. - Dave -- 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/94FC42B1-ABD0-4E37-AE80-0B4313DC34C9%40gmail.com.
Re: [go-nuts] Generics and parentheses
On Jul 14, 2020, at 5:54 PM, 'Robert Griesemer' via golang-nuts
wrote:
>
> But if we are comfortable with the extra type keyword, the ambiguity
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not yet
> on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to arise
> with square brackets. Here are some examples where extra parentheses are not
> needed with square brackets:
>
> using () using []
> func f((T(int)) func f(T[int])
> struct{ (T(int)) } struct{ T[int] }
> interface{ (T(int)) }interface{ T[int] }
> [](T(int)){} []T[int]{}
Just my $0.02: I really like this. Thank you for responding to feedback, and I
look forward to trying the new syntax out!
- Dave
--
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/6C145CFD-7A43-4BAA-87AA-5E3AA00C068C%40gmail.com.
Re: [go-nuts] Golang telnet package
On Jul 12, 2020, at 10:17 AM, Harris Newman wrote: > > I'm writing a telnet server and have found several packages which provide > telnet functionality, but can't find any telnet support in the standard > library or other packages in the golang.org site. > > Is there a golang supported telnet package that allows writing of telnet > clients/servers? If so, can you point me to it? I'd assume it's unlikely to ever be in the standard library for the same reason FTP clients/servers are unlikely to be there: telnet and FTP are both wildly insecure and largely obsolete in the commercial world, so there's relatively little reason for the standard library maintainers to spend the effort maintaining them given the overall utility to the Go community. That said, there are lots of valid reasons to write Go telnet and FTP clients (speaking as a vintage computer enthusiast who frequently makes use of both protocols as well as Gopher, AppleTalk, DECnet and other things that will never live in the stdlib). They're just not the kind of really broad use case that would warrant inclusion in the standard library. But they're an excellent candidate for a popular third-party implementation if you or someone else wants to maintain that. In general, as far as I can see, the standard library tends to be constrained to: - Things that are useful/needed for Go itself (e.g. text processing that the compiler uses) - Selected very popular use cases (e.g. there is a built-in JSON encoder/decoder and HTTP server, but not YAML, Protobuf or gRPC, though the latter two are maintained separately by Google) - A handful of esoteric tools proven useful (e.g. expvar) Other than that, the rich array of available third-party modules is your friend. - Dave -- 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/74A2ED70-0043-42B1-B069-D7788630A381%40gmail.com.
Re: [go-nuts] building go 1.14.4 on CentOS 7 multiple test failures
On Jul 10, 2020, at 3:02 PM, Alastair Neil wrote: > > > It's an old but not an especially slow machine: dual 8 core E5-2670 Xeon > with 64 GB Ram. > I wil try > GO_TEST_TIMEOUT_SCALE=4 I've successfully built on an older and slower (pre-Nehalem) 8-core Xeon with a similar RAM load just last week, so it's probably not that. Is something amiss with your system's timer setup? The tick tests seem wrong, but precisely near 100ms boundaries. It almost looks like you have 10 Hz scheduler ticks and it's not seeing the granularity it should (and maybe getting scheduled later than expected). - Dave -- 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/46244F14-A133-4E5C-B54E-49C703F73921%40gmail.com.
Re: [go-nuts] Re: Speed up png.Decode
On Jun 27, 2020, at 8:30 AM, Robert Engels wrote: > > Just because the bulk of the time is in the decode doesn’t mean the decode is > inefficient or can be improved upon. It might be the most expensive stage in > the process regardless of the implementation. This is I think the most important point; image decoding is an expensive operation, and it makes sense that the bulk of your time decoding is spent on it. The question is how it stacks up to other decoders; if you're able to write a quick C proof-of-concept to test how fast libpng does it (or libspng) and run the same benchmarks, you'll get your answer there. Depending on how regular your images are (size-wise, especially), you may be able to get some additional mileage out of pooling your receiving buffers and reusing them after your operations are complete. There doesn't appear to be a handle for that in the current image/png library like there is for encoding, though; you'd have to do some surgery on decoder.readImagePass to do something like that. - Dave -- 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/5F296DCC-1521-4D04-9D93-9BCEB6B5B537%40gmail.com.
Re: [go-nuts] Slices and inconsistency
On Jun 26, 2020, at 2:59 PM, Ian Lance Taylor wrote: > > I honestly don't think that append is an example of worse-is-better. > I think it's an example of preferring to pass and return values rather > than pointers. The language could easily have made append take a > pointer to a slice as its first argument, which would eliminate a > certain class of bugs. But it would also mean that you couldn't > create a slice by simply appending to nil, as in s := > append([]int(nil), 1, 2, 3). You would instead have to declare the > variable first. I should clarify that I don't consider it a dig; I think it's a practical solution to the problem even if it has its warts, because it is both performant and flexible. Other languages choose either in-place operations (e.g. Java) or copies (e.g. Erlang), but you can do a lot more with what's offered in Go. It just takes some getting used to. > While append does confuse people from time to time, I think it's > clearly documented, as pointed out upthread. It's not really all that > hard to understand. And once you understand it, it's easy to use. The "once you understand it" part is really the issue here, because it's not immediately obvious if you're not reading the manual. > I don't think any particular approach is obviously better here, so I > don't think this is an example of worse-is-better. The canonical example in Worse Is Better is Unix's solution to the problem where you get an interrupt in the middle of a syscall; Unix just said "hey, this failed, do it again" instead of going to great lengths to try to resume the operation, which was the pragmatic choice even if it led to a somewhat quirky interface. "Worse Is Better" is often characterized more by quirkiness rather than outright badness, and Richard Gabriel (LISP purist that he was) was pretty upfront about being cheekily hyperbolic about the properties that Unix and C had that made them perhaps occasionally inelegant but ultimately more effective and survivable. I think a lot of aspects of Go embody that particular spirit, again for good reason considering its progenitors. - Dave -- 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/46EE15DC-9728-4DD3-BAAA-F794A78DE123%40gmail.com.
Re: [go-nuts] Slices and inconsistency
> On Jun 26, 2020, at 2:52 PM, Tyler Compton wrote: > > On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote: >> Also, to this specific point: this exact approach, as with much of Go, >> embodies the Bell Labs approach to design (for better or for worse, and with >> good reason). Sometimes we have to live with the artifacts of evolution. >> > One interesting counterexample here is the GC and scheduler, which take on a > huge amount of complexity in the implementation to create a dead-simple > interface. It seems like Go is willing to take a worse-is-better approach > when the amount of interface complexity is relatively small. Agreed, and this is a good point! Similar for even early Unix and the memory allocator. Some things you have to make a simple interface for or no one will use them. - Dave -- 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/AB926BC1-A29E-4D77-8DCD-BA022463797E%40gmail.com.
Re: [go-nuts] Slices and inconsistency
On Jun 26, 2020, at 1:41 PM, Robert Engels wrote: > > My opinion is that if RTFM is required more than once for a core concept > there may be a design problem. It clearly bites a lot of people. Slices are a > higher level struct, as the underlying array is the same as Java, but Java > doesn’t suffer these knowledge gaps. I’m guessing because it’s higher but not > high enough. Done for performance while forsaking some safety and clarity. Also, to this specific point: this exact approach, as with much of Go, embodies the Bell Labs approach to design (for better or for worse, and with good reason). Sometimes we have to live with the artifacts of evolution. https://www.jwz.org/doc/worse-is-better.html - Dave -- 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/6E11D888-40DA-4606-B698-8509CAE5502F%40gmail.com.
Re: [go-nuts] Slices and inconsistency
On Jun 26, 2020, at 1:41 PM, Robert Engels wrote: > > I don’t think “how it works” is the confusion, more of “how to use it > properly” > > My opinion is that if RTFM is required more than once for a core concept > there may be a design problem. It clearly bites a lot of people. Slices are a > higher level struct, as the underlying array is the same as Java, but Java > doesn’t suffer these knowledge gaps. I’m guessing because it’s higher but not > high enough. Done for performance while forsaking some safety and clarity. Frankly, I think the problem is with append(). I understand why it's structured the way it is, and yes, I agree the documentation is fairly clear about how it works *if you read it*, but we need to be honest with ourselves about how people read the documentation (or don't). The problem with append() is that it returns a value, and if you only learn by example or quickly skim through the docs (as Howard pointed out), it's not going to be immediately apparently that it's not necessarily a new slice or array. I don't say this because I think append() should be modified to be an in-place operator (that would be impractical and break a lot of things that rely on current behavior) but it shouldn't be mysterious to us that people coming from every language that has a variable-length vector think of it incorrectly because that's how the vast majority of them treat an append operation (either as an in-place or as a copy, and we've kind of split the difference). I wish I had a more constructive answer to this, because I guess you can't make other people's tutorials call this out, and using the return value as a different slice is a valid thing to do even if it is inadvisable without doing more elaborate checking on the capacity, etc, so it's kind of hard to put in a linter. - Dave -- 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/7E5E5A28-4CAE-41DF-A354-320CC7F7ED87%40gmail.com.
Re: [go-nuts] Slices and inconsistency
> On Jun 26, 2020, at 9:28 AM, Robert Engels wrote: > >> On Jun 26, 2020, at 8:23 AM, David Riley wrote: >> >> You are correct, the programmer needs to read the manual. Slices are >> "windows" into their underlying array, therefore assigning data into slices >> tied to a given array changes the data in other arrays as well. The >> append() function merely extends the slice by n and assigns into those >> elements, returning the new slice header (the old one can remain unchanged, >> but they will both be slices of the same array). >> >> Ian pointed to the canonical documentation on this: >> https://blog.golang.org/slices >> >> Additionally, the language spec has this: >> https://golang.org/ref/spec#Appending_and_copying_slices >> >> I do agree that it would be nicer if this were flagged a little more loudly, >> since the semantics of the append() builtin can lead the early developer to >> believe they are making a copy of the slice in question, but they aren't. >> > That is not quite true. Once is it extended beyond the current capacity you > will have a new backing array and the slices will diverge. Agreed, but the problem here is that unless you are checking the capacity beforehand, you cannot count on that behavior. The general point is that if you want a modified copy of an array/slice, you need to be explicit about it or you will run into unpredictable and unpleasant to debug problems, but that is not immediately apparent given the superficial semantics of the append() builtin unless you understand slices at a deeper level. As in all things, the proper fix is to RTFM, but I think TFM could afford to be a *tiny* bit more explicit about this because it's surprisingly easy to miss. - Dave -- 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/222003D0-79C2-46D8-B0CE-41CF0342BE78%40gmail.com.
Re: [go-nuts] Slices and inconsistency
On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote: > > Essentially based on the existing capacity, the assignment of one slice > effects other slices. These are stemming from the underlying pointer > arithmetic and seems inconsistent. Looks like programmer needs to know the > history of capacity before understanding the ramifications of slice > assignments. You are correct, the programmer needs to read the manual. Slices are "windows" into their underlying array, therefore assigning data into slices tied to a given array changes the data in other arrays as well. The append() function merely extends the slice by n and assigns into those elements, returning the new slice header (the old one can remain unchanged, but they will both be slices of the same array). Ian pointed to the canonical documentation on this: https://blog.golang.org/slices Additionally, the language spec has this: https://golang.org/ref/spec#Appending_and_copying_slices I do agree that it would be nicer if this were flagged a little more loudly, since the semantics of the append() builtin can lead the early developer to believe they are making a copy of the slice in question, but they aren't. - Dave -- 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/CA9014AE-527F-4D18-81A9-6E63FAD97B54%40gmail.com.
Re: [go-nuts] Generics: More on parens
On Jun 18, 2020, at 6:19 PM, Jon Conradt wrote: > > Ian, I like the direction being taken on Generics, and I am thankful the Go > Team did not rush into an implementation. > > I'm not a huge fan of another set of ()'s and I agree with not wanting the > overhead of overloading <>. That got me thinking that we are in the 21st > century. We all use editors which are comfortable with Unicode. Why not take > advantage of characters beyond 7-bit ASCII? The biggest reason, IMO: those are difficult to type on a keyboard. What you're proposing here will be nearly impossible to type on any editor that doesn't have specialized support, which is a lot of them. The keystrokes you propose (shift-opt-0/9) are Mac specific, since no one else has an Option key, and on my Terminal (on OS X) they result in the characters "·" and "‚" respectively, so I can't use them in vi. The second-biggest reason is that they aren't guaranteed to display right everywhere (especially on screen readers, and I know we have a number of visually-impaired folks on this list for whom this is vitally important). With apologies to those who can't view images, here is how this looks on my mail client in both proportional font (as received) and monospaced (as typed): This will cause problems. The authors of the proposal explicitly said they couldn't bring themselves to use something that's not ASCII, and I think that's still a valid decision. - Dave -- 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/B2D47B12-F91B-4F87-8E20-33ACE5B35878%40gmail.com.
Re: [go-nuts] [generics] replace ()/(type ) with :[]
On Jun 18, 2020, at 12:30 PM, 'Thomas Bushnell, BSG' via golang-nuts wrote: > > On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo wrote: > Personally () parentheses seems like to be harder to read, too similar with > function calls. > > This is exactly why I like it. These are parameters, and should be thought of > just like other parameters in a function call. This is precisely why I don't like it, because they are *metaparameters*. Having a variable length set of options where the length determines what the FIRST options are is actually really confusing, particularly because we already have an optional set of parentheses for the return types. I understand that folks familiar with Lisp/Scheme might be comfortable with it, but I'm very comfortable with both of those and I find this a bit maddening. Could be just me. I really do like the idea of separate characters for metaparameters on functions; another option would be Python/Java style decorators on the function (e.g. @type(A)), though I think in practice that might be a bit unpleasant (I really wish there were a better way to do the decorator pattern in Go, though). I'm somewhat surprised that the parser developers find the variable-length list of parenthetical clauses *easier* to deal with; it seems like a good way to introduce ambiguity in the parsing. That may be part of why the parser currently breaks when returning closures. But then, I'm not the one writing the parser, so I'm running on a lot of assumptions. I'm all for giving this time to settle and see how it plays out, of course. One thing I've learned is that it's generally a fool's errand to optimize for my use cases, at least if anyone else is going to like it. But consider this my vote for alternate delimiters. - Dave -- 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/D495EE84-B30E-46BD-9DD7-3E4531DFCB18%40gmail.com. signature.asc Description: Message signed with OpenPGP
Re: [go-nuts] [generics] Closure?
I think this probably gets a little closer to what you were going for, but
there's a puzzling error that leads me to think the parser doesn't quite
understand the instantiation in the return type:
https://go2goplay.golang.org/p/gcD609dr21E
type Foo(type T) struct {}
type FooFunc(type T) func() Foo(T)
func bar(type T)() FooFunc(T) {
return func() Foo(T) {
return Foo(T){}
}
}
Looks like someone else just posted that naming the return value is a
workaround for this parser issue: https://go2goplay.golang.org/p/0Kdfj81Ot3B
type Foo(type T) struct {}
type FooFunc(type T) func() Foo(T)
func bar(type T)() FooFunc(T) {
return func() (_ Foo(T)) {
return Foo(T){}
}
}
> On Jun 18, 2020, at 2:17 PM, teivah@gmail.com wrote:
>
> Hello,
>
> I didn't find in the latest draft design any mention of generics with closure
> and I'm struggling in having something working:
>
> type Foo(type T) struct {}
>
> func bar(type T)() Foo(T) {
>return func() Foo(T) {
> return Foo(T){}
>}()
> }
>
> In this example, how can I create a closure that would return a Foo(T)?
>
> Here is the playground: https://go2goplay.golang.org/p/N-b10vSCois
>
> Cheers
>
> --
> 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/2083e7d6-95f4-4d34-b5c1-6f986d0d4c51o%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/9D3C56F5-713F-4177-82A0-27D012BA682B%40gmail.com.
Re: [go-nuts] Awkwardness around built in containers and user containers
On Jun 17, 2020, at 8:45 PM, Ian Lance Taylor wrote: > > On Wed, Jun 17, 2020 at 9:35 AM wrote: >> >> How do I write a function that can take any container? Either a built in >> container or a user defined structure? Java is awkward when deciding to >> accept arrays or the List type — is go fated to repeat this awkwardness? > > It is as you fear: Go does not have a unified syntax for looping over > either builtin containers or user containers. In Go this rarely comes > up due to the absence of generics. I might object to the use of "rarely" here: there's no convenient construct in Go to iterate over any non-fixed container but a channel, and while you can make an iterator/generator out of a channel, it is awkward and fraught with peril because of some of the peculiarities around hanging channels. This comes up rather a lot for me, actually. - Dave -- 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/0DA952D0-4C74-424B-849A-54A15D600766%40gmail.com.
Re: [go-nuts] Re: political fundraising on golang.org!
On Tuesday, June 16, 2020 at 11:52:10 AM UTC-4, K Richard Pixley wrote: > > There is agreement on the code of conduct. There is not agreement on the > banner. IMO, the banner is out of line with the goals of this group and > with the code of conduct. It's inappropriate. It needs to be removed. > > > You're welcome to submit a CL and have the community vote on it. I look forward to voting on your submission. -- 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/67296c2b-add0-4c62-9204-03e0388ea0d1o%40googlegroups.com.
Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?
Not quite. When they switched to PowerPC, that was the case; the initial one was a table-driven instruction translator in ROM originally written for the M88k, which had been the original target before Motorola canned it, but it was apparently a relatively simple thing to change the translations to PowerPC instructions (only took a weekend according to legend, but, well, legends). It eventually evolved into something much more sophisticated and performant. The transition from PowerPC to Intel ended the Classic VM environment that ran Mac OS 9, which included the old 68k translator in the ROM file. On a PowerPC Mac running OS X 10.4 (including G5s, which are 64-bit!), you can run 68k apps from the dark ages just fine (as long as they didn't use undocumented interfaces, etc). I've been doing exactly this recently while porting a very old Mac game to modern systems. Anyway, no Classic support on Intel, thus no 68k either (and PowerPC only for OS X apps). The PowerPC emulation for Intel (Apple called it "Rosetta") was a licensed third-party product that used JIT-style compilation, but it really only worked for userland programs; it didn't support drivers and it presumably wasn't close enough to the real deal to support the Classic environment, so they dropped it in all Intel versions of Mac OS (10.5 dropped it for PowerPC as well for reasons I don't quite understand, since that was the last PowerPC version). Anyway, given that the PowerPC translation on Intel only lasted through 10.6, and Apple just dropped 32-bit Intel support in 10.15, I would expect backwards compatibility support for Intel apps (if they're even planning it) to drop within 2-3 revisions of macOS after the transition. Just putting that out there. > On Jun 10, 2020, at 8:47 PM, Robert Engels wrote: > > When Macs first switched to Intel the OS included a Motorola 68k emulator so > that existing Mac binaries would run. -- 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/985784B5-328E-42A6-88A4-92B2EC5A3FE1%40gmail.com.
Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?
On Jun 10, 2020, at 3:23 PM, David Riley wrote: > > Also worth noting that IBM i (f/k/a System i and AS/400) traditionally stores > its executables as an IR form to be compiled to native code (currently PPC) > on execution, though my recollection is that this is a one-time process, not > a JIT process like Java or WASM. Well. Actually, currently POWER, as long as I'm being pedantic. :-) - Dave -- 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/039A4634-08AD-4EAE-BB25-498B456B46D2%40gmail.com.
Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?
On Jun 10, 2020, at 5:50 AM, Jesper Louis Andersen wrote: > > 2. Dynamic binary translation from machine-code to machine-code has been used > in the past for these architectural changes. While this carries a penalty, it > also provides a short-term solution. The added efficiency of recompiles for > the new machine code target encourages people to install newer versions in > the case. The history is old and long here. M68K to PowerPC, PowerPC to x86, > x86 to DEC Alpha, VAX to Alpha RISC, and even more. Apple have been involved > in at least two such models in the past, so I wouldn't count this out as a > strategy. This is certainly pedantry, but it's worth noting that the VAX to Alpha translation in VMS wasn't dynamic recompilation, but static. There are almost certainly similar examples; I'm not familiar enough with NT history to remember if there was a similar translator for the Alpha version, but given that Dave Cutler was at the helm of that transition (though not the VAX->Alpha transition at DEC), I wouldn't be surprised. Also worth noting that IBM i (f/k/a System i and AS/400) traditionally stores its executables as an IR form to be compiled to native code (currently PPC) on execution, though my recollection is that this is a one-time process, not a JIT process like Java or WASM. - Dave -- 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/B924AC7A-F592-4FFA-A56F-75134C626D04%40gmail.com.
Re: [go-nuts] High Performance REST API Framework.
I like Echo (echo.labstack.com) a lot. Nice and modular, more capable than Gin with about the same performance, and I think it meets all of your criteria (except having never used Spring Boot before, I don't know how it compares). - Dave > On May 9, 2020, at 12:39 AM, Sai Matam wrote: > > What would be a high performance web framework? I am looking for:- > • Reactive (non-blocking) > • Enough HTTP compatibility to implement a REST API > • Would be great if it feels like Spring Boot or Swagger > • Well maintained. > • Should be able to scale to tens of thousands of connections > • WebSocket support would be nice. > • idiomatic or stylized. > 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/BF0C59CB-AC6A-45BC-9FF0-E6A84340990E%40gmail.com. signature.asc Description: Message signed with OpenPGP
Re: [go-nuts] Re: go run requires internet connection?
I feel like it's 10.15 where Apple really started doubling down on their "notarization" service? I haven't updated anything to it because it breaks (by design) a number of things I regularly use, so it would be hard to say, but that has to be frustrating for developers who can't be constantly online. - Dave > On Apr 9, 2020, at 7:54 AM, Michael Jones wrote: > > Unable to reproduce the issue on MacOS Mojave 10.14.6, though I tried with > gusto. > > On Thu, Apr 9, 2020 at 4:32 AM Tanmay Das wrote: > Thanks, everyone for your valuable comments. I think Brain is right. It might > be an OS-related issue. I really like how active this group is. I look > forward to coming back with more topics in the future. Stay Home. Stay Safe. -- 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/9A9C1172-116D-4B73-B799-6E9FF0E41EA3%40gmail.com.
Re: [go-nuts] Re: Using modules with private repos
This is actually a fairly neat solution! I might look at using that from here on out. How well does it work if something else (also with access to your private repository) tries to include your module? - Dave > On Apr 1, 2020, at 11:47 AM, Dave Mazzoni wrote: > > With all the examples out there and a little experimentation, I found the > solution I needed. Here's the tree from the 'top' directory: -- 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/3DA50BB0-29DF-4E37-905D-11B1D011D90E%40gmail.com.
Re: [go-nuts] Go course
And since I'm a fan of lifelong learning, I have to admit to not having known
that println() was a builtin until this post. Thanks! That does un-complicate
it somewhat.
> On Mar 26, 2020, at 10:34 AM, Sebastien Binet wrote:
>
> On Thu, Mar 26, 2020 at 3:29 PM David Riley wrote:
> [...]
> But:
>
> - You still need to import something just to print a line, and it is
> confusingly (to the novice) named "fmt"
> - You still need to declare a function called main(), and most brand-new
> programmers don't understand functions yet, so this becomes a "wave the dead
> chicken at it just right" thing
> - Semicolons are still there under the surface, but they're inserted by the
> lexer, and when they get inserted can be really mysterious and trip a lot of
> people up
>
> In contrast, in Python (3, in this case), it is:
>
> print("Hello, world!")
>
> to be fair, in Go, "hello world" can be reduced to:
>
> package main
> func main() {
> println("hello world")
> }
>
> that's usually how I start my Go-based lecture.
> (and then, 2-3 lectures/hands-on sessions after that, I do introduce 'import
> "foo"')
>
> -s
--
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/D503437D-FA3F-4388-973D-4DF4BC1F73A8%40gmail.com.
Re: [go-nuts] Go course
, I would say that it is much > more complicated than Go. > It has a large and growing number of expressive features which add to the > cognitive load of those attempting > to get up to speed on the language. When you learn Go, you don't need to > understand dict comprehensions, > decorators, metaclasses, asyncio etc. Compare the breathtaking simplicity of > launching a Go routine > with the convoluted mess of python threading. > > The lack of strong static typing and a separate compilation phase means that > errors which in Go would > cause a compilation error result in run-time exceptions, when a particular > code path gets executed. > > Python also has the "feature" that changes in invisible whitespace characters > change the programme semantics. > I never really understood the rationale for the feature. > > The Go 1 compatibility promise is also helpful. This means that course > materials or online code examples written > 8 years ago will still work today. The python community broke most existing > code when they moved from Python 2 to Python 3. > (A decade on this transition is still ongoing). > > On Wednesday, 25 March 2020 23:04:58 UTC, David Riley wrote: > It’s just my opinion, and I’m willing to be wrong. :-) > > But having TAed a university introductory computer science course that was > first in C and then in Python (and having had several students who failed > when it was in C retake in Python and pass with flying colors), I will say > that a lot of the elements that tripped beginners up in C which were absent > in Python are present in Go. > > Most of those (e.g. separate compilation, static typing, a few other bits of > arcana) are features that make Go a much more effective systems language than > Python, but I do feel like it’s probably best to “take the bumpers off” AFTER > the student knows about loops, variables, functions, etc. > > Again, it’s only my point of view, and I do have some biases, but they do > have some basis. > > > - Dave > > > On Mar 25, 2020, at 17:08, Dan Kortschak wrote: > > > > I don't agree that Go is intrinsically harder than python as a beginner > > programming language. There are things that are subtle, but these can > > largely be avoided in the beginner setting. > > > > Note that there have been discussions here about using Go as a language > > for teaching beginners, notably this one > > https://groups.google.com/d/topic/golang-nuts/FIRSDBehb3g/discussion > > > > Dan > > > >> On Wed, 2020-03-25 at 13:34 -0400, David Riley wrote: > >> If you are already a programmer in another language, the Tour of Go > >> (tour.golang.org) is absolutely the best. > >> > >> If you are not already a programmer in another language, I personally > >> don't recommend Go as a first language; it's an excellent language, > >> but I feel that people will do better with it once they already grasp > >> the fundamentals of programming and are ready for something with > >> slightly more arcana. Python makes a pretty good first language. > >> > >> > >> - Dave > >> > >> > >>> On Mar 25, 2020, at 6:07 AM, Renato Marcandier < > >>> renato.m...@gmail.com> wrote: > >>> > >>> Hello guys, > >>> > >>> What's the best course to start with Go? > >>> > >>> > >>> > >>> Regards > >>> RG > >>> > >>> -- > >>> 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 golan...@googlegroups.com. > >>> To view this discussion on the web visit > >>> https://groups.google.com/d/msgid/golang-nuts/b2aa0e9a-921f-49de-a0be-729a6ca35f5f%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 golan...@googlegroups.com. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/golang-nuts/18B2AF64-4888-4730-B282-FCB4C00AB697%40gmail.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/b43ecb5a-c043-44d4-92d6-f8c046dda7ff%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/21528ED2-C49B-4785-AD12-ED28B603D44B%40gmail.com.
Re: [go-nuts] Go course
It’s just my opinion, and I’m willing to be wrong. :-) But having TAed a university introductory computer science course that was first in C and then in Python (and having had several students who failed when it was in C retake in Python and pass with flying colors), I will say that a lot of the elements that tripped beginners up in C which were absent in Python are present in Go. Most of those (e.g. separate compilation, static typing, a few other bits of arcana) are features that make Go a much more effective systems language than Python, but I do feel like it’s probably best to “take the bumpers off” AFTER the student knows about loops, variables, functions, etc. Again, it’s only my point of view, and I do have some biases, but they do have some basis. - Dave > On Mar 25, 2020, at 17:08, Dan Kortschak wrote: > > I don't agree that Go is intrinsically harder than python as a beginner > programming language. There are things that are subtle, but these can > largely be avoided in the beginner setting. > > Note that there have been discussions here about using Go as a language > for teaching beginners, notably this one > https://groups.google.com/d/topic/golang-nuts/FIRSDBehb3g/discussion > > Dan > >> On Wed, 2020-03-25 at 13:34 -0400, David Riley wrote: >> If you are already a programmer in another language, the Tour of Go >> (tour.golang.org) is absolutely the best. >> >> If you are not already a programmer in another language, I personally >> don't recommend Go as a first language; it's an excellent language, >> but I feel that people will do better with it once they already grasp >> the fundamentals of programming and are ready for something with >> slightly more arcana. Python makes a pretty good first language. >> >> >> - Dave >> >> >>> On Mar 25, 2020, at 6:07 AM, Renato Marcandier < >>> renato.marcand...@gmail.com> wrote: >>> >>> Hello guys, >>> >>> What's the best course to start with Go? >>> >>> >>> >>> Regards >>> RG >>> >>> -- >>> 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/b2aa0e9a-921f-49de-a0be-729a6ca35f5f%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/18B2AF64-4888-4730-B282-FCB4C00AB697%40gmail.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/A75157E2-25B3-4431-8182-280FD3854CCD%40gmail.com.
Re: [go-nuts] Go course
If you are already a programmer in another language, the Tour of Go (tour.golang.org) is absolutely the best. If you are not already a programmer in another language, I personally don't recommend Go as a first language; it's an excellent language, but I feel that people will do better with it once they already grasp the fundamentals of programming and are ready for something with slightly more arcana. Python makes a pretty good first language. - Dave > On Mar 25, 2020, at 6:07 AM, Renato Marcandier > wrote: > > Hello guys, > > What's the best course to start with Go? > > > > Regards > RG > > -- > 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/b2aa0e9a-921f-49de-a0be-729a6ca35f5f%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/18B2AF64-4888-4730-B282-FCB4C00AB697%40gmail.com.
Re: [go-nuts] SIGILL running 1.14 on macOS
On Feb 26, 2020, at 2:00 PM, James Pettyjohn wrote: > > A little further digging shows that VZEROUPPER is part of the AVX instruction > set, not supported on any Apple computers prior to 2011 from what I can tell. > > Given the rc1 code worked fine, that could be an alternative for Darwin where > the CPU does not support AVX. While not ideal, I'd argue it's better than > cutting off support for these machines which can run High Sierra. Once > support for High Sierra is dropped then it should not matter as it takes a > 2013 or later model to run anything after High Sierra. There are quite a lot of extant machines running Nehalem-generation Xeons (55/56xx) and routers running older Atoms that don't support AVX. I had a similar problem with the Suricata package for OpenBSD. - Dave -- 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/08181A18-07F3-4BF5-8E12-4D661170C17B%40gmail.com.
Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write
On Mar 5, 2020, at 5:17 PM, Warren Stephens wrote: > > So I should invent a fractal programming language -- where every function > must be defined within another function -- have people write tests for that! I think we call that "LISP". - Dave -- 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/445D8594-E9D0-42BD-9D6D-6F2C9393F431%40gmail.com.
Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write
On Mar 5, 2020, at 9:26 AM, Warren Stephens wrote: > > And I am saying Functions PLUS Structure. > > > > Functions remain. Visible structure is added. Right, and you can do your testing at the boundaries of those functions, because the structure is nothing but a shell (in most Step Lambda cases, just a state machine) that runs the lambdas. That's what's also suggested for how one should structure Go code for testability; if you want to test something, it should be externally visible as part of the established, documented interfaces. If you're trying to externally test function internals, you are inevitably setting yourself up for a lot more maintenance headaches down the road because the internals of a function are not (or should not be) subject to control by the specification. Consider the testing approach defined by Cucumber (whose excellent Go implementation is available as "godog"). You can actually write the entire specification as a series of tests, if you wanted to. But the point is that it tests as a set of externally-observable behaviors, not relying on "this magic internal value should be set to this value". It will save you a LOT of time in the end, even if it requires significant mental effort and dragging people along with you. I spent the last year and a half trying to push changes like that at my org, and it was beginning to show tangible benefits right before the project got shut down for other reasons. Making your tests organized, consistent, readable and repeatable will make your life so much easier in the end, even if it seems insurmountable right now. And if your org is resistant to spending the time necessary to clear away the technical debt that's been built up by (probably decades of) lax engineering approaches? It's probably a sign that either you need to put your foot down more and/or sell it by noting that reduced defects means increased velocity and less embarrassing fires to put out, or you should start polishing your resume, because there are many orgs out there that will probably pay you more to do it right. - Dave -- 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/32F8B9ED-5A90-476E-9D6D-76F3A4D704CE%40gmail.com.
Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write
On Mar 2, 2020, at 1:54 PM, Warren Stephens wrote: > > I have never experienced that writing tests at the beginning saves time. I > find it is always faster to not write them in the beginning. Functionality > typically changes 3 or 4 times before it "settles down" enough that writing > tests makes sense to me. I'm not a TDD stan in the least, but I have to argue here that if this is the case, you're not spending enough time on requirements and use cases up front. You should be able to write a specification that can be tested against; if that changes in huge, significant ways such that you have to rewrite all your tests, you don't have a spec, you have a draft. I'm aware that that is the reality for a lot of engineers, having worked under both kinds of domains, but that doesn't make it right. Similarly, if your problem with writing tests for your own code refactored by someone else is that you can't understand the dataflow anymore, then the problem is that someone somewhere along the line has not sufficiently documented the code. The solution is not to enable the retroactive insertion of crutches into the internals of a function, especially since tests should be verifying that the external interfaces of the unit under test conform to the specification. Internals should not even be visible to tests, which is why they usually aren't. IMHO we should not be modifying Go to enable poor engineering methodologies, and reactive design is absolutely one of those. - Dave -- 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/90C6F1DB-92E3-4161-86D4-3D79836A1F4D%40gmail.com.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
On Feb 20, 2020, at 8:35 AM, Manlio Perillo wrote: > > This is not a matter of style. It is a matter of having clean diffs in > commits. It is both. You may prioritize clean diffs, and I understand your reasons for that. Many other people prioritize readability over clean diffs. Neither side is *wrong*, because it's all subjective, but I think it would be better to get some sense of how it would affect users either way before committing to a path. Otherwise, you will wind up with pitchforks and torches. My belief is that the status quo is actually the best compromise, but I'm willing to be convinced otherwise. However, I'm unlikely to be convinced that a new "magic" tab that won't be supported by the vast majority of existing editors, terminals, printers, browsers and the like is going to be the solution. You could always split the baby and use a default tabstop of, say, 30 or 40 columns and let longer identifiers just run over. That's unlikely to really satisfy anyone, but it's equally unlikely to dissatisfy folks to the extent that changing to a single space will. Note that any change made is going to wind up producing ENORMOUS superfluous diffs the first time anyone uses it on existing code that's already been formatted, not unlike the problem of converting hard tabs to spaces or vice versa, so bear that in mind. - Dave -- 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/81701ED1-D431-4B36-8E6D-0E4FF8EB763C%40gmail.com.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
On Feb 18, 2020, at 9:15 PM, Wojciech S. Czarnecki wrote: > > [1] use marker relative to the opening brace hinting at the desired comment > position, ie. compute type-start position relative to the opening brace then > comment-start position relative to the marker from the comment of the brace > line. Adjust both positions modulo 8 rounded up. Field name that gets over > past the established type-start position stays over. If I'm understanding what's proposed here, I think I like it. The other option would be a wider fixed tab stop, but no one is ever going to agree on what that should be (but it worked for Fortran 77, I guess). - Dave -- 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/15D2D587-2593-447D-B81B-B485F58F3255%40gmail.com.
Re: [go-nuts] Go without garbage collector
On Feb 13, 2020, at 1:45 PM, Robert Engels wrote: > > Swift uses GC - it uses a reference counting GC which has been proven to be > inferior compared to tracing collectors - especially in concurrent > environments. Not to mention cycles. Worth noting, too, that Swift does this largely because it inherits its default runtime from Objective-C, which started as a manually refcounted language and added automatic refcounting GC-ish behavior later in life. Swift was designed to be a more intuitive replacement for ObjC, so it inherits most of its benefits and curses. - Dave -- 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/F2055F9B-BF0D-47AD-B269-AF19F048FE36%40gmail.com.
Re: [go-nuts] Re: arm64 builder on raspberry pi 3B/3B+
As does Armbian (armbian.com). I dare say they're my favorite ARM distribution for getting stuff up and running on generic ARM boards; their default SD card installs mostly Just Do The Right Thing (including automatically expanding the filesystem on first boot to fit), and the hardware support is generally some of the best you'll find. - Dave > On Feb 12, 2020, at 4:02 AM, Liam wrote: > > The archlinuxarm.org project has great support for a variety of arm64 boards. > > > On Tuesday, February 11, 2020 at 7:33:04 PM UTC-8, kortschak wrote: > I have been wanting an arm64 builder to do local testing for Gonum > recently. Unfortunately, though RPi 3 and 4 have 64 bit cores, Raspbian > is 32 bit, so they don't satisfy. > > However, I found this article[1] which goes through installing a UEFI > bootloader and vanilla Debian Buster install on 3B/3B+. > > I tried it out yesterday and it worked perfectly (making sure to follow > the instructions to the letter). > > There is also a UEFI bootloader setup for the RPi4[2], but it is > currently experimental. > > Dan > > [1]https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html > [2]https://github.com/pftf/RPi4 > > > > -- > 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/a791b76b-9027-4a32-a744-dde89ffed242%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/306B4793-687A-403F-82D0-67BD51847E4C%40gmail.com.
Re: [go-nuts] Go without garbage collector
> On Feb 12, 2020, at 10:10 AM, Henrik Johansson wrote: > > Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better > so that particular example isn't really helping the GC case. > > I don't mind the GC myself but I hear the "GC is actually faster" often and > it seems not to be true in the wild although I am sure theoretical cases can > be envisioned. GC *can* be faster, but it depends on the workload. I don't believe in universals here. If you have a lot of random allocations, and a GC/allocator that's designed for that, it's great. Go works well for random-access workloads; it tends to have some issues with database workloads, which have more linear allocations and a different object lifecycle. Check out the discussions on caching algorithms for dgraph for some very interesting points of view on that. People resigned themselves to writing custom allocators for purpose-specific things in the game engine world in C/C++ a long time ago. In Go, you could do the same for specific use cases if you wanted as well, though you'd lose the advantages of GC (though I'd argue that in a database, if you can't track the objects you own, you're in for a world of hurt anyway). Interacting with the allocator, as well as OS-level virtual memory structures, has long been a facet of database and similar design in the C/C++ world, and it's only escapable in the higher-level language world (e.g. Go, Java) if you want to avoid any discussion of performance issues. If you haven't had to consider structures like B-trees and B-heaps to optimize for various virtual memory scenarios, you haven't delved deeply enough into the problem space to be talking about whether GC is "better" or not, and once you have, you'll probably realize that there's not a simple answer to that. - Dave -- 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/CEEF5C7A-D698-4F18-BB7F-F038569BEAEA%40gmail.com.
Re: [go-nuts] Why Discord is switching from Go to Rust
On Feb 7, 2020, at 7:24 AM, Everton Marques wrote: > > I think Go is way better than Rust, but it is amusing to see why people pick > one over another. I think they have very different use cases. Rust is fundamentally a functional language, which suits it quite well for things functional languages excel at (which definitely includes most server functionality). Go is a mostly-imperative language, which makes it excellent for general purpose (and it does pretty well at server-oriented stuff as well). Rust also has some concrete safety benefits over Go, largely down to the compile-time dataflow analysis that prevents a lot more hazards like data races, to which I've found Go is still quite susceptible. There's been a lot of talk here about the effect of GC, and I think that's accurate, but it's worth noting that Go's GC is designed to make *initial* allocations very fast, which actually can give it a significant edge over many non-GC languages if they haven't come up with an allocator optimized for low latency (this is very popular in C/C++ game development because malloc() is not usually fast). Correspondingly, the rather heavy requirements for the Go runtime make it a lot less practical for small embedded use cases (though not impossible, as recent list traffic indicates). If I were building a small (think <=256k RAM) embedded system these days, I'd probably go with Rust, largely because I've come to recognize that the undefined behavior in C/C++ makes writing definitively safe code impossible. As always, use the tool appropriate for your use case, otherwise you get Perl's "when all you have is scissors, everything looks like a nail" problem. There are appropriate use cases for Forth. Language "quality" is a vector quantity, and trying to reduce it to a scalar does everyone involved a disservice. That said, if I were to describe my ideal language for modern PCs and/or servers, it would probably be "Rust, but more stable, with channels and Goroutines", so I am somewhat biased. Maybe someone can make an LLVM target or something for the Go runtime that makes something like that possible, but I sure don't have the time. - Dave -- 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/2A183438-E5DE-41DE-B464-78C2176F584D%40gmail.com.
Re: [go-nuts] [Proposal] Change how gofmt formats struct fields
On Feb 1, 2020, at 9:00 AM, Manlio Perillo wrote: > > On Saturday, February 1, 2020 at 12:45:23 AM UTC+1, David Riley wrote: >> Please don't do this. Or make it an opt-in. This is not a good change to >> force on users by default. >> > > You are right, thanks. > I guess the only possible solution is for gofmt to not align the fields, > using only one space character between field name and field type. I don't know if that's the *only* solution; I think the current solution isn't terrible, even if it does lead to somewhat larger diffs when things are changed. The fact that it already only aligns them in a "clump" makes it a bit easier to segment those changes out. The status quo is not, IMO, terrible (though again it is just my opinion). Single space would definitely be preferable to single tab, since that's already fairly prevalent and reasonably legible. It ain't always pretty, but it gets the job done without a lot of weird jumping all over the place like tabs would invariably do. If computing had evolved differently to the point where there were actual canonical tab stops at, say, 4 and 50 columns instead of just every n columns, this would be a fine proposal. Alas, we have the ambiguous settings we have today. This is, perhaps, one opportunity Unicode has to remedy things, but relying too much on fancy Unicode features to render code that is generally understood to be "sort of flexible ASCII", as Go is, is also a minefield when it comes to compatibility with existing tools. - Dave -- 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/50460D06-D16E-46A5-A31D-B9CE52D247CD%40gmail.com.
Re: [go-nuts] [Proposal] Change how gofmt formats struct fields
On Jan 30, 2020, at 8:46 AM, Manlio Perillo wrote: > > Yes. > > In fact I wrote that alignment should be done by the editor, not gofmt. In this scenario, the editor needs to understand Go formatting and apply special formatting to tabs within struct fields? I strongly discourage this. It will also make structs look TERRIBLE when viewed as plain text (witness the large corpus of C code which is only legible when viewed at a specific tab width because their authors used this approach). Go's current hard-tab predilection works currently because tabs are always starting at a constant left offset (0) from the start of line; this is not the case in struct fields, variable declarations, etc. Please don't do this. Or make it an opt-in. This is not a good change to force on users by default. - Dave -- 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/3D13001F-03D8-474B-9418-EBC84547EDE9%40gmail.com.
Re: [go-nuts] Go security bugs database
I strongly agree this would be beneficial. I’ve discussed this exact concept with my employer before, because it’s an area we have scanners for with older languages, but not Go. I do believe Snyk offers a commercial version of this service, but a public, official, well-vetted repository that is machine-readable would be EXTREMELY welcome. And before we get into religious wars, no, package scanning is far from a panacea, but it does help catch the low-hanging fruit early, and the popularity of (generally non-Go) exploits out there taking advantage of years-old known-vulnerable libraries indicate that widespread availability of such scanning is a good thing. - Dave > On Jan 20, 2020, at 14:34, Manlio Perillo wrote: > > > In https://research.swtch.com/vgo-why-versions, Russ Cox wrote about an > hypothetical database of bugs in Go modules. > A tool can query the database, extracting the list of modules used in a > binary built with Go. > > Such a tool can be probably be written today, using, as an example, > https://www.cvedetails.com/ and GitHub Security Advisories. > For querying a CVE database, the tool can use the last segment of the module > import path (not sure if there are more than one module in a repository). > For querying github security advisories, the tool can find the actual > repository associated with the import path, and then query GitHub (this > information *could* be reported by go get). > > The problem with the CVE database is that the query needs manual verification. > The problem with GitHub is that not every Go module is on GitHub and not > every Go modules use the security advisory tool. As an example: > > - https://www.cvedetails.com/cve/CVE-2016-9123/ go-jose is on github, but > there is no security advisor issued > - https://www.cvedetails.com/cve/CVE-2019-14255/ go-camo issued a github > security advisor > > IMHO, it would be useful to have an official security bug database for the Go > ecosystem, e.g. security.golang.org. > > > Thanks > Manlio Perillo > > > > > -- > 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/900e05da-303f-4bf0-99e2-e3a24773da82%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/AF746910-B6EB-4CB8-9117-2614AD63D81F%40gmail.com.
Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends
I'll be interested to see how this trend goes when they FINALLY pull the plug on Python 2.7 and everyone who's been kicking the can down the road for the better part of a decade finally has to figure out which third-party libraries are breaking. Python is better for some things, Go better for others. Python makes a good first language; Go does not. That affects numbers, too. Go apps are MUCH simpler to deploy than Java or C# or Python apps, but that's going to matter more for enterprise users with a good release process than hobbyists or business users whose deploy is "scp a bunch of files over and reboot", which is more than you'd think, sadly. I don't trust popularity metrics that treat vector quantities as scalars. I'm not going to lose much sleep over this. - Dave > On Jan 15, 2020, at 8:16 PM, Liam wrote: > > That could affect the level of a term, but wouldn't impact its trend much. > Trends are the important insight of this graph. > > On Wednesday, January 15, 2020 at 2:58:31 PM UTC-8, Robert Engels wrote: > > Please look deeper into how these "trends" are calculated. > > For example, if everyone that uses product Y can't figure out how feature X > works, and they search for it. Product Y will be showing growth... > -Original Message- > From: Liam > Sent: Jan 15, 2020 4:18 PM > To: golang-nuts > Subject: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends > > My point is that Go should be rising, since Java & C# are falling. Python has > gained significant mindshare, and Go is way better. > > I think something's amiss with the public perception of Go, but it's hard to > say what. -- 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/0C78DFFC-2A7D-4459-B347-8BAFF58AE104%40gmail.com.
Re: [go-nuts] Re: A question !
On Jan 7, 2020, at 04:44, Motaz Hejaze wrote: > > > Thank you all guys for your help.. > > May i ask what is the best deployment for more performance ?? I’m not quite sure what you mean. Do you mean what environment results in the highest-performing Go programs? I’d imagine the s390x architecture represents the biggest hammer, but it’s not one I’d suggest unless you know you need it. Running on OS X and Linux (on any supported architecture) will likely yield the best mix of performance and pleasant development experience. But Go runs fine (modulo certain low-level compatibility issues) on Windows, FreeBSD, NetBSD, OpenBSD and a variety of other systems as well. Deploying for production will likely be easiest with Docker containers or the like, albeit at the normal (relatively small, mostly) performance costs associated. You can deploy directly as a regular application, with all the associated maintenance issues that may involve. What is the angle of your question? -- 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/B2C596C5-67D1-4722-B418-B3BFF321C1FE%40gmail.com.
Re: [go-nuts] Need help to learn go lang
This may be a controversial opinion on this list (maybe it's not, I don't know), but I've never thought Go is a particularly good first language. It's an *excellent* language, but I've always said the same thing about it as I did about C/C++ and Java: there's just a touch too much arcana for it to be particularly beginner-friendly. Much of that is because it's aimed squarely at experienced programmers and isn't meant to have training wheels which eventually hem you in. But I'm biased; I grew up using BASIC on Apple IIs, which was a really great introduction to programming. I feel like the modern equivalent to that is Python or Ruby, or anything where you don't really need to declare a special function that happens to be the thing that runs first. After learning the basics of programming (what's a loop? what's a conditional? how do I write something to the console?), Go makes a very good second language, and tour.golang.org makes a great introduction. But it does assume some prior programming knowledge. If you'd like, I'd be happy to point you toward some good tutorials and/or books. But that's decidedly out of scope for this list. - Dave > On Jul 19, 2019, at 9:50 AM, Veeresh Reddy wrote: > > Thanks much . To be honest I have not wrote any code so far but I wanted to > start of with Go Lang . Pleade suggest me some accordingly . > > On Fri, 19 Jul 2019, 7:15 pm Brian Hatfield, wrote: > Hi Veereshreddy! > > Welcome to Go! > > Here's a collection of links that I put together for some of my teammates who > are new to Go: > > Basics / Introduction to Go > > GoByExample is a great resource if you've got experience with 2+ programming > languages already. It quickly showcases langauge syntax and features, but is > relatively spartan in its presentation. > > The Little Go Book is a more thorough book-style approach to Go for folks > with less diverse programming language experience, or for folks who find > GoByExample to be too spartan. > > The Golang Tour is the official interactive introduction to Go. It leverages > the Go playground, which lets you run Go right in your web browser. > > Intermediate Go > > These links deal with the practicalities of writing Go, and > encourage/discourage various implementation patterns observed in real world > use. > > Effective Go is officially provided documentation that gives tips for writing > clear, idiomatic Go code. "Effective Go" is generally regarded in the Go > community as particularly helpful. > > Go Code Review Comments is a laundry list of common mistakes, not a > comprehensive style guide. It's great for beginners and advanced programmers > as it explains the rationale behind its guidance. > > Practical Go: Real World Advice presents an excellent overview of the > practice of software engineering in Go. Some overlap with Effective Go and > Code Review Comments, but with more explanation and memorable quotes to > describe patterns. > > > On Fri, Jul 19, 2019 at 9:39 AM wrote: > would anyone help me out how to learn go lang more practically , may be some > resources . I want to understand go lang more practically , with some great > examples. > > 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/4cb7eae4-b6d2-4454-9d4a-2fe7790cf685%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/CAEZF3R8FQ%2BL2z3O7W0nTJZidj%3DyQPCxEFQmwStikeodP2iN0rQ%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/1D9C791B-777B-4899-A88E-1F624EA8E148%40gmail.com.
Re: [go-nuts] Re: Project Layout Question
On Jun 11, 2019, at 13:38, Ronny Bangsund wrote: > > > >> On Tuesday, June 11, 2019 at 2:47:44 PM UTC+2, Boris Mühmer wrote: >> Is the project layout total rubbish? > > I'm not sure - all I know is that it's different from how I prefer it, and > "pkg" is the one thing I frequently see people dislike ;) > If you want to share packages, parent them to the project directory. Anything > you feel is too niche you can hide inside internal/. Binaries in cmd/ makes > it nice and tidy, but you can get away with top-level main packages if > there's only one command and it's really simple (few source files to clutter > it up). This layout is, I feel, most useful for large projects which build many binaries and have many packages (which is what we use it for). In that context, it’s great. > I might make a server cmd the same name as the project directory, and if > possible, make it have CLI options to control itself (talk via local socket, > gRPC, REST, whatever). Pleasing VS Code is mainly about configuring the build > task(s). I like to have Release and Debug tasks, sometimes with tasks > requiring other tasks (client-server projects, for instance). One thing I’ve found it doesn’t work especially nicely with is things that have files hardcoded to be in `pwd` (the common “task” utility is an example of this), because then you get your nice, tidy top level cluttered with dreck from your tools. Also, `go test` runs its commands from the directory of the tested package, not the current working directory, but that gripe is better hashed out elsewhere. > I haven't looked closely at the current state of modules to say anything > about how it'll change up my standards, but it looks like we're expected to > run module stuff out of the top-level directory. If not, aren't those parts > better off breaking out into their own standalone projects? Running module > setup in sub-directories with potentially different versions of external > dependencies feels dirty. It works fine with modules, at least assuming your repo directory is one module! We haven’t tried it with sub-modules, mostly because that feels like madness. - Dave -- 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/174A6172-8A4B-47F0-9C49-F54A7D1B17A8%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Marshaling to JSON and dynamically choosing fields
There are other JSON packages (jsoniter, gojay come to mind) which may do more of what you want. The standard library's JSON package is fine for simple things, but because it relies on struct tagging, it's not terribly well suited for situations where you want to separate the serialized representation from the internal data (e.g. it gets a little crowded if you need to map to other formats (maybe you also need XML and something else), and it's right out if you're separating a REST interface from business logic). None of the off-the-shelf packages do *exactly* what I want to do in those regards, but gojay comes pretty close. https://github.com/francoispqt/gojay https://github.com/json-iterator/go - Dave > On Jun 1, 2019, at 10:58 PM, hieuht...@gmail.com wrote: > > Have you solved this? > > On Monday, December 17, 2012 at 9:03:50 AM UTC+7, Boris wrote: > On Sun, Dec 16, 2012 at 5:45 PM, Dustin Sallings wrote: > Boris writes: > > > I have JSON web API that accepts fields URL parameter, like this: > > > > GET /something/?fields=a,b,c > > > > This is common pattern in web APIs to send partial objects instead of > > full objects. Suppose struct has fields a,b,c,...z, I don't want to > > fetch all fields from database, marshall, send, unmarshall, etc. I > > know I can add tag to struct fields to suppress them in JSON, but that > > is done at compile-time. Is there a way to do this at run-time, or > > should I write custom marshaller for this? > > You need to implement a custom MarshalJSON for your object that > considers some internal fields you configure to specify which parameters > are emitted. > > > Interesting, so http://golang.org/pkg/encoding/json/#Marshaler is the way to > override default marshaling. I guess I will implement some helper function so > I don't re-implement this for every single struct type I use, and have an > internal field in the item, which I set to indicate which fields to include. > If anyone has anything else to add, like an example implementation or tips > for efficiency, I will appreciate. > > Thanks > Boris > > -- > 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/09b0a4c5-92a6-4948-aae9-77cc713d4438%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/1F8B9E51-09E6-49B4-ABDB-673E820A7426%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types
Because Min and Max are very good and simple indicators of whether the mechanism is generic enough to handle a fairly common idiom: small functions for similarly behaved items, say comparable items, which are annoying and repetitive to write for every data type which might support the operation (not to mention the fact that increases the surface area for errors). It's also worth noting that if Min and Max can't be written in a generic system, it's likely that Sort can't, either. If the purpose of a generic system is to reduce repetitive code in a readable way, it's probably not doing its job very well if it can't do Min and Max. They're good canaries. - Dave > On May 31, 2019, at 9:06 AM, Robert Johnstone wrote: > > Hello, > > I'm not sure that Min and Max need to be in the 80%. It's annoying to write > them repeatedly, but they are also very short. The place where I typically > miss generics is larger chunks of code, such as concurrency patterns. I'm > certain others are looking at datatypes. Why do Min and Max need to be in > the 80%? > > Robert > > > On Thursday, 30 May 2019 14:26:34 UTC-4, Ian Lance Taylor wrote: > One of my guidelines for an acceptable generics proposal is that > people can write Min and Max. Your proposal admits that it doesn't > permit that. I think that is a problem. I'm fine with the general > idea of "do 80% of the job" but in practice people really do want to > write Min and Max. I think they are part of the 80% that needs to be > handled, not the 20% that can be omitted. > > -- > 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/e91e761e-92cd-452a-a387-e0741ebacd66%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/A5807C0F-B951-45A1-9EBE-00629FE40B22%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types
On May 30, 2019, at 2:25 PM, Ian Lance Taylor wrote: > > One of my guidelines for an acceptable generics proposal is that > people can write Min and Max. Your proposal admits that it doesn't > permit that. I think that is a problem. I'm fine with the general > idea of "do 80% of the job" but in practice people really do want to > write Min and Max. I think they are part of the 80% that needs to be > handled, not the 20% that can be omitted. I agree strongly with this metric. My principal reason for wanting generics is precisely so I can avoid writing the kind of repetitive code that I currently need to write to perform the exact same simple operations on similar datatypes. Min and Max are perfect examples of that, Map and Filter are slightly more complex ones. If I can't write Min and Max for generic data types, I'm not using it. YMMV. - Dave -- 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/BC671E96-348F-409A-A24B-AD9DCE21783F%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] How to constant ?!
On May 28, 2019, at 8:12 AM, Ashutosh Baghel wrote: > > Hello folks, > > I want to declare a few variables constant. But I guess there is nothing as > "Constant" type in GoLang. How do I achieve this in GoLang? https://tour.golang.org/basics/15 -- 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/28D8407C-68A0-4839-8E42-E94A2680E0D4%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: the Dominance of English in Programming Languages
On May 18, 2019, at 05:59, ma...@madra.net wrote: > >> On Saturday, 18 May 2019 00:44:33 UTC+1, Rob 'Commander' Pike wrote: >> jail is a clear improvement over the ludicrous gaol... > > I hadn't actually realised that GAOL vs JAIL was a British vs. US English > distinction. I thought 'Gaol' was just an archaic spelling of 'Jail', as I've > only ever come across it in C19th and earlier literature. Even over this side > of the pond, 'Jail' is used pretty exclusively. Although we mostly call it > 'Prison' :-) This is OT for the list, but: I think it’s more the latter (an archaism rather than a regional distinction; jail is basically universal here because we started later). We do, however, tend to distinguish somewhat between “jail” and “prison”; the short version is that jail is temporary holding while awaiting trial, while prison is more permanent punitive containment post-sentencing. I’m not sure if that distinction exists as much overseas, and in colloquial US English, saying that someone is “in jail” is often used for both situations (I, myself, enjoy our more colorful slang such as “in the pokey” or “up the river”). - Dave -- 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/A89B99F0-1753-4D8F-81FE-9A6C26A2FDC9%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go if else syntax .. suggested replacement
On May 12, 2019, at 06:55, Jesper Louis Andersen wrote: > > I don't think there are developers who find it unreadable once they know the > logic of that operator. However, if you don't know the rules, then it looks > like black magic. > > In large software developments, consistency beats convenience almost all the > time. You can somewhat easily add another developer, if the notation rules > are consistent. Whereas clever notational convenience costs for every > developer you add to the project. Giving people a choice means you have yet > another section in your style guide to understand and maintain. > > The deeper observation is that in a language with two syntactic classes, > statements and expressions, you can opt to have an if-like evaluation in the > expression class, or you can omit it. Go does the latter, where C does the > former. Of course, you can also define your language with a single syntactic > class. In that case, the above example can be written > > let color = if temperature > 80 then "red" else "green" in ... > > This style is used in a large selection of languages, which people often call > "functional languages". Though the lines of when something fits into the > moniker is somewhat blurry. As it happens, I did get to ask Ken Thompson about his reasoning when he presented at VCF East last weekend. Ken said, as close to verbatim as my week-old memory gets, that they were “too hard to compile right without the possibility of introducing subtle bugs”. I didn’t press further, because there were plenty of people in line to talk to him and I didn’t want to be rude; my assumption is that he was talking about either order of expression execution, or the difficulty of lumping the subexpressions together. He definitely didn’t have anything to say about their potential for abuse or about them being confusing to new programmers, but then we also didn’t talk long. Just adding that since I said I’d ask about it a few weeks ago. BTW, the video of his keynote chat with Brian Kernighan is not to be missed; I was working the audio, so sorry about Brian’s levels, but he was feeding back so I couldn’t turn him up any louder: https://m.youtube.com/watch?v=EY6q5dv_B-o - Dave -- 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/4EF0A6BE-E1A6-4844-A297-07BE31BA07A9%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Running tests in read-only containers
> On Apr 27, 2019, at 1:11 AM, Constantin Konstantinidis > wrote: > > Your description seems to relate to this issue > https://github.com/golang/go/issues/30667. It does indeed! It would be great if there were also a way to prevent it from trying to modify the cache, or at least to be less noisy if that fails. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] cracking the go language aplication
On Apr 26, 2019, at 07:12, smn shilla wrote: > > Hi > any luck please Your request (“how to crack the Go application.exe”) is vague, and it is not immediately clear that you’re asking for help that people here might be comfortable giving. If you’re interested in reverse engineering Go applications, I would suggest taking a look at radare2 (or Ghidra, if you trust my country’s intelligence services not to backdoor an application they’ve publicly released) and one of the millions of tutorials on binary reversing, then delve into the considerably smaller number of tutorials/papers written on disassembling Go apps, which are somewhat different than most others. What you’re (probably) asking about is a long and fascinating journey with a potential lifetime of learning and adaptation. It’s a lonesome valley worth walking, but as they say, no one can walk it for you (though you do not, in fact, have to walk it by yourself; there are lots of communities for this sort of thing). In the meantime, I’d recommend asking more specific questions; if it is difficult to specify because of language difficulties, I’d be happy to recommend/help find reversing groups in your native language who may be able to guide you better. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go if else syntax .. suggested replacement
On Apr 26, 2019, at 2:12 AM, Mike Schinkel wrote: > > Given that, I am curious what your thoughts would be if this were possible in > Go instead? > >color := if temperature > 80 then “red” else “green” > > And especially if this formatting were valid: > >color := if temperature > 80 > then “red” > else “green” That is pretty close to how Python added a ternary operator: foo = bar if a==b else baz More Pythonic, but same potential for abuse (no one is gonna stop you from nesting expressions). - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Running tests in read-only containers
Hi all, We have an unusual issue owing somewhat to Jenkins' rather odd (but understandable) method of running things in containers. Jenkins, when it runs things in Docker containers through its pipeline plugin, volume-mounts the workspace directory at the same location as it is in the host system (problem #1), and then it runs from that directory using (by default) Jenkins' UID/GID (problem #2). The reasoning for some of this makes sense, after a fashion: if you force the UID to be either root or the UID used by your container by default, any artifacts you store in the bind-mounted area for later consumption by Jenkins have those permissions (if it's even possible), which then often can't even be removed by the cleanup process, leaving you with a royal mess. Ask me how I know. Our build process, for a multi-application set of containers built from a single repo, is as follows: - Build "gobuild" images with Go compiler tools and needed distro packages (based off of golang:alpine for Alpine, and base Centos with a directory structure roughly mirroring golang:alpine) - From the "gobuild" images, for each distro, build a "gobase" image by copying in the repo source, downloading the dependencies with "go mod download" (and "go get" for required Go tooling, like mockgen), generate the generated files, and build/install the binaries in a known location using "go install" - Based on that image (for each distro), copy the application images and required assets into separate, fresh minimal-runtime container images per app to minimize image size This generally works pretty well when we're building locally, and we can run the "go test" run off of the "gobase" image (which is part of why we build everything in a single image in the first place). However, when building with Jenkins, we run into a problem: the parts of $GOPATH created by the "go" user used for the build (including $GOPATH/pkg) are effectively read-only to everyone but the "go" user, including Jenkins. So is the original build directory, though that's a secondary concern because the volume-mounted workspace area at least has the same contents, except for what's been generated. The problem here is that there doesn't seem to be any way to tell the go command to not even try to update the modules, and when it does, at the very least it is extremely noisy about not being able to update the mod cache. In Go 1.11, we're still able to run the tests after that, it just jams up our log files. But in Go 1.12, it fails when trying to write to go.sum in the local directory regardless of whether anything has changed. Is there anything I've missed that can make Go just trust that the modules are good to go, so to speak? We've tried "-mod=readonly", and it does... basically nothing to change this situation. In theory, we could go to the extent of also building the test executables in the build phase and running them that way, but it seems like we should be able to build from a read-only tree and tell Go to just fail if something doesn't match up. So far, there doesn't seem to be any way to inhibit the writes to go.sum (and I did spend about half a day looking at the source that drives that section without much luck, though I'm not sure if it's possible to redirect go.sum to a different directory). I recognize that this is a sort of weird use case, but it does seem strange that there's no way to run the build that guarantees Go won't try to modify a source file (go.sum included, but also the packages). Building from read-only storage isn't *that* out there. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go if else syntax .. suggested replacement
On Apr 24, 2019, at 5:25 PM, andrey mirtchovski wrote: > >> I may easily misremember, but that doesn't match my recollection. I >> don't remember what position Rob and Robert took, but as I recall Ken >> was generally opposed to the ternary operator. He had been in part >> responsible for adding it to C, and felt that it had been a mistake. >> >> Ian > > I am happy to stand corrected. I believe it was an offhand comment by > either Rob or Russ in one of the early Go talks. Unfortunately hard to > find 10 years later, especially in non-transcribed videos. Well, Ken is giving the keynote at the Vintage Computer Festival East this year, maybe I can ask him then. :-) - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go if else syntax .. suggested replacement
On Apr 24, 2019, at 12:34 PM, Marcus Low wrote:
>
> On Wednesday, April 24, 2019 at 10:08:53 PM UTC+8, Mark Volkmann wrote:
>> Are there really developers that find this unreadable?
>>
>> color := temperature > 80 ? “red” : “green”
>>
>> I know what you are going to say. People will nest them. But even nested
>> usage can be readable when formatted nicely with one condition per line.
>> Another alternative is to allow only unnested ternaries.
>>
> color := map[bool]string{true:"red",false:"green"}[temperature>80]
> Here you go.
Pardon my bluntness, but it is silly to assert that this is anywhere near the
readability of the ternary statement. The entire point of the ternary
statement is that it is concise and spartan; this is cluttered and overwrought.
Yes, people can (and will) abuse it. That doesn't seem to have stopped us from
having a reflection library, which is arguably much worse for readability and
more pernicious compared to ternary statement abuse.
There are very few cases where you can force good coding hygiene by removing
language features. This isn't one of them. If you wanted to force good coding
style, put a check for nested ternaries in go vet along with other readability
issues.
- Dave
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go if else syntax .. suggested replacement
On Apr 24, 2019, at 8:04 AM, Mark Volkmann wrote:
>
>
>> On Apr 24, 2019, at 6:22 AM, Robert Engels wrote:
>>
>> Though to the ops point, not sure why Go doesn’t have the ternary operator -
>> which is pretty ubiquitous.
>
> The idea of adding the ternary operator to Go has been debated many times.
> It’s clear that those in charge have a strong dislike for it. For me the lack
> of the ternary operator is one of main things I dislike about Go. It’s nails
> on a chalkboard for me to write a five line “if” statement when it could have
> been a one line assignment statement.
I enthusiastically concur with this. I understand the antagonism toward the
ternary statement to a point, but there are some things that it just makes
about a million times easier without sacrificing readability:
fmt.Printf("This parrot is %s.\n", is_dead ? "pining for the fjords" : "alive")
This isn't just a toy example. Nothing (to my mind) is unclear about this
statement.
I run into this sort of thing every day; the main thing the ternary statement
relieves me of is either writing convoluted if/switch/map statements when a
single line would do, or repeating myself. I'd have to do one or the other to
resolve the above one-liner, and it wouldn't enhance readability in the
slightest.
- Dave
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go+ replacement
> On Apr 23, 2019, at 12:52 PM, Darko Luketic wrote: > > But Twitter is a loose group of individuals, or does it have group > functionality now? Everything is done via #channels last time I checked. > I honestly very rarely use it, too small sized posts, it's very chaotic and > stuff you've seen just now is gone after a reload and can't be found again. > Also it's always so political and full of journalists, so hipster, all show > no substance. > Anyhow what channels or "hashtags" do you subscribe to, or can you even > subscribe to hashtags? I just follow a lot of folks who talk about things I'm interested, which occasionally includes Go? It's not what I'd call "organized", I guess, and I never follow hashtags, but everyone has their own preferred interaction styles. I find I can ask about Go, k8s, Rust, whatever and there are people who will answer things. Make whatever value judgments you want about it, but I do find some utility there. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go+ replacement
On Apr 21, 2019, at 9:02 PM, icod.d...@gmail.com wrote: > > I don't know about you but for me, even if there wasn't so much going on, > Google+ and the Go+ community was a source of info. > > Reddit is reddit, this whatever it is, is what it is, mewe can't replace > G+. > Facebook just isn't the crowd. > Xing and the like just aren't made to handle the task of staying informed and > people presenting their work. > > An essential source of information has disappeared. > What is there to replace it? > > People would post links to youtube videos there, some were quite interesting > and some were fresh from the horses mouth about whatever conferences or > happenings. > It's all gone now. > > Nuts is more of a "help I have a problem" thing. > > I know, Google+ had its own issues, the biggest was them forcing changes onto > their users no one wanted. > As a result most people stopped using it and in the end it disappeared. > > G+ did fill a nieche, that of the enterpreteur who also wanted to be > entertained and catch news, stay up to date. > > I know this post is kind of pointless, since it won't change what is. > But maybe something exists that I'm unaware of I actually find that the Go community on Twitter fills a lot of those roles for me fairly well. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] floating point question
On Apr 16, 2019, at 2:29 AM, Miki Tebeka wrote: >> >> On Monday, April 15, 2019 at 7:59:28 PM UTC+3, David Riley wrote: >> On Apr 15, 2019, at 12:47 PM, Miki Tebeka wrote: >> > >> > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: >> > >> > 1.1*1.1 and 1.21 are untyped constants and have much higher precision at >> > which they are not equal. >> > Does that mean that the Go compiler is using floats with more precision >> > than the runtime? >> >> Yes, but it's also worth remembering that in general, in computing, it's not >> a great idea to compare floats for absolute equality except for specific >> constants (e.g. +/- zero, +/- infinity, NaN). >> >> Is there an in-built intrinsic in Go for comparing floats within an epsilon, >> or does that have to be done manually? > > I came across this when teaching about floats not being exact, was surprised > to see the "true" :) Yup! My personal perspective is that it's best to treat floating point numbers as "noisy", because you lose or add little bits to them with most operations in ways that are hard to control (this is one of the reasons IEEE floating point numbers have tightly-defined characteristics, because then at least the flaws are well-defined and you don't get e.g. diverging results in physics simulations on different machines because they round differently). Treat a floating point number as a noisy signal, always compare within ranges (often enough, even when comparing against zero, especially considering that there is also a *negative* zero in floats) and you won't go wrong. Well, not *very* wrong. Better yet, avoid use of floating point arithmetic where at all possible (but here I'm showing my personal biases). - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] floating point question
On Apr 15, 2019, at 12:47 PM, Miki Tebeka wrote: > > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: > > 1.1*1.1 and 1.21 are untyped constants and have much higher precision at > which they are not equal. > Does that mean that the Go compiler is using floats with more precision than > the runtime? Yes, but it's also worth remembering that in general, in computing, it's not a great idea to compare floats for absolute equality except for specific constants (e.g. +/- zero, +/- infinity, NaN). Is there an in-built intrinsic in Go for comparing floats within an epsilon, or does that have to be done manually? - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] go in cloud server
On Apr 3, 2019, at 11:34 AM, Shyaka Rene wrote: > > > Hello. > I'm new to go, i'm looking for a programming language to replace java. I have > simple questions > • is it a good idea to deploy go in cloud server if go is compiled to > machine binaries, what can happen if the cloud provider changes the physical > server to different processor architecture. This is a concern for Java, too, in that you have to have a JVM to run on. Go builds easily for most common cloud architectures these days (amd64, ppc64le, arm/aarch64, s390) and less easily for a few others (e.g. sparc). Do multi-architecture builds to protect yourself. If you're building for modern cloud infrastructure, you may be using Docker; Docker supports multi-architecture images, so if you do your build system correctly, you should be able to build image bundles that support a bunch of different architectures reasonably easily. It's maybe somewhat less easy than distributing a Java binary across multiple architectures, but ultimately it's probably easier than maintaining something that needs to run well across different Unixes and beyond (OpenVMS, IBM i to name a few). That said, most cloud providers aren't in the business of suddenly changing their entire processor architecture to something incompatible, unless they're Oracle. > • does go have embedded relational database management system similar > to h2 in java. google gives me key/value pair embedded database >any help is appreciated. thank you Go has lots of interfaces to lots of databases, from key/value (memcached, Redis, bdb) to relational (an flexible SQL interface with drivers for most popular RDBs including sqlite) to popular non-SQL databases (Couchbase, Mongo, etc). Others on the list have also pointed out a few other embedded ones available for Go of which I wasn't aware, so that's very exciting. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Build problems with modules in Docker
A few things. Responses inline.
> On Apr 3, 2019, at 7:05 AM, Marcus Franke wrote:
>
> Hello,
>
> I have a small project here at work, that does not compile using modules
> inside the golang docker image.
>
> The software resides inside a rather monorepo like repository inside the
> organizations private repository at github. So far, a great place for the
> modules, as I can develop the software outside my GOPATH and building it on
> my machine works great.
>
> My code resides inside this private repository inside an arbitrary path,
> which is not fully part of the name I initiated the module with. Which does
> not impose a problem when building on my laptop.
>
> My go.mod file looks like this:
> ```
> module github.com/org/repo/asm
>
> go 1.12
>
> require (
> github.com/aws/aws-sdk-go v1.19.5
> github.com/kr/pretty v0.1.0
> github.com/stretchr/testify v1.3.0 // indirect
> golang.org/x/net v0.0.0-20190327091125-710a502c58a2 // indirect
> gopkg.in/yaml.v2 v2.2.2
> )
> ```
This generally looks OK.
>
> I have a Makefile does some simple tasks for building, it creates a tarball
> of my code directory and starts a docker build -t job.
Why make a tarball? You'll get a lot more mileage out of just copying the files
from the Docker context, which Docker is already tarring up to pass around
anyway. You'll get fewer surprises that way.
In our Dockerfiles, we generally have the following as preamble (we also add
some non-root permissioning, which is more complex than you really need right
now):
# Provide arguments for the module name (required) and the
# optional module proxy for hermetic builds
ARG MOD_NAME=modname
ARG GOPROXY
ENV GOPROXY ${GOPROXY}
# Set a variable for our working directory (make sure it matches
# the module name)
ENV D $HOME/build/$MOD_NAME
RUN mkdir -p $D
WORKDIR $D
# Copy go.sum/go.mod and warm up the module cache (so that this
# rather long step can be cached if go.mod/go.sum don't change)
COPY go.* $D/
CMD go mod download
# Now copy the rest.
COPY . $D
# Run the build script, which in the end generally calls
# "go install ./cmd/$app1 ./cmd/$app2 ...etc"
RUN ./scripts/build.sh install-all -v
>
> My simplified Dockerfile:
> ```
> FROM golang:1.12
> ENV GO111MODULE=on
> CMD mkdir asm
> WORKDIR /go/asm
> ADD code.tar .
> CMD tar xvf code.tar
Careful with ADD, it automatically untars things when they're compressed
(though yes, this is not currently compressed). Again, though, there's usually
not much reason to do that; you should probably just do a COPY of the files
from your context instead.
> RUN cd cmd/asm
This doesn't doo what you think it does; it does not change the working
directory. For that, you want the WORKDIR directive. However...
> RUN go build -o asm
Instead of trying to change directories, you might want to just say go build
./cmd/asm. You'll do yourself a lot of favors if you do your builds from the
base of your repo
> ```
>
> When I execute the build, I get the following error output:
> ```
> Step 10/10 : RUN go build -o asm
> ---> Running in 243e73e7ed25
> go: finding github.com/stretchr/testify v1.3.0
> go: finding github.com/kr/pretty v0.1.0
> go: finding github.com/aws/aws-sdk-go v1.19.5
> go: finding gopkg.in/yaml.v2 v2.2.2
> go: finding golang.org/x/net v0.0.0-20190327091125-710a502c58a2
> go: finding github.com/kr/text v0.1.0
> go: finding github.com/davecgh/go-spew v1.1.0
> go: finding github.com/pmezard/go-difflib v1.0.0
> go: finding github.com/stretchr/objx v0.1.0
> go: finding gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
> go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
> go: finding golang.org/x/text v0.3.0
> go: finding github.com/kr/pty v1.1.1
> go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
> go: finding github.com/jmespath/go-jmespath v0.0.0-20180206201540-c2b33e8439af
> can't load package: package github.com/org/repo/asm: unknown import path
> "github.com/org/repo/asm": cannot find module providing package
> github.com/org/repo/asm
> The command '/bin/sh -c go build -o asm' returned a non-zero code: 1
> ```
>
> Why does the go tool try to kind of resolve the import path of my project
> itself? I thought this would be defined by the module directive in my go.mod
> file, at the source root of my project directory?
It is, the Go tool generally uses that to specify where the package "lives" if
it's working properly. This looks to me almost like it's not seeing go.mod
correctly.
>
> My repository contains two internal packages below a pkg/ directory and these
> are being imported just fine with "github.com/org/repo/asm/pkg/foo" and
> "github.com/org/repo/asm/pkg/bar" in my code. On my laptop the compiler can,
> as written above, compile the project just fine. Here it seems it does not
> fumble with finding that particular and rather virtual module name.
>
> Am I doing something wrong or did I just misunderstand the way
Re: [go-nuts] [CoC] screenshot images. Lazines or incompetence?
On Mar 12, 2019, at 7:44 AM, Wojciech S. Czarnecki wrote: > > On Mon, 11 Mar 2019 23:13:00 -0700 (PDT) > Lucio wrote: > >> It's clearly become a lot easier > > An that is the crux of the problem. > > It is so easy that it easily turns off the brain and suppress > the last faint of thought that text turned into the image: > > * is not searchable > * can neither be edited nor compiled > * is not available to the part of the population The above are more important, but I would also add: - is hundreds to thousands of times larger than the original text I don't know in what world it's "easier" to screenshot a section of the screen and attach the file than it is to highlight and copy some text, except on Twitter where there are actual character limits. Taking a screenshot of plain text is like taking a tank to the grocery store across the street. Please don't; it is inconsiderate, full stop. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Module replacement forks and Artifactory
Hi all, We're running into a bit of an interesting problem with modules. A month or two ago, we finally converted our project over to using modules, partly because it was The Right Thing To Do and partly because Artifactory supports module repositories (but not dep). The process hasn't exactly been a smooth one. We've hit a few of the interesting corner cases with modules, but none of them has been quite so pesky as the issue of replacing broken upstream dependencies with private forks. The one that's giving us the most trouble is the mock package (github.com/golang/mock); as-is, it does not support Go Modules because the stock "mockgen" executable generates code which uses relative imports, which do not work under modules. There is a fix in review for this from github.com/poy/mock, but it's been held up because the only viable fix would break Go 1.9 and below, and the author was waiting for the release of 1.12 so that 1.9 would drop from the support list. 1.12 has been released, and the fix is lingering in review (it's https://github.com/golang/mock/pull/253 if anyone is curious). Anyway, we absolutely require mockgen for our build and tests, and so we used a "replace" line in our go.mod file to point at the "poy" repo's "go-modules" branch. That fixed the problem, but caused other ones for two reasons: 1) force-pushes were being used to rebase changes onto the branch, which caused the old commits to disappear and break the build, and 2) modules can't track a branch head, they can only be pointed at specific commits based on a ref when they're first pulled. So we made a private fork of the repository at a point where it was functioning properly, which has solved THOSE problems for the time being. However, we can't get it to be cached in Artifactory's private repo (we cannot use the transparent proxy mode for Reasons) because the go.mod file in the fork claims it is github.com/golang/mock instead of /mock. This doesn't cause problems with Go, which is happy to use it as a replacement, but Artifactory won't store it (and in fact barfs if I try to add it as a direct dependency because of the mismatch). This means we can't build with GOPROXY set to the Artifactory repo, because the replacement module doesn't exist there and there's no fallback mechanism for GOPROXY, so the build just fails at the initial "go mod download". Is there a good solution to this conundrum that isn't a) vendoring, which is yucky, or b) rewriting go.mod in the private fork? This sort of situation is inevitably going to happen again when we need to make private fixes to a dependency or the like, and it would be good to know if there's either a de facto or de jure best practice for this. I recognize that this is probably a deficiency in Artifactory's module handling code (it doesn't seem to understand the "replacement" concept), and while I also recognize that this isn't an Artifactory support list, I have to imagine that someone here has run into this problem (or a similar one). Thanks in advance. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is Go a single pass compiler?
Was this book written in the '70s or '80s? Single-pass compilation is great in some ways (memory and time efficient), not in others (usability). C is (sort of) single-pass (if you don't count the preprocessor, optimization passes, etc), which is why you need function prototypes. Assemblers are very often single-pass. C is basically a user-friendly front-end to the assembler anyway, so. Languages built for the the minicomputers of the '70s and microcomputers of the '80s should be designed for a single pass, because if you were trying to do anything bigger than that it would likely take forever or exceed your available resources. I don't think that has been a valid constraint on anything for a long time unless you're planning on e.g. compiling something on an AVR (for example, Forth is a single-pass language if you squint at it hard enough, and it fits nicely on some REALLY small things). - Dave > On Feb 27, 2019, at 6:46 PM, ivan.medoe...@gmail.com wrote: > > Thanks, Ian. > > I remember reading in some compiler book that languages should be designed > for a single pass to reduce compilation speed. > > Go proves that wrong :) It's amazingly fast, looks like computers are pretty > good at traversing AST trees. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] ctrl-c and Golang
I suspect it's because your reference to the time_array is actually copying it
into your closure that's running as the goroutine instead of making a reference
to it. You might do better to pass that array as a parameter to the goroutine
instead of trying to absorb it as context.
I should note that your approach of filling a statically sized array is
probably not the best one, because that's going to eventually panic once you
hit the limit. But that's a bit out of scope of this discussion, and I'm sure
you mostly meant it for illustrative purposes.
- Dave
> On Feb 16, 2019, at 9:29 AM, Hemant Singh wrote:
>
> I have the following program. The program is processing network packets at 1
> Gbps rate. I don't want to print the rate for every packet. Instead, I'd
> like to save the rate in an array and dump the array on Ctrl-c of the
> program. When I dump the array on Ctrl-c, the data is all zeroes. Please
> see "<===" in the program below. Anything else one could do?
>
> Thanks.
>
> -Hemant
>
> func main() {
>
> const SZ = 65536
> var time_array [SZ]float64
>
> c := make(chan os.Signal)
> signal.Notify(c, os.Interrupt, syscall.SIGTERM)
>
> go func() {
> <-c
> fmt.Printf("You pressed ctrl + C. User interrupted infinite loop.")
> fmt.Printf("%v ", time_array); <=== all zeroes printed.
> os.Exit(0)
> }()
>
>
> i := 0
> for {
> ...
> time_array[i] = rate
> fmt.Printf("%f bps ", rate) <=== value printed is correct.
> i++
> }
> }
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: using docker for compiling
Yes, but we have somewhat different objectives than you might.
We use the Docker golang (alpine) image to build our images, and it works
wonderfully (and really makes it a lot easier to cope with differences in
Jenkins build nodes). However, our apps generally eventually run on
Kubernetes, which means we have a few things to consider for actual use that
other folks might not.
I should also note that for the most part, we use shell scripts to build, as
make doesn't really bring us many advantages; it can't really track
dependencies across the Docker barrier, and since they're not strictly speaking
files, it can't track the predecessor images (we use a multi-stage build
process) as dependencies, so shell scripts it is.
By way of background, our project is a collection of microservices which we
generally build at the same time for a variety of reasons (one of which is to
maximize parallelism and cache reuse). We use `go build` and/or `go install`
to achieve that, but we use `go run` when testing things.
Our build process is as follows:
- We make a "build" image for each supported distribution we build our apps for
(currently Alpine and CentOS, which have to be built separately because
Alpine's musl-libc makes the binaries incompatible with everything else). The
build image is generally the base Go image (which is the official one for
Alpine, and an equivalent cobbled-together one for CentOS) along with a basic
set of packages installed that we know we need for our build (typically git,
gcc, protobuf stuff and not much more). That image is stored locally and used
as a base for the next step.
- We make a "base" image by first copying in the bootstrap scripts (formerly to
install dep, but now just to do a bit of prep work) and the go.{mod,sum} files.
We warm up the build cache by running `go mod download`, then copy in some
secondary scripts to run `go get -u` to pull in the required Go binaries for
things like code generators needed for the build. Then we copy in the rest of
the code (we defer this to maximize use of the Docker build cache so it doesn't
fetch the dependencies every time), run the code generators with `go generate`,
and then run `go install` on all the apps we want to build (rather than `go
build` so they wind up in an easily-known location), running it on all of them
at once to build them at the same time. After that, we copy a few of the
static assets that get bundled with the apps over to other well-known locations
in the image because none of our environment variables carry over to the next
step.
- We then use Docker's newer multi-stage build capability to start from a fresh
runtime image for each app/distro combo, and copy the apps and their required
static assets into the fresh image. That way, our Alpine images tend to be less
than 15MB each (CentOS is a bit more, though in theory the base layers get
reused, though this is not always true for distribution). Because they are
microservices, each app container is built with the entrypoint simply launching
the app itself so the container terminates when the app does (which is
preferable for Kubernetes).
Now, this obviously wouldn't be ideal for rapid deployment, which is where
things start getting interesting. In theory, we could work directly from the
"base" container (the middle piece), since that has all the source and runtime
needed to run the containers, but not everyone on the team relishes using
terminal-based text editors (there's no accounting for taste). We do, in fact,
run the unit tests and benchmarks from that container and it works splendidly.
But for an edit-compile-run cycle, it leaves a little bit to be desired, so we
add a bit more on for local development.
For the iterative cycle, we do two things. First, we bind-mount our source
directory over the copied source directory in the container (yeah, it's a
little wasteful, but the image is already there and set up, so). We then run
an autorunner which watches the source files and re-runs `go run
.// ` (we use `reflex` since it worked best for our
purposes, but there are others out there including `realize` which seems to be
generally more popular). This works wonders for developing microservices in
the container environment with an editor outside the container, though getting
the regexes to hit all the right files can be interesting; you may need to
manually poke things after a `go generate`, for example. This works extremely
well even across the VM barrier of Docker for Mac, and I would assume also
Docker for Windows, since they have taken great pains to ensure that filesystem
notifications work across platforms.
For specific Kubernetes work, because we want to be able to connect to
in-cluster resources that aren't available outside the cluster as well as
connect to the API and get all the environment variables we'd get when deployed
in-cluster, it's a bit more complex. You don't want to be t
Re: [go-nuts] What does "nil implay?
On Jan 20, 2019, at 18:00, 伊藤和也 wrote: > > I know "nil" is zero values for slices, maps, interfaces, etc but I don't > know what "nil" implays. Does nil implay the absence of value or a variable > has't been initialized yet or something else? Basically yes, all of the above. This pattern dates back to C, Lisp, and other languages of computer science history, though many languages have different semantics attached. In C, NULL was just a zero pointer value that effectively stood for an empty/uninitialized value; in Lisp (or Python, for example, which has a similar None), nil is a special value of its own type that connoted an empty value, or false (there is similarly a “t” in Lisp which connotes the opposite of nil, though it is valueless). In C, NULL values can be dangerous to play around with; in Go, some effort has been made to make them useful (for example, they are treated an empty arrays, though they are not quite the same as an empty map). - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] What is nil pointer dereference?
On Jan 20, 2019, at 16:36, Burak Serdar wrote:
>
>> On Sun, Jan 20, 2019 at 2:32 PM 伊藤和也 wrote:
>>
>> type a interface{
>> m()
>> }
>>
>> type abc int
>> func (abc) m() {}
>>
>> func main() {
>> var v a
>> v.m()
>^^
>
> v is nil. It is declared but never assigned a value. You are
> dereferencing v to call m, causing nil ptr dereference.
Importantly, v is of type a, which is an interface; it has to be dereferenced
in some sense in order to get its type information in order to figure out what
m() method to call.
If you’d made v of type *abc (and m() was a method for type *abc, not abc),
this would actually be valid and would execute, but the instance pointer passed
to m() would be nil. Sometimes that’s actually something you want to do/handle,
though I would argue it’s fairly rare and more often it’s something you would
want to check as an error case.
- Dave
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Versioning golang.org/x/foo packages
Oh man, I searched in vain for any kind of discussion exactly like that issue. Your Google-fu is clearly superior to mine. Thanks! :-) > On Dec 14, 2018, at 10:08 AM, Paul Jolly wrote: > > Just to briefly note the discussion in > https://github.com/golang/go/issues/27858 (and other issues linked > within that one). -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Versioning golang.org/x/foo packages
Hi all, We're building with go 1.10.x and dep for a project at work, and having been bitten twice in the space of a week with unversioned upstream executables fetched via "go get" causing strife with versioned vendor code fetched by "dep", we've been working on making our build environment hermetic (we'll be moving to modules soon when we move to 1.11, especially because we use Artifactory, which supports vgo registries so we can protect our build chain, but for now we're stuck with dep). Our common solution for this is to make sure the tool is put in the "required" stanza in Gopkg.toml, then running "dep ensure" to make sure it ends up in the Gopkg.lock file so the Docker build can pick it up when it runs "dep ensure --vendor-only". This works pretty well for protoc-gen-go from protobuf and mockgen (the two tools that broke our build this past week), but I also want to do the same for goyacc, which lives in golang.org/x/tools. I notice that nothing from the golang.org repository is at all versioned, so as far as I can tell, it all comes from the master branch. How do I version these to ensure that they don't break with older/other Go versions? Is there some sort of guarantee that they'll work at least n revisions back? I'm already extremely skeptical about the practice of just fetching all packages from git repositories, given how easy it is to slip malicious code in that way, so requiring a "go get" for those tools doesn't exactly give me the warm and fuzzies. - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: pass interface
Ah! No, that is not possible, because interfaces (and other types) are not
first-class objects in Go like they are in some other languages (such as
Python). You can work around it, to some extent, by passing a zero-valued
instance of such an interface (e.g. PrintInterface(A{})) and using some
reflection magics to do what you need based on the reflect.Type and similar.
That's how a number of libraries like Resty determine how to e.g. deserialize
JSON to a specific type requested by users. It's got its warts, but it works.
- Dave
> On Dec 10, 2018, at 9:53 AM, Mark Volkmann wrote:
>
> Yes, this is what I'm trying to do!
> Perhaps this is not possible.
>
> On Sun, Dec 9, 2018 at 10:34 PM Robert Engels wrote:
> I think what the OP wants is:
>
> type A interface{}
> type B interface{}
>
> ...
> PrintInterface(A)
>
> Meaning they want to pass the interface definition to some method.
>
> At least that’s what I am guessing.
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Position(s) available at FireEye
Hi all, I work at FireEye on the tooling end of things, and my team needs more decent senior backend devs. Our current project is a large-ish system in Go; we're looking for experienced systems programmers, but deep proficiency in Go isn't strictly required (Go is easy enough to pick up, system-building experience less so). I'm a backend developer doing a lot of the API plumbing for the system (microservices orchestrated by Kubernetes tying several other major components in other languages together, along with the UI). Currently we could REALLY use more folks on the backend. It's supposed to be a remote position (East Coast US strongly preferred because of timezone), though I don't think that's reflected on the req. Obviously, if you're already near the Reston, VA area that's obviously a plus. This is the position on my team: https://www.fireeye.com/company/jobs/jobdescription.html?gnk=job&gni=8a78879e6626316901666366a66b4faf&jobtitle=Senior%20API%20Software%20Engineer&loc=United%20States%20Reston%20VA%2020190 We have a few others on closely connected teams: https://www.fireeye.com/company/jobs/jobdescription.html?gnk=job&gni=8a78879e6626316901665c7318254efa&jobtitle=Senior%20API%20Software%20Engineer&loc=United%20States%20Reston%20VA%2020190 https://www.fireeye.com/company/jobs/jobdescription.html?gnk=job&gni=8a78879e6626316901665c85ac4a5158&jobtitle=Senior%20API%20Software%20Engineer&loc=United%20States%20Reston%20VA%2020190 And in general, there are a number of related positions, so feel free to peruse the job board, you may find something you like if you're looking: https://www.fireeye.com/company/jobs.html Feel free to bug me for a referral, it will speed the process up (obviously, we'll want to talk first). I'm glad to make referrals for qualified candidates, including for entry level positions! We're a good company, and we treat our workers well, and I'm very happy here as an engineer. Hopefully this isn't the wrong forum for job posts, but I'm interested in finding enthusiastic developers. If you know anyone you can recommend, please send them my way (my direct email is my name, joined by periods, at fireeye dot com). - Dave -- 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. For more options, visit https://groups.google.com/d/optout.
