Someday there should be a new generation... maybe go-ahead

[J Decker]

Things next gen should have.

Ability to dynamic load modules

Ability to compile go from in-memory strings and generate in-memory objects that can be used.  (C# system.reflection.emit)

A DataSet Structure.  Go has all the ability but lacks this construct to create a database schema in memory with tables and constraints between said tables.  (System.Data.DataSet, System.Data.DataTable)

If it had any 2 of the above I might even forgive it's blind s/\n/;/ behavior.

Event based networking instead of poll based. (including websocket as event based)

Proper enumeration type; that is constants groups into a type and not just arbitrary names.  (Again spoiled by C#)

an event type could be useful; event my_callbacks;  ... external: my_callbacks.Add( callback ); internal: my_callbacks(); which saves some typing and coding to iterate through a list of delegates and creating methods to accept various delegate functions to store them into appropriate lists.  

accessors.  It's sometimes useful to be able to interact with variables and give them complex functions without the calling code being changed.  (recompiled, but not changed)

I'm sure there's a half dozen other things I'm forgetting now; and/or didn't get around to trying, for lack of features.  I started to port sources of DataTable.. but there's several constants named 'None'... and they should all be relative to their other related values.... not just 'None'.  And making sub packages just for the sake of constants seemed like overkill. 

Yes some of these last things are pretty frivolous; just some things I thought were pretty simple to have been omited; and some can be worked around.

-----

It's surprising given it's limited abilities that Go as it is has such a large audience.

[minux]

On Wed, Sep 30, 2015 at 9:12 PM, J Decker <d3c...@gmail.com> wrote:

Things next gen should have.

Ability to dynamic load modules

[snip] 

It's surprising given it's limited abilities that Go as it is has such a large audience.

I think the primary reason Go is popular is its "less is more" design philosophy [0].

we already have enough "feature-packed" languages out there, why not take a

fresh look and see what could be done with a much simpler one?

[0] http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

[Andrew Gerrand]

You may find these articles illuminating. They discuss Go's design philosophy.

https://talks.golang.org/2012/splash.article

http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

Andrew

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roberto Zanotto]

Why are you such a fan of events? Events introduce callback spaghetti in single threaded environments, in multithreaded environments you also get shared state and locks and data races. Concurrent programs with goroutines and channels are much more simple to reason about, give it a try :)

[J Decker]

On Wed, Sep 30, 2015 at 6:58 PM, Andrew Gerrand <a...@golang.org> wrote:
> You may find these articles illuminating. They discuss Go's design
> philosophy.
>
> https://talks.golang.org/2012/splash.article
> http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html
>

Certainly interesting. I note a few things; on being the myopic
obsession that there's only c and C++; and that it was targeted for a
specific set of problems and not meant to be a broad comprehensive
scope language. But stopping at c++ I see why proper enumerations are
missing; because they weren't any more than what they are in Go.

Things like concurrency I would think would lead to events and the
dispatch thereof without having to have developers reroll their own
every time. I did conclude with 'most of these things can be worked
around' aka 'implemented repeatedly by developers'. But then my
origins were developing an RTOS on top of DOS; so I had no prior
experience that networking was even a polling mechanism... and instead
saw networking as an IRQ from hardware.

But that's also why I proposed it as a alternative future rather than
modifications to Go itself.

[Egon]

