Re: [go-nuts] Disadvantage of Go

[Jesper Louis Andersen]

For 2, out of curiosity. What is wrong with the following code using
math.MaxUint32 for instance:

https://play.golang.org/p/pPFvo1pOlc

math defines a constant, which you will need to assign to an variable. But
I don't see there being any type conversion in this piece of code. It is
all implicit over the types given.

Did you allude to something else?

For 1, your workarounds are:

* Write the code yourself by hand. The work seems tedious, but one
observation I have from implementing monomorphisation/defunctorisation
passes in compilers is that often the number of variant uses of an
abstraction is at most a handful. Even in very large programs. So there may
be less code to write in the common case than what people think.

* Use a generator and generate the code. Essentially running the
monomorphisation yourself as a first stage in the compiler. This is also
pretty easy to do.

A side note: if you *really* care about your programs efficiency, you need
a compiler which supports staged compilation, so you can stage code
generation for more than just types. For instance by specializing matrix
multiplications to a specific dimension and so on. This is the land of
cogen as well.

On Fri, Jan 13, 2017 at 4:03 PM Ian Lance Taylor  wrote:

On Fri, Jan 13, 2017 at 6:47 AM, hui zhang  wrote:
> Yes ,   cycle import is a bad design.
> But as the software becomes larger , not everything is controllable.
> In real project , some times it is a great risk to do refactor.

Go is careful to initialize values in the correct order, such that if
the initializer for V1 refers to V2, then V2 is always initialized
before V1.  It is possible to break this by calling between packages
in the initializers, but it takes a fair amount of work.  If Go
permitted cyclic imports, correct initialization would be impossible.
Go has given up one feature (cyclic imports) in favor of another one
(simple and correct initialization).

Ian

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscr...@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Disadvantage of Go

[Ian Lance Taylor]

On Fri, Jan 13, 2017 at 6:47 AM, hui zhang  wrote:
> Yes ,   cycle import is a bad design.
> But as the software becomes larger , not everything is controllable.
> In real project , some times it is a great risk to do refactor.

Go is careful to initialize values in the correct order, such that if
the initializer for V1 refers to V2, then V2 is always initialized
before V1.  It is possible to break this by calling between packages
in the initializers, but it takes a fair amount of work.  If Go
permitted cyclic imports, correct initialization would be impossible.
Go has given up one feature (cyclic imports) in favor of another one
(simple and correct initialization).

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Disadvantage of Go

[hui zhang]

Yes ,   cycle import is a bad design.
But as the software becomes larger , not everything is controllable.
In real project , some times it is a great risk to do refactor.

在 2017年1月13日星期五 UTC+8下午5:56:48，rog写道：
>
> On 13 January 2017 at 07:44, hui zhang  
> wrote: 
> > 4 Can not Cycle import. 
>
> In my opinion, this is one of Go's really great features. When software 
> becomes 
> larger, there is huge pressure to create cyclic dependencies between 
> packages. 
> Once you start to get cyclic dependencies, the system as a whole tends 
> inevitably 
> to gather into a giant "ball of mud". That makes everything less 
> modular and much 
> harder to refactor. 
>
> There are so many times that I would have created a cyclic dependency 
> rather 
> than spending a day or two teasing out the dependencies into something 
> non-cyclic. 
> This process almost always creates something better engineered than before 
> with a better separation of concerns. 
>
> Also, as Egon says, there's a good technical reason: the Go 
> initialisation order depends 
> fundamentally on non-cyclic imports - there's no way to see an 
> imported package's initialised 
> global variables in an uninitialised state. 
>

-- 
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] Disadvantage of Go

[Egon]

On Friday, 13 January 2017 11:56:48 UTC+2, rog wrote:
>
> On 13 January 2017 at 07:44, hui zhang  
> wrote: 
> > 4 Can not Cycle import. 
>
> In my opinion, this is one of Go's really great features. When software 
> becomes 
> larger, there is huge pressure to create cyclic dependencies between 
> packages. 
> Once you start to get cyclic dependencies, the system as a whole tends 
> inevitably 
> to gather into a giant "ball of mud". That makes everything less 
> modular and much 
> harder to refactor. 
>
> There are so many times that I would have created a cyclic dependency 
> rather 
> than spending a day or two teasing out the dependencies into something 
> non-cyclic. 
> This process almost always creates something better engineered than before 
> with a better separation of concerns. 
>
> Also, as Egon says, there's a good technical reason: the Go 
> initialisation order depends 
> fundamentally on non-cyclic imports - there's no way to see an 
> imported package's initialised 
> global variables in an uninitialised state. 
>

There's a way, but it's not pretty *(Delphi can have these issues with 
initialization order and it's a pain to fix/debug in a big project.)*

-- 
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] Disadvantage of Go

[roger peppe]

On 13 January 2017 at 07:44, hui zhang  wrote:
> 4 Can not Cycle import.

In my opinion, this is one of Go's really great features. When software becomes
larger, there is huge pressure to create cyclic dependencies between packages.
Once you start to get cyclic dependencies, the system as a whole tends
inevitably
to gather into a giant "ball of mud". That makes everything less
modular and much
harder to refactor.

There are so many times that I would have created a cyclic dependency rather
than spending a day or two teasing out the dependencies into something
non-cyclic.
This process almost always creates something better engineered than before
with a better separation of concerns.

Also, as Egon says, there's a good technical reason: the Go
initialisation order depends
fundamentally on non-cyclic imports - there's no way to see an
imported package's initialised
global variables in an uninitialised state.

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