thank u very much. I know they all have work around. and I also write
some util my own.
I just wish go to make it more simpler, wish the code could be clean and
short .
Right now go let programer do repeat and Mechanical work
the top 3 are bothering me most
[1],[2] let me do many type cast all the time.
[3] let me have to do initialize default for each struct.
right now I am solving [3] like this.
type F struct {x int32}
var FDefault = F{x:1}
type E struct {f F}
var EDefault = E{f: FDefault}
type D struct {e E}
var DDefault = D{e: EDefault}
在 2017年1月13日星期五 UTC+8下午4:39:55，Egon写道：
>
> As Shawn mentioned, most of these were decided against for varying
> reasons. I'll try to give as much info as I can remember.
>
> On Friday, 13 January 2017 09:44:10 UTC+2, hui zhang wrote:
>>
>> Disadvantage of Go
>> 1 No Generic For Now
>>
> That make user coding repeat code many times, even for basic type such as
>> int float bool
>> It is not easy , even to make a generic min function.
>>
> using interface will always check type casting.
>> and for []interface{} in generic function, u can't do cast
>>
>
> You cannot cast []interface{} to []float64 because they have different
> memory layouts.
>
>
>>
>> 2 Incomplete Type in Basic Lib
>> Take math lib as an example, math.Max math.Min are only for float64 ,
>> you have do stupid conversion for other type.
>>
>
>> 3 No Default Value for struct.
>> Consider multilayer struct. A {B {C {D {E {F} } } }
>> to init A to a default value will be complicated.
>> And how about A[] slice
>> And what if D E F are from third party lib ?
>> You have to dig into 3rd party code just for its default value.
>> For It may have none zero default value.
>>
>
> All structs are zero initialized.
>
> If you had default-values for structs the overhead of constructing
> something becomes non-obvious.
>
>
>>
>> 4 Can not Cycle import.
>> package A B can not import each other at the same time.
>> While other language can.
>> It seems not a big deal just put the the common thing in a new package
>> But when the package and project grow bigger, it just easy to say.
>> This change will affect all caller.
>>
>
> Structures that have cyclic dependencies have longer compile times, init
> order becomes more confusing and prone for errors, and a program having
> cyclic imports is harder to understand than one without it (usually).
>
> Break cycles with DI.
>
>
>> 5 Inconsistent type conversion
>> bool type are normal type just like int and float ,
>> but u can't do below. while other type can cast to others
>> int(bool) bool(int)
>>
>>
> https://github.com/golang/go/issues/9367#issuecomment-143128337
>
>
>> 6 No multi casting expression
>> func foo() (int16, int8)
>> var i,j int32 = (int32,int32)(foo())
>> Since go can't do this, why go provide multi return value.
>>
>
> Why would you not return int32 immediately from `foo`?
> Why would you write `foo` in the first place?
>
> 7 No Ternary Expression
>> hardly find a language without it except go
>>
>
>> 8 No Negative Index for slice
>> all other script language support a[-1] as a[len(a)-1]
>>
>
> In such situations, indexing that involves computation (e.g. `a[n-5]`) can
> easily hide mistakes.
>
>
>>
>> When programing in go
>> we have to do repeated type casting many times, due to the above.
>> write long code for Ternary ,int(bool) a[-1] etc
>>
>
> If you repeatedly need to use it, then:
>
> func ifthen(v bool, a, b int) { if v { return a; }; return b }
> func asint(v bool) int { return ifthen(v, 1, 0) }
>
> x := ifthen(a < b, a, b)
>
> init big struct with default value.
>> Which make Go not an Elegant and simple language.
>> Once I thought go was a simple language,
>> but in fact we write more code.
>>
>> All above are proposal for many times.
>> And it is 6 years(or more).
>> These basic functions are still not added. some of that should be add in
>> version 1.0
>> I belive most above could make go simpler,
>> someone know a little programing could know how to use it.
>> however someone still fear it make go complicate like c++
>>
>
> But, it seems to me you are trying to use Go as a language that it is not.
> Can you show the code where you are having problems with some/all of these
> points, then we can discuss how to avoid these situations in the first
> place.
>
> If you try to use any language in a way that it was meant to, you will
> have problems.
>
> + Egon
>
--
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.