(Warning, will be very direct here, don't take it personally, this language style simply carries my ideas/thoughts over in a conciser and clearer way.)

On Thursday, 1 October 2015 04:12:25 UTC+3, J Decker wrote:

Things next gen should have.

Ability to dynamic load modules

Those will probably come, at some point.

 

Ability to compile go from in-memory strings and generate in-memory objects that can be used.  (C# system.reflection.emit)

This would mean including the whole compiler into Go. Also it wouldn't fit with Go-s constraints that it must run in locations where runtime code-generation is not allowed.

 

A DataSet Structure.  Go has all the ability but lacks this construct to create a database schema in memory with tables and constraints between said tables.  (System.Data.DataSet, System.Data.DataTable)

I don't understand why it should be part of the language?

There are already plenty of  DB/Storage libraries https://github.com/golang/go/wiki/projects#databases-and-storage. Different needs require different set of features.

 

If it had any 2 of the above I might even forgive it's blind s/\n/;/ behavior.

Event based networking instead of poll based. (including websocket as event based)

Why would the event based networking be better than the current single thread (not OS thread) of execution?

 

Proper enumeration type; that is constants groups into a type and not just arbitrary names.  (Again spoiled by C#)

Why?

 

an event type could be useful; event my_callbacks;  ... external: my_callbacks.Add( callback ); internal: my_callbacks(); which saves some typing and coding to iterate through a list of delegates and creating methods to accept various delegate functions to store them into appropriate lists.  

What's the real-world example where you would use it?

 

accessors.  It's sometimes useful to be able to interact with variables and give them complex functions without the calling code being changed.  (recompiled, but not changed)

Not sure what you mean here?

 

I'm sure there's a half dozen other things I'm forgetting now; and/or didn't get around to trying, for lack of features.  I started to port sources of DataTable.. but there's several constants named 'None'... and they should all be relative to their other related values.... not just 'None'.

 And making sub packages just for the sake of constants seemed like overkill. 

Why the hell would you do that? This would rather suggest that there is no clear architecture in your port.

It seems to me that you are trying to fit a project into Go that was written in an another language that has a different set of idioms and patterns. It's like taking a Prolog program and trying to make it work in C#, and then complaining that you cannot run statements in arbitrary order.

So...

Where is your code that you are trying to get working and where are the locations that you are having trouble with? Maybe, people can suggest improvements to your code instead.

If you write language X like language Y -- you will fail. Go is not C# and Prolog is not C# and Haskell is not Prolog etc. They are different languages, hence they must be handled and written differently.

Learn how Go programs are structured and you will have less need for all of the features that you ask. I'm not saying you definitely don't need them, but rather that you are coming from a different language and do not understand how to structure things.

I'm not saying that you don't know how to program... I'm pretty convinced that you know it very well. I'm saying that Go is not language X and treating it as such will result only in misery.

"Real Programmer can write FORTRAN programs in any language."

+ Egon

[Giulio Iotti]

On Thursday, October 1, 2015 at 9:35:01 AM UTC+2, Egon wrote:

On Thursday, 1 October 2015 04:12:25 UTC+3, J Decker wrote:

Things next gen should have.

Ability to dynamic load modules

Those will probably come, at some point.

True. Shared library linking is already possible: https://talks.golang.org/2015/state-of-go-may.slide#13

 

Event based networking instead of poll based. (including websocket as event based)

Why would the event based networking be better than the current single thread (not OS thread) of execution?

Can someone explain this to me? What is event based networking at OS level? One OS thread per connection? What API does that use?

-- 

Giulio Iotti 

[Giulio Iotti]

On Thursday, October 1, 2015 at 9:44:24 AM UTC+2, Giulio Iotti wrote:

Event based networking instead of poll based. (including websocket as event based)

Why would the event based networking be better than the current single thread (not OS thread) of execution?

Can someone explain this to me? What is event based networking at OS level? One OS thread per connection? What API does that use?

Ah, I guess he meant something like select/epoll available to in Go without using syscalls.

So yeah, Egon's answer makes more sense now.

-- 

Giulio Iotti

[Henrik Johansson]

Perhaps I have gotten it wrong but network io is implemented using said async models under the hood.

--

[Giulio Iotti]

On Thursday, October 1, 2015 at 10:57:06 AM UTC+2, Henrik Johansson wrote:

Perhaps I have gotten it wrong but network io is implemented using said async models under the hood.

Yes, it is, that's what confused me. The request was to make their use directly available in Go, I think. 

But as goroutines are a totally different beast than threads, the current approach makes is fast and powerful, no need for the event loop[1].

[1] http://dave.cheney.net/2015/08/08/performance-without-the-event-loop

-- 

Giulio Iotti 

[Staven]

On Wed, Sep 30, 2015 at 06:12:25PM -0700, J Decker wrote:
> Things next gen should have.
>
> Ability to dynamic load modules
>
> Ability to compile go from in-memory strings and generate in-memory objects
> that can be used. (C# system.reflection.emit)

What Go really needs, is self-modifying code.
I'm sure nothing bad can happen.

> If it had any 2 of the above I might even forgive it's blind s/\n/;/
> behavior.

what does that even mean

> accessors. It's sometimes useful to be able to interact with variables and
> give them complex functions without the calling code being changed.
> (recompiled, but not changed)

Yeah, I think the ability to attach arbitrarily complex hidden side-effects
to any assignment expression would really improve the readability.

[Konstantin Shaposhnikov]

Ability to compile go from in-memory strings and generate in-memory objects that can be used.  (C# system.reflection.emit)

This would mean including the whole compiler into Go. Also it wouldn't fit with Go-s constraints that it must run in locations where runtime code-generation is not allowed.

 

Having ability to use Go compiler as a library could actually be quite useful (in some rare cases ;). One possible use-case is a database engine compiling SQL queries to the machine code for the best possible performance.

[minux]

Is that really necessary? (i.e. is there any production database engine that does that?)

compiling to machine code is usually the last resort and is kinda the bruteforce approach

to performance problems.

[you...@z505.com]

On Wednesday, September 30, 2015 at 7:12:25 PM UTC-6, J Decker wrote:

Things next gen should have.

Beware of bikeshedding, if you haven't looked up the meme...
 

Ability to dynamic load modules

Ability to compile go from in-memory strings and generate in-memory objects that can be used.  (C# system.reflection.emit)

A DataSet Structure.  Go has all the ability but lacks this construct to create a database schema in memory with tables and constraints between said tables.  (System.Data.DataSet, System.Data.DataTable)

Would this be anything like Tutorial D done wrong without a mathematics basis and foundation of the relational model? Is it anything like LINQ or object relational mappers? Sorry, I don't like C# and never have used it (but I'm sure it has some interesting "features") so I'm not sure what a dataset is and acts like in C#.  My reason for never using C# was simply when I looked at a hello world it forced me into using objects instead of having the option of simple elegant procedures like Delphi, C, even C++, oberon, GoLang.  But just because it made this mistake of forcing OOP onto people (kool aid drinkers) doesn't mean C# hasn't come up with some innovations.
 

If it had any 2 of the above I might even forgive it's blind s/\n/;/ behavior.

Please explain what you mean...
 

Event based networking instead of poll based. (including websocket as event based)

Proper enumeration type; that is constants groups into a type and not just arbitrary names.  (Again spoiled by C#)

Have a look at Niklaus Wirths comments on Enumerations and why he thinks they are dangerous. I'm still skeptical of this though, I really like Enumerations in delphi for some things... but I'm wondering if it is a can of worms that leads to more problems then its worth (Wirth has some comments on how it adds all sorts of complexity to compilers since enums can be used for many things, where simple constants are easier to compile and reason about) .  Again I am still researching enums and why they are bad, I am by no means an expert why they are bad, yet.

an event type could be useful; event my_callbacks;  ... external: my_callbacks.Add( callback ); internal: my_callbacks(); which saves some typing and coding to iterate through a list of delegates and creating methods to accept various delegate functions to store them into appropriate lists.  

accessors.  It's sometimes useful to be able to interact with variables and give them complex functions without the calling code being changed.  (recompiled, but not changed)

I'm sure there's a half dozen other things I'm forgetting now; and/or didn't get around to trying, for lack of features.  I started to port sources of DataTable.. but there's several constants named 'None'... and they should all be relative to their other related values.... not just 'None'.  And making sub packages just for the sake of constants seemed like overkill. 

Yes some of these last things are pretty frivolous; just some things I thought were pretty simple to have been omited; and some can be worked around.

-----

It's surprising given it's limited abilities that Go as it is has such a large audience.

More like encouraging. COBOL and Ada and C++ are examples of complex beasts that have become monsters.  An example of something encouraging is cars still sell you manual roll down windows... since electronic complex gadgets break, contacts fail, wires have to be run all through the car... Or another example is they still offer manual transmission cars. Heck, even seats are not electric in many cars. More features does not equal better.  Wirth has also warned about this. Feature are often bugs. For example C++ has been medically proven to be the next iteration of cancer. Doctors did a study on it. Java and C# don't even have "procedures" as a simple every day feature I need 99 percent of the time... they force you to use Methods inside a class and makes you code a needlessly complex heirachy/nest that looks jokingly like this:

class {
   {
     {  
       { method
           {system.writer.tostandardout.makesure.print("hello world")
   }
 }
}

Why haven't some languages got basic procedures as a feature? I had to figure out a way to get Ruby doing procedural programming and found a way, but it's as if this simplicity is discouraged and you have to cleverly break out of OOP by going against a languages OOP enforcement.. in ruby you use a global class.. Not sure what you do in Java or C#.  So some people demand simple languages get more complex features, but I often find myself demanding complex languages offer simple features that they never thought to implement, because of some cult ideology. Procedures are bad, don't use them! (no, no, that's just some OOP heavy pattern oriented guru quackery that is plain wrong).

But I would like to hear about what dataset is and if it has anything to do with relational mapping, or what Tutorial D is trying to solve.

[Konstantin Shaposhnikov]

I think this depends on type of queries a database engine optimizes
for. Simple queries that work on large datasets can benefit from using
compiled code.

I am aware of the following products that use code generation:
- Apache Spark (though it is not a general purpose database engine)
generates Java code (that is autoamtically compiled by JIT) to execute
some of the SQL functions in a more efficient way
- memsql (http://docs.memsql.com/4.0/faq/#what-is-the-advantage-of-memsql-over-traditional-databases-like-oracle-sql-server-or-mysql-with-data-in-a-ramdisk-or-large-buffer-pools)

[you...@z505.com]

On Thursday, October 1, 2015 at 3:34:24 AM UTC-6, Staven wrote:

On Wed, Sep 30, 2015 at 06:12:25PM -0700, J Decker wrote:
> Ability to compile go from in-memory strings and generate in-memory objects
> that can be used.  (C# system.reflection.emit)

What Go really needs, is self-modifying code.
I'm sure nothing bad can happen.

You mean there is someone out there who's critical of Lisp and doesn't fall for all the hype about it?
 I have thought of rare cases where this could be useful in some bizarre video game. Imagine grand theft auto where the main character himself, can recompile the game to his liking, with different physics.  I.e. instead of you modifying the game, the character inside the video game itself, has an A.I. ability to recompile the game and restart it himself, while you are out getting groceries and left your computer on.

Note: although this is humorous, it's also something like "lisp is the most intelligent way to misuse a computer" but one doesn't neccesarily need to use lisp to do this, one could figure out a way to embed a compiler in a go program and restart the go program from the code itself, but I don't know if the state of the system could be saved easily, whereas lisp allows you to fiddle with the program at run time without restarting the proces.

This sort of stuff is not to be read or studied without Alice In Wonderland style drugs first. Still an interesting topic.

[Staven]

On Fri, Oct 02, 2015 at 10:49:53PM -0700, you...@z505.com wrote:
> On Thursday, October 1, 2015 at 3:34:24 AM UTC-6, Staven wrote:
> >
> > On Wed, Sep 30, 2015 at 06:12:25PM -0700, J Decker wrote:
> > > Ability to compile go from in-memory strings and generate in-memory
> > objects
> > > that can be used. (C# system.reflection.emit)
> >
> > What Go really needs, is self-modifying code.
> > I'm sure nothing bad can happen.
> >
> >
> You mean there is someone out there who's critical of Lisp and doesn't fall
> for all the hype about it?

There are people in this world who are born as bitter old men and are critical of everything.

[Lucio]

On Saturday, 3 October 2015 19:53:35 UTC+2, Staven wrote:

There are people in this world who are born as bitter old men and are critical of everything.

I suspect I'm one of those.  And maybe it's an age thing that makes me critical, I not so clearly remember defending the indefensible instead, sometimes in the past.

Thing is, I thought it was a good thing to see both sides of a coin, now I'm not so sure.  In the field of security, I think it's still an asset, irrespective of whether it's the good or the bad side that you see when others overlook it.

Lucio.

[Scott Pakin]

On Wednesday, September 30, 2015 at 7:12:25 PM UTC-6, J Decker wrote:

Ability to compile go from in-memory strings and generate in-memory objects that can be used.  (C# system.reflection.emit)

I wonder if llgo will eventually support dynamic code generation.  I haven't been following the project so I don't know if anyone's looking into that, but the underlying LLVM framework would certainly make it possible,

Be careful what you wish for, though: Generating code from strings can be a security nightmare, although there are certainly places where it can be convenient.

 

Proper enumeration type; that is constants groups into a type and not just arbitrary names.  (Again spoiled by C#)

Go lets you define typed constants.  Notice how in http://play.golang.org/p/O_SVlkwWEV, the compiler rejects the attempt to add a Shape and a Color.  Is there something more than that that C# offers? 

— Scott

[Carlos Castillo]

I'm not sure about C# but I suspect it's like Java, where the compiler will actively prevent you from passing anything but the defined enum values. In go, even though you can prevent casual use of one type as another, the underlying type is still usually an int (for most enums) so you can use ++/--/etc, or constants to pass arbitrary values to your code when it's expecting that only specific values are possible. That being said, the case of accidentally doing this drops significantly with go's type system, so most problems caused are through intentional acts.

What it means in general, is that you should have a default case (usually a panic) for any time you accept an enum from the outside to catch unplanned for values, and otherwise the type system can usually handle the accidents at compile time.

[Levi Corcoran]

FWIW, C# does allow undefined enum values; any value compatible with the underlying type (again, usually an int) can be cast and set to any variable/field of that enum type.  ToString() will just show the integer value rather than the enumeration value.