Program your next server in Go • Hacker News Board

Re: Program your next server in Go

#341

Post by geodel » Wed, Jun 08, 2016, 1:07 PM UTC

cryptos wrote: post #292

There are some questionable statements: > Go differs from Java in several ways > Programs compile to machine code. There's no VM. This tries to imply that having a VM is a bad thing. > Simple, concise syntax The syntax is simple, but not overly concise. For example the lack of generics leads to a lot of repetition. > Statically linked binaries You can have them with Java, too. > Built-in strings (UTF-8) Should this s…

It is not that strange considering Java is frequently mocked for highly abstract / design pattern laden 'AbstractSingletonProxyFactory' code.

Re: Program your next server in Go

#342

Post by konart » Wed, Jun 08, 2016, 1:12 PM UTC

IshKebab wrote: post #324

oconnor663 wrote: post #262

> When writing code, it should be clear how to make the program do what you want. Sometimes this means writing out a loop instead of invoking an obscure function. For example instead of the obscure function a.reverse() you can use the clear for loop for i := len(a)/2-1; i >= 0; i-- { opp := len(a)-1-i a[i], a[opp] = a[opp], a[i] } :(

Yes there are clearly examples where the loop is less clear than the function. But I think they wanted to avoid complex 'functional' code like this: Averager averageCollect = roster.stream() .filter(p -> p.getGender() == Person.Sex.MALE) .map(Person::getAge) .collect(Averager::new, Averager::accept, Averager::combine); System.out.println("Average age of male members: " + averageCollect.average()); From here: https://…

Well, this is not the best example, imo.

I have very littile knowledge of Java, but it's clear as day that we filter only entities with male gender, get their age values and return average.

I mean... really.

Re: Program your next server in Go

#343

Post by xamolxix » Wed, Jun 08, 2016, 1:18 PM UTC

cryptos wrote: post #292

There are some questionable statements: > Go differs from Java in several ways > Programs compile to machine code. There's no VM. This tries to imply that having a VM is a bad thing. > Simple, concise syntax The syntax is simple, but not overly concise. For example the lack of generics leads to a lot of repetition. > Statically linked binaries You can have them with Java, too. > Built-in strings (UTF-8) Should this s…

>> Statically linked binaries >You can have them with Java, too.

Is there a widely available FOSS implementation of this?

Re: Program your next server in Go

#344

Post by lossolo » Wed, Jun 08, 2016, 1:27 PM UTC

stymaar wrote: post #340

shadowmint wrote: post #332

Earlier quoted context omitted.

I'm saying it. The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? no. ...rust is verbose. It is statically typed, it is less productive than some other languages and it is hard to learn. Now, you get a whole lot of other benefits in exchange for that, absolutely, and technically speaking, rust is a super a…

> The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping. > rust is verbose. It is statically type, it is less productive than some other languages Than scripting languages ye…

> (what you wouldn't be able to do in C or C++)

I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.

Re: Program your next server in Go

#345

Post by shpx » Wed, Jun 08, 2016, 1:29 PM UTC

mahyarm wrote: post #252

pvelagal wrote: post #114

Earlier quoted context omitted.

Slide 13 ( https://talks.golang.org/2016/applicative.slide#13 ) is interesting. I was expecting Go to be very close to C/C++ on the X axis (fast/efficient) as it doesn't use VM, but it is more close to Java ?

In my experience programming speed goes like this: - 1x benchmark - C / static C++ - 2x slower - pure virtual C++ / objective-c - 3x slower - statically typed GC languages (java,go) - +6x slower - dynamically typed GC languages (js, python, etc) After a well optimized implementation, speed comes down to manual vs GC memory management, static vs virtual function dispatch, dynamic vs static typing and heap vs stack all…

https://benchmarksgame.alioth.debian.org/u64q/which-programs...

Re: Program your next server in Go

#346

Post by shadowmint » Wed, Jun 08, 2016, 1:38 PM UTC

stymaar wrote: post #340

shadowmint wrote: post #332

Earlier quoted context omitted.

I'm saying it. The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? no. ...rust is verbose. It is statically typed, it is less productive than some other languages and it is hard to learn. Now, you get a whole lot of other benefits in exchange for that, absolutely, and technically speaking, rust is a super a…

> The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping. > rust is verbose. It is statically type, it is less productive than some other languages Than scripting languages ye…

eh, I don't want to argue; I've said my bit.

Verbose low level memory safety and a high level trait system is a massive step up from C++/C. It's of mixed value if you're doing something you could do in java or go. It's of questionable value if you're doing something you could just whip up in python or js.

Perhaps you're right; rather than just straight out saying go, I'll preface my answer next time I hear the go/rust question:

    'Should a write my next project in go or rust?'

'If you didn't use either, would you write it in C++?'

     '...no?' -> 'Then pick go.'

     '...yes?' -> 'Wtf dude, there's no way you could do it in go then. use rust.'

Re: Program your next server in Go

#347

Post by shadowmint » Wed, Jun 08, 2016, 1:39 PM UTC

lossolo wrote: post #344

stymaar wrote: post #340

Earlier quoted context omitted.

> The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping. > rust is verbose. It is statically type, it is less productive than some other languages Than scripting languages ye…

> (what you wouldn't be able to do in C or C++) I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.

They're referring to memory safety, which isn't possible in C/C++* and is in rust.

(and in go and java and js, yes; but not in C/C++ or any other low level language)

(* without external formal verification, which makes it technically possible I suppose, but not as a built-in feature)

Re: Program your next server in Go

#348

Post by stymaar » Wed, Jun 08, 2016, 1:55 PM UTC

lossolo wrote: post #344

stymaar wrote: post #340

Earlier quoted context omitted.

> The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping. > rust is verbose. It is statically type, it is less productive than some other languages Than scripting languages ye…

> (what you wouldn't be able to do in C or C++) I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.

Of course it's possible to do the same thing in C, but most likely not with «the same amount of code», nor with «memory safety». ;)

Re: Program your next server in Go

#349

Post by oconnor663 » Wed, Jun 08, 2016, 3:02 PM UTC

konart wrote: post #342

IshKebab wrote: post #324

Earlier quoted context omitted.

Yes there are clearly examples where the loop is less clear than the function. But I think they wanted to avoid complex 'functional' code like this: Averager averageCollect = roster.stream() .filter(p -> p.getGender() == Person.Sex.MALE) .map(Person::getAge) .collect(Averager::new, Averager::accept, Averager::combine); System.out.println("Average age of male members: " + averageCollect.average()); From here: https://…

Well, this is not the best example, imo. I have very littile knowledge of Java, but it's clear as day that we filter only entities with male gender, get their age values and return average. I mean... really.

I think one of the simple differences between functional and imperative code is just that functional code is less likely to name its intermediate values. Imperative code is probably going to put something in a local variable, which hopefully has a useful name, but functional code is probably going to chain a bunch of generic methods together.

This isn't a big deal when what I'm looking at is "students.filter(...MALE)" because that's obviously the "male students". But it quickly gets more confusing. What is "students.filter(... == year - 3)"? Is that "freshman students" or "sophomore students" or something else entirely?

Of course there's nothing stopping functional programmers from naming their intermediate results, and nothing stopping imperative programmers from choosing useless 1-letter variable names. But the two different programming styles seem to encourage different things.

Re: Program your next server in Go

#350

Post by lossolo » Wed, Jun 08, 2016, 3:04 PM UTC

stymaar wrote: post #348

lossolo wrote: post #344

Earlier quoted context omitted.

> (what you wouldn't be able to do in C or C++) I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.

Of course it's possible to do the same thing in C, but most likely not with «the same amount of code», nor with «memory safety». ;)

> nor with «memory safety»

I've wrote that you can do it with memory safety which is possible BUT it's more complex in languages like C/C++ that do not guarantee memory safety (it's your responsibility). If it was not possible then you would not have anything on your screen right now. I am writing that because someone that is not familiar with those languages would get impression from your comment that memory safety is impossible in C/C++ which is not true.