That is a different argument entirely.
That you have a team of competent Go developers that are productive in a few
weeks is a point against generics in Go at all (which is where I am now).
And that was my original point, is that outside of type-safe containers, MOST
generic code is not
On Fri, Oct 26, 2018 at 9:32 PM robert engels wrote:
>
> OK, you got me, I’m sucked in - it was a nice balance of yes, BUT no.
>
> First, there is simply no debate, Java += Android, and you have the most
> successful language/platform ever. NO debate.
>
> Arguing against Java’s write-once, run
Quoting robert engels (2018-10-26 23:31:46)
>OK, you got me, I'm sucked in - it was a nice balance of yes, BUT no.
>
>First, there is simply no debate, Java += Android, and you have the
>most successful language/platform ever. NO debate.
>Arguing against Java's write-once, run
OK, you got me, I’m sucked in - it was a nice balance of yes, BUT no.
First, there is simply no debate, Java += Android, and you have the most
successful language/platform ever. NO debate.
Arguing against Java’s write-once, run anywhere implementation is a bad
position to take. Yes, if you
HI , you can capture and store the sdtin buffer and handle it then, for
example:
// Set IO
session.Stdout = os.Stdout
session.Stderr = os.Stderr
in, _ := session.StdinPipe()
go func() {
for {
var buffer [1024]byte
n, err := os.Stdin.Read(buffer[:])
if err != nil {
fmt.Println("read error:",
Please no. The absence of sigils in Go is one of the syntactic features
of the language that make it light to read.
I don't want a symbol that, even if only due to external cultural
context, suggests that the code is trying to say something exciting.
On Fri, 2018-10-26 at 03:22 -0700,
Quoting Pat Farrell (2018-10-26 21:30:47)
>This leads to my second issue with the OP's ideas. I strongly believe
>that Java has been damaged by its attempt to deliver backward
>compatability. While others have brought up the potential issues with
>keywords, a much more telling
On Wednesday, October 24, 2018 at 11:59:34 AM UTC-4, robert engels wrote:
>
> When Java came along there was a heavy sigh of relief by ISVs that
> understood write-once, and it will continue to work even as mega company
> released new OS versions and APIs - the burden was on the JDK/JRE
>
After giving this some more thought, i’ve changed my syntax for complex
relationships between types. Now it looks like this:
contract Node {
Edges() []Edge
}
contract Edge {
Nodes() (from, to Node)
}
func ShortestPath(type N Node, E Edge)(src, dst N) []E
Andy
> On Oct 25,
I'd be very interested to see if it would be possible to implement an
x/mobile backend for Fyne (github.com/fyne-io/fyne).
The widgets are designed to work across various platforms and the EFL
backend is just one possible implementation.
Could be interesting if we can use the same app code to
First, backward compatibility isn't free. The reason why you can still
compile your "version 1.0" source is because someone gives some thoughts
about it and puts some extra efforts to make it happen. Backward
compatibility requires maintenance and adds constraints to future
development. The
>> for i:=c.Iterator();i.HasNext(); {
>> v := i.Next()
>> }
> I don't like the eyeball friction.
Could you please explain what you mean?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
Inspired to some extent by Ian's idea, I've had another idea which could
rid us of the *new keyword problem* not just for Go 1.xx or Go 2 but for
ever. We wouldn't even have to worry about whether a new keyword could be
restricted to *contextual* use or not.
Suppose any new keyword introduced
13 matches
Mail list logo
