Re: [go-nuts] Re: C++ 11 to Golang convertor

[Drew Derbyshire]

I am reminded of someone once asked how to go from Burlington MA to 
Waltham, when what he really wanted to do was go from Burlington to Logan 
Airport.  (For the uninformed, via Waltham is not generally how most would 
do it.)

This conversation is thoughtfully covering all angles of the C++ to Go 
problem, but I may suggest one steps back and defines the ORIGINAL problem 
being solved and the requirements of the solution.  (Not the approach, and 
certainly not the design, but the basic requirements.)

What is the C++ doing which is required, and why does it have to 
re-implemented in Go? 

-ahd-

-- 
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 are the reasonable reasons to use pointers?

[Drew Derbyshire]

On Tuesday, January 1, 2019 at 9:13:44 AM UTC-8, Jan Mercl wrote:
>
>
> On Tue, Jan 1, 2019 at 12:34 PM 伊藤和也 > 
> wrote:
>
> > What are the reasonable reasons to use pointers? Are pointers necessary?
>
> Yes, they're necessary in non-trivial programs. Without pointers any 
> program can use only (named) variables declared in the program. Pointers 
> allow creating (anonymous) variables at run time accessed via the pointer. 
> Many useful data structures rely on variables dynamically allocated at run 
> time.
>
 
You've never met a FORTRAN 66 programmer.   :-)

-- 
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] Re: Go2 proposal: remove := operator (or remove variable shadowing)

[Drew Derbyshire]

Given all Go's narrow minded ideas for the sake of purity, := should be 
considered a vicious hack and removed from the language.  Adding a simple

var err 

At the top of a routine won't kill people.

In my own experience, that construct is the single largest cause of trivial 
errors in Go that I've seen.

-- 
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] Re: why does go reverse the order of name and type? "i int" vs "int i"

[Drew Derbyshire]

On Wednesday, September 19, 2018 at 10:30:11 PM UTC-7, Sathish VJ wrote:
>
> I've been asked this question a few times and I haven't been able to find 
> an answer.  Why does go reverse the order of variable declaration:  "i int" 
> vs "int i"
>

To match PL/I, of course.   :-)

-ahd-

-- 
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] Re: vertical search engine go concurrency

[Drew Derbyshire]

As Andre noted, I don't think you have provided sufficient information.

I'd go further: *Stop*,  Determine what you (and your developer) need to 
know. 

Decide what you want, and write a specification. If you have to ask 
"specification for what", make a list what you don't know.  Does the 
specification need to be long?  No, but it has to define your problem(s) 
and solution(s). 

You can do the specification writing or the contractor can -- but if you 
have questions after reading it, get them written down and answered in the 
specification. You are just asking for trouble to ask a remote developer 
(across town or across the sea) to write a complex application backend if 
you don't understand what you asking for.

-ahd-

-- 
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 this code thread safety?

[Drew Derbyshire]

What Jan said.  I had started my own post before I realize other sane 
people checked in about the absurd colors.

On Thursday, November 2, 2017 at 3:13:07 AM UTC-7, Jan Mercl wrote:
>
> On Thu, Nov 2, 2017 at 6:54 AM sheepbao  
> wrote:
>
> > the close function is thread safety? how about call `closed` at the same 
> time. 
>
> I don't know, but you might want to reconsider posting text with contrast 
> going in some places below 10% (guestimated), to possibly get answers from 
> people which refuse to read what's not really readable.
>
> Black on white is the best.
>
> -- 
>
> -j
>

-- 
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] Tools for 80 column split for golang

[Drew Derbyshire]

I haven't edited on a true text mode terminal since 1992, but a column 
limit is still useful.  This and the other Go standards for relatively 
fixed formatting are not its strong suit.

On Wednesday, September 6, 2017 at 11:36:04 PM UTC-7, Jakob Borg wrote:
>
> On 7 Sep 2017, at 06:10, Sankar  
> wrote: 
> > 
> > Are there any tools available for golang to split long functions so that 
> they can fit in 80 columns (as long as possible) ? 
>
> Don't fear longer lines, most of us are not on text mode terminals any 
> more. :) 
>
> When it becomes *too* long it's probably hard to read due to being a too 
> large or too complex expression, not the line length per se. My preferred 
> solution would be to split it up with a variable or two. I don't think 
> there is a tool for that, it requires human consideration. 
>
> //jb 
>
>

-- 
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: No Allman-Style, No go!

[Drew Derbyshire]

"And thirdly, the code is more what you'd call "guidelines" than actual 
rules."  -- Captain Hector Barbossa

On Saturday, July 29, 2017 at 10:37:11 AM UTC-7, ecstati...@gmail.com wrote:
>
> Sorry to repeat myself, but I think I wasn't clear enough, as many people 
> on this forum still don't understand my point at all. 
>
> Google, as ANY company, MUST force its employees to use exactly the same 
> standards.
>
>
This is flat out incorrect.  In particular, by using "ANY", "MUST" "force" 
and "exactly", your directive is invalidated by a single company that 
doesn't follow your directive succeeding. I've been at several such 
companies.  

Google has some of the strictest (and in some cases, flawed) coding 
standards I've seen in my three plus decades in the industry.  Those 
standards didn't make the code better than companies I've been at with 
loose or even non-existent coding standards.

I'd compare Google coding standards to Google management's belief that open 
floor plans are more productive; that office layout is only a boon to 
real-estate services's budget. I spent over a third of my career in 
environments where I had a private office or at least sufficient space to 
have minimum disruptions, and I can say the Google philosophy (and it's 
interruption filled side-effects) is truly flawed.

But neither Google's office layout nor their coding standards are fatal 
flaws.

I would stress proper documentation, good tests and diligent code reviews 
far more than blind adherence to a coding standard.

Good coders write good code, including being consistent with the code base. 

OCD coding standards don't make bad coders good coders.  Never did, never 
will.

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