[go-nuts] Possible language improvement re multiple assignment
For the case of multiple variable assignment where some of the target
variables are to be created in the local scope and some are to be found in
the existing scope...
Allow:
existingVar, :newVar = 1, 2
instead of:
var newVar int
existingVar, newVar = 1, 2
That additional line for explicit local var declaration clutters the
program and could even be a bit confusing.
With this suggestion, current syntax and semantics of multiple assignment
stay the same. Use of the more concise syntax is optional, of course.
Advantages:
- More readable
- More concise
- Easier to understand at a glance -- current rules are a tad complex and
require knowledge of previously-declared variables in the current block
- Does not break existing programs
- I look at this as "factoring out" the colon :)
Disadvantages:
- Can't think of any
For me, the most common use case is where the first variable exists outside
of the enclosing block and the second is an error to be handled locally:
var err error
loopCount, err = strconv.Atoi(arg)
if err != nil {
...
Always bothers me to have to insert that "err" declaration. To me, this
seems much nicer:
loopCount, :err = strconv.Atoi(arg)
if err != nil {
...
I think the above is a worthwhile improvement and should be considered.
Thoughts?
--
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/ddd97db1-7a02-406b-b905-3f94f533d8c2n%40googlegroups.com.
Re: [go-nuts] Contrary to popular opinion...
Thanks, Amnon, for that well known quote from the Python world. Python has been one of my favorite languages for around 20 years. Even had the honor of meeting Guido while we were both working at Google a while back. Please, Python, do not integrate a dependency management system into your language and force all Pythonistas to use it! (Actually, my recollection is that quote was a swipe at the competing Perl language, whose motto is "there is more that one way to do it" :) On Thursday, February 25, 2021 at 11:38:39 PM UTC-8 Amnon wrote: > > *There should be one-- and preferably only one --obvious way to do it. * > From the Zen of Python. > But also good advice for Gophers. > > On Friday, 26 February 2021 at 01:03:00 UTC skinne...@gmail.com wrote: > >> I have a wonderful video of a GO program I wrote over 5 years ago which >> will not compile today due to my failure to vendor one lost module. I too >> had multiple paths in my GOPATH and it varied upon the client. I consider >> the new modules an improvement but the adaptation has not been without pain. >> >> For students who are experimenting and testing and trying things, and >> only running and compiling locally, a single experimental repository with a >> doc.go file and v0.0.0 module for an experimental pkg and cmd works very >> very well and if they do create a useful abstraction then they can refactor >> and publish the result with ease at the end of the semester after they have >> a mastery of the language. >> >> I have a student using vscode and my vscode is complaining that my Go1.16 >> installation does not have a GOPATH. >> >> On Thursday, February 25, 2021 at 6:36:36 PM UTC-6 mar...@gmail.com >> wrote: >> >>> Given the writing on the wall that GOPATH is going away, what I have >>> done is created a single module where I keep all my own code, each >>> different experiment in its own subdirectory. I named it "github.com/...", >>> but never submitted it to github, so in the future I can do that without >>> too much fuss if I wanted to. >>> >>> Having been writing Go heavily since 1.2, I find the >>> all-code-in-one-module approach to be the easiest so far. >>> >>> -- Marcin >>> >>> >>> On Thu, Feb 25, 2021 at 4:21 PM Bob Alexander wrote: >>> Agreed -- module mode is great for "delivered code". But in a personal single machine single developer environment, all the extra complexity and manual overhead might not worth it. I'd guess that most students and hobbyists don't even use SCMs. My point was that GOPATH mode is good for them. On Thu, Feb 25, 2021 at 1:38 PM Robert Engels wrote: > That is 100% true but a important point is that using GOPATH requires > manual dependency management via ‘vendoring’. This can be very labor > intensive and error prone - leading to security issues in your delivered > code. > > On Feb 25, 2021, at 3:08 PM, Bob Alexander wrote: > > > GOPATH mode does *not *limit your Go code to a single directory. I've > seen this misunderstanding stated in probably hundreds of various posts. > > $GOPATH allows specification of multiple directories. I've used that > capability for several years to distribute my Go code to my personal > general library and to various application-specific libraries. Each of > the > multiple GOPATH directories refers to a Go "workspace", so the result is > my > general library workspace plus mini-workspaces in various application > directories -- each with src, pkg, and bin subdirectories. A single go > install installs all workspaces specified in your GOPATH at once, or you > can selectively build by temporarily changing the GOPATH. > > This is a pretty good setup for me, a decades-experienced software > engineer working in "programmer" mode for my personal development. > > Go's goal of ending GOPATH mode sounds like a choice to serve the > professional software engineer, and not the personal programmer. Module > mode is a good thing if you are publishing your code, but is a lot of > additional labor and cognitive load for us "programmers". > > I wonder if this might discourage adoption of Go by certain categories > such as college and high school students, non-software-engineer > professionals who write internal programs for their business, and curious > folks who want to introduce themselves to Go. It is s much easier to > set up my environment with GOPATH mode. In attempting conversion to > MODULE > mode, I've spent lots of frustrating hours and it's still not working > perfectly! > > So, I am +1 for retention of GOPATH mode (as well as MODULE mode), > allowing Go users to make the choice of MODULE vs. GOPATH based on their > needs. > > -- > You received this message because you are subscribed to the Google > Gr
[go-nuts] Re: Alternate implementations of regular expression matching?
In *my* ideal world, both O(n) and backtracking implementations would be available in the standard library. Most popular languages have only backtracking versions in their standard libraries (Java, Python, Ruby). It's nice that Go has an O(n) implementation. But, some regexes that can be written in the modern backtracking implementations that support "atomic groups", etc. just cannot be rewritten for O(n) implementations, sometimes resulting in having to write a lot of code to achieve the equivalent result. The reason that O(n) implementations lack those features is that they simply can't be done without violating O(n). So why not let the programmer exercise the choice -- O(n) where possible for denial-of-service safety or maybe better performance, and backtracking when O(n) can't be done or maximum performance is not important, and regexes incoming from the wild do not happen. And... I suspect that well written regexes for backtracking can be nearly as performant if backtracking is kept under control via skillful use of those atomic features. It's the sloppy ones that are the problem. -- 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/7afca073-a3ff-464c-8de4-8b2ba7c4d214n%40googlegroups.com.
Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime?
I'm glad to see this issue getting some discussion. I have 100+ smallish utility programs written in Go, and each one consumes about 1.5 MB (precise average: 1,867,844 bytes); my bin directory contains 100+ copies of the Go runtime. Sadly, I mainly use Windows, and there seems to be no way to use linked libraries in Go for Windows. My solution has been to rewrite many of my smallish Go programs in Python (except those that really need Go's speed) -- 10K each vs. 1.5M each disk storage. For these manually invoked utilities, the speed difference is often not noticeable. And the number of source lines and overall program complexity is reduced by roughly 30%. (Added benefit: the Python programs are always properly indented, even without a "pyfmt" program :-) I *am* a Go fan, and I understand that Go's mission is for writing big server programs, but it's too bad that the size of a small Go program executable is *many* times larger than a small C program. On Sunday, January 29, 2023 at 9:49:17 AM UTC-8 jlfo...@berkeley.edu wrote: > The discussion of SSD wear and tear is going way off my original question. > I'm sorry I even mentioned it. > Can we drop it? > > I'm still interested in the answer to the original question, which we've > made some progress in answering. > As of now the answer is yes, subject to some permission and performance > problems. I hope the experts > can shed some light on these. > > Cordially, > Jon Forrest > > -- 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/3c691095-e0d8-4da5-8513-887af7b0e9b4n%40googlegroups.com.
