Scala code is 6000 lines. Go is about 3000.

[Bienlein]

Hello,

I found this statement in http://go-lang.cat-v.org/quotes:

“I have reimplemented a networking project from Scala to Go. Scala code is 6000 lines. Go is about 3000. Even though Go does not have the power of abbreviation, the flexible type system seems to out-run Scala when the programs start getting longer. Hence, Go produces much shorter code asymptotically.” — Petar Maymounko

This sounds really exciting and puzzles me. I would like to know whether it is true and, if so, how it can be explained. At first sight it seems as if the advances in programming languages since C were almost of little use as what expressiveness is concerned (aka lines of code). Some modernized C comes along like Go and beats the heck of all languages that are supposed state-of-the-art like f.ex. Scala (you know what I mean, so please no discussions whether Scala is state-of-the-art or not ;-)).

How can this be explained? Delegation and implicitly implementing interfaces results in such code reduction? I wished I would understand this better. Any ideas?

Cheers, Bienlien

[Aaron France]

Hi,

Go abhors masturbatory programming. Complex systems for the sake of complex systems is what got that program to 6000 lines. Idiomatic Go is straightforward and lacks the wankery that comes with a lot of other 'modern' languages.

Regards,
Aaron

--
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/groups/opt_out.
 
 

[Paulo Pinto]

Just wait until enterprise architects put their hands on Go.

On 22 Mai, 11:03, Aaron France <aaron.l.fra...@gmail.com> wrote:
> Hi,
>
> Go abhors masturbatory programming. Complex systems for the sake of complex
> systems is what got that program to 6000 lines. Idiomatic Go is
> straightforward and lacks the wankery that comes with a lot of other
> 'modern' languages.
>
> Regards,
> Aaron
>
>
>
>
>
>
>
> On Wed, May 22, 2013 at 11:01 AM, Bienlein <jeti...@web.de> wrote:
> > Hello,
>
> > I found this statement inhttp://go-lang.cat-v.org/quotes:
>

> > “*I have reimplemented a networking project from Scala to Go. Scala code

> >> is 6000 lines. Go is about 3000. Even though Go does not have the power of
> >> abbreviation, the flexible type system seems to out-run Scala when the
> >> programs start getting longer. Hence, Go produces much shorter code

> >> asymptotically.*” — Petar Maymounko

[Henry Heikkinen]

I'd love to see that. I can't even imagine how horrible and awkward "Enterprise Go" would look like. AbstractGopherFactoryGoroutineServices?

2013/5/22 Paulo Pinto <paulo....@gmail.com>

[adnaan badr]

AbstractGopherFactoryGoroutineServices: They are going to have a touch time pulling that off. No "abstract" keyword kind of kills their dreams.

[Henry Heikkinen]

Like it would stop them, hah.

2013/5/22 adnaan badr <badr....@gmail.com>

[Ian Lance Taylor]

I don't know what code Peter wrote. But it's not hard to see why Go
code can be shorter than Scala code. In Scala you have to spend time
defining the connections between your types: your inheritance and
implementation hierarchy. In Go you don't do this, because in general
you can't.

There are cases where it is advantageous to define complex type
connections. But it tends to lead you to a programming model where
you write types, and then you write code. In Go you just write code.

Ian

[Pieter Droogendijk]

To me, writing in Scala feels like having a fight with the JVM, its compatibility with Java, and Scala's "everything is an object" clause, all at the same time.

The JVM limits its performance, the compatibility with Java limits its type system (though inference removes a lot of pain for the programmer), and "everything is an object" limits its operators and creates so many magic exceptions.

Also, the way to do concurrent programming in Scala is just so much more verbose than in Go.

It's got some great ideas though, and it's definitely better than Java.

By comparison, writing in C feels like being scratched by a kitten, Java feels like being mauled by a tiger, Haskell feels like masturbating, and Go feels like making love.

[Joshua Marsh]

On Wednesday, May 22, 2013 3:39:13 AM UTC-6, Henry Heikkinen wrote:

 AbstractGopherFactoryGoroutineServices

I LOL'ed. For what it's worth, I work at a large company that is primarily enterprise Java. I've been trying to get them to use go and they don't bite. They haven't given me a much better answer than "It's not Java" despite the lower overall costs and better performance I've been able to show.

[Pieter Droogendijk]

I feel your pain.

[Anssi Porttikivi]

They will learn when their system is replaced by Go based competition.

[Pieter Droogendijk]

On Wednesday, 22 May 2013 17:21:46 UTC+2, Anssi Porttikivi wrote:

They will learn when their system is replaced by Go based competition.

I doubt it. We still run oodles of Cobol.

[Eric Palmer]

Oh My!

Sorry to hear that.  The description earlier about java is like fighting with a tiger resonates with me.  Hope you don't have to touch that cobol code!

--

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/groups/opt_out.
 
 

--
KK4MWM (Ham Radio)
About Me
http://www.thingiverse.com/DaddyOh
Join the 3DPrinter Revolution
http://makerbot.com

[Henry Heikkinen]

While horrible, Java is widely used and often gets things done. It's pretty easy to hire people who know Java too. I understand why it might sound just insane to switch to something else. Unfortunately people often forget that it's not necessarily good thing to be locked in to a single technology no matter how great it is.

I think some people at where I work are trying to push Clojure as the first step out of Java. I would definitely suggest Go if we had any new projects that would benefit from it or couldn't make use of a lot of existing code.

Regards,

Henry Heikkinen

2013/5/22 Joshua Marsh <jos...@themarshians.com>

On Wednesday, May 22, 2013 3:39:13 AM UTC-6, Henry Heikkinen wrote:

 AbstractGopherFactoryGoroutineServices

I LOL'ed. For what it's worth, I work at a large company that is primarily enterprise Java. I've been trying to get them to use go and they don't bite. They haven't given me a much better answer than "It's not Java" despite the lower overall costs and better performance I've been able to show.

--

[Thomas Bushnell, BSG]

It's easy to hire people who know Java, but it's a mistake to hire people who cannot learn new programming languages easily....IMO...

[Henry Heikkinen]

Yeah, that's a problem. Getting stuck with a single technology stack doesn't help that either.

Regards,

Henry Heikkinen

2013/5/22 Thomas Bushnell, BSG <tbus...@google.com>

[Pieter Droogendijk]

On Wednesday, 22 May 2013 18:09:14 UTC+2, Thomas Bushnell, BSG wrote:

It's easy to hire people who know Java, but it's a mistake to hire people who cannot learn new programming languages easily....IMO...

On Wed, May 22, 2013 at 9:06 AM, Henry Heikkinen <r...@rce.fi> wrote:

While horrible, Java is widely used and often gets things done. It's pretty easy to hire people who know Java too. I understand why it might sound just insane to switch to something else. Unfortunately people often forget that it's not necessarily good thing to be locked in to a single technology no matter how great it is.

I think some people at where I work are trying to push Clojure as the first step out of Java. I would definitely suggest Go if we had any new projects that would benefit from it or couldn't make use of a lot of existing code.

What Henry said sounds extremely familiar, and I sort of understand where the manager types come from. But Thomas' comeback is beautiful. I'm definitely stealing it.

[Pieter Droogendijk]

On Wednesday, 22 May 2013 17:28:48 UTC+2, Eric Palmer wrote:

Oh My!

Sorry to hear that.  The description earlier about java is like fighting with a tiger resonates with me.  Hope you don't have to touch that cobol code!

Thankfully, no! Writing Cobol would be like fighting a whole forest full of bengals. We have a bunch of guys with extremely long, manly beards for that sort of work.

[Eric MacAdie]

How do you think Clojure compares to Go?

= Eric MacAdie

[Bienlein]

I LOL'ed. For what it's worth, I work at a large company that is primarily enterprise Java. I've been trying to get them to use go and they don't bite. They haven't given me a much better answer than "It's not Java" despite the lower overall costs and better performance I've been able to show.

Well, I fear that typical Java places won't consider Go for general application development. Go is some modernized C and only few people would choose C for "ordinary" company-internal application development. You would even run into trouble if you didn't continue learning new Java systems, framdeworks, tools, servers, etc. Not wanting to be tough, it's just the bitter situation on the job market.

There was a time where application development was mostly either done in Smalltalk or C++ (when OO was the big new thing). Then Java came along causing Smalltalk to disappear and C++ being moved to the system programming corner. So I believe Go will have to find its place in systems programming or programming of general systems like Cloud systems, NoSQL databases, network programming, etc.

I was also bending my mind how to get a Go job somewhere somewhen. I believe for some time to come you have to be either very lucky, start your own start-up or have to reside to Go programming as a spare time effort to learn new things as such (new programming approaches  as in Go). If you know better let me know. I will be the first one to jump on the occasion :-).

-- Bienlein

[Henry Heikkinen]

Another thing is that most Go job announcements are by companies in the US. Afaik it can be pretty problematic if both sides are not prepared.

2013/5/22 Bienlein <jet...@web.de>

--

[Arnold]

Still only one line of REBOL :D

Regards,

Arnold

2013/5/22 Henry Heikkinen <r...@rce.fi>

[Paulo Pinto]

On 22 Mai, 19:34, Bienlein <jeti...@web.de> wrote:
> Well, I fear that typical Java places won't consider Go for general
> application development. Go is some modernized C and only few people would
> choose C for "ordinary" company-internal application development. You would
> even run into trouble if you didn't continue learning new Java systems,
> framdeworks, tools, servers, etc. Not wanting to be tough, it's just the
> bitter situation on the job market.

We do .NET and JVM consulting, and given that some of our projects
have been
migrations from C++ to those systems, it is very hard to promote any
language
that lives outside those eco-systems.

Additionally in the enterprise, the languages are chosen based on the
project type and
not on developers preferences.

>
> There was a time where application development was mostly either done in
> Smalltalk or C++ (when OO was the big new thing). Then Java came along
> causing Smalltalk to disappear and C++ being moved to the system
> programming corner. So I believe Go will have to find its place in systems
> programming or programming of general systems like Cloud systems, NoSQL
> databases, network programming, etc.

Given that NoSQL and network programming are mostly covered by
JVM, .NET, Erlang and
C++ it is going to be a though call.

If you want to sell Go, you need to think of how to sell a story about
the business value of
adopting a new language.

--
Paulo

[Bienlein]

If you want to sell Go, you need to think of how to sell a story about
the business value of
adopting a new language.

Yeah, I believe this is going to be difficult. You can write some interesting blogs, write some nice generic (aka application-independent) framework in Go that takes design skills to write and this might be a plus at some places when applying for a job.

Coming to think of it, the maybe best approach is to get yourself a job where you also do C programming. When Go gets more mature your knowledge in C and private open source projects in Go will be a plus for a Go job or you might be able to convince your employer to change for a project from C to Go and see what's the benefit. But doing Go without getting professional experience in C will probably end up as your efforts in Go remaining for private fun leisure. Unless you are lucky and get a job at Google or some startup, but this is very unlikely for many people in the US and much more for us here in Europe ... Maybe at some place they let you write some things in Go instead of Python as they used to, because the management doesn't object it.

Not meaning to be negative. Just looking for a realistic path that gets you around the cliffs ...

Cheers, Bienlein

[Anh Hai Trinh]

Like it or not, JVM languages have generics and hence MapReduce.

Scala now has http://spark-project.org/ which is also based on generics and higher-order generic functions.

I'm a big fan of Go, but I'm afraid that when distributed computing and data processing is involved, Go is out of its league, despite all the concurrency awesomeness that is goroutine, channels and selects.

--
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/groups/opt_out.

--
@chickamade

[David Symonds]

On Thu, May 23, 2013 at 6:13 PM, Anh Hai Trinh <anh.ha...@gmail.com> wrote:

> Like it or not, JVM languages have generics and hence MapReduce.
>
> Scala now has http://spark-project.org/ which is also based on generics and
> higher-order generic functions.
>
> I'm a big fan of Go, but I'm afraid that when distributed computing and data
> processing is involved, Go is out of its league, despite all the concurrency
> awesomeness that is goroutine, channels and selects.

Yeah, totally. Google, one of the biggest distributed computing and
data processing companies in the world, could never possibly use Go
for any of that.

Oh, wait.

[Paulo Pinto]

On 23 Mai, 08:56, Bienlein <jeti...@web.de> wrote:
> If you want to sell Go, you need to think of how to sell a story about
>
> > the business value of
> > adopting a new language.
>
> Yeah, I believe this is going to be difficult. You can write some
> interesting blogs, write some nice generic (aka application-independent)
> framework in Go that takes design skills to write and this might be a plus
> at some places when applying for a job.
>
> Coming to think of it, the maybe best approach is to get yourself a job
> where you also do C programming. When Go gets more mature your knowledge in
> C and private open source projects in Go will be a plus for a Go job or you
> might be able to convince your employer to change for a project from C to
> Go and see what's the benefit.

Speaking from the work market here in Germany, that is going to be
really thought.

I only see job advertisements requesting C experience in the car
industry, automation and
embedded systems, usually located in small towns lost in the middle of
the country.

Everything else already moved away from C into other languages.

--
Paulo

[Bienlein]

Speaking from the work market here in Germany, that is going to be

really thought.

 
Turns out again the world is small ...

I only see job advertisements requesting C experience in the car
industry, automation and
embedded systems, usually located in small towns lost in the middle of
the country.

 
Yeah, and automotive is no good industry to be in. Many developers there are external and may be made redundant easily. And there is quite some oversupply in the European car industry. There are sometimes job ads asking for Java developer with knowledge in C/C++ considered a plus. Then special things like image processing for medical images. Maybe just some Go for fun and leisure but controlled in a small dosis ...

[Bienlein]

Coming to think of it ... For example nobody cares what language Erlang is written in. Nobody cares that much that Java/C#/C developers cannot write Erlang code and that you need a special kind of breed that can write Erlang programs. So you need something like Erlang being written in Go and you are fine. People would just ask for Go people and that's it. I know of some banks here that run Erlang systems and also telecommunication systems. So that should work.

[Eric Palmer]

That is creative. I like that.  I'm lucky. I own my development environment and can use whatever tools I want. But that is because it is very parochial.  

--

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/groups/opt_out.
 
 

--

[Paulo Pinto]

Well to be honest, all the projects that are known where Go is being
used at Google, could be easily
done in any strong typed modern language free from C and C++ pre-
historic toolchains.

Until a big Google project is shown being done in Go, people will
doubt how much it is really being used.


On May 23, 10:35 am, David Symonds <dsymo...@golang.org> wrote:

> On Thu, May 23, 2013 at 6:13 PM, Anh Hai Trinh <anh.hai.tr...@gmail.com> wrote:
>
> > Like it or not, JVM languages have generics and hence MapReduce.
>

> > Scala now hashttp://spark-project.org/which is also based on generics and

[minux]

On Thu, May 23, 2013 at 10:50 PM, Paulo Pinto <paulo....@gmail.com> wrote:

Well to be honest, all the projects that are known where Go is being
used at Google, could be easily
done in any strong typed modern language free from C and C++ pre-
historic toolchains.

Until a big Google project is shown being done in Go, people will
doubt how much it is really being used

code.google.com/p/vitess ? 

[Paulo Pinto]

That belongs to "could be easily done in any strong typed modern
language".

On 23 Mai, 17:37, minux <minux...@gmail.com> wrote:

[Rob Pike]

Or in assembly language, at least absent the waffleword "easily". I
don't see your point.

-rob

[minux]

On Fri, May 24, 2013 at 12:23 AM, Paulo Pinto <paulo....@gmail.com> wrote:

That belongs to  "could be easily done in any strong typed modern
language".

Let's ask the opposite question:

Can you please give an example that couldn't be "easily" done in a strong typed modern

language? (how easy could be regarded as "easily"?)

[Henry Heikkinen]

That argument is pretty thin because it works just as well the other way too.

2013/5/23 Paulo Pinto <paulo....@gmail.com>

[Paulo Pinto]

It is all about the business value as I mentioned in some other post.

Go is a nice language, but its features are mainly surprising for
people
coming from dynamic languages, or the ones mostly used to the C and C+
+
ways of doing things.

Many of us that enjoyed the Pascal family of languages, mainly Ada,
Modula-2/3, Delphi,
Oberon-2, Active Oberon already experimented most of the nice features
Go has.

Sadly due to C's hegemony in systems programming, many young
developers never got to use such
languages. Luckily they are rediscovering them via Go.

Coming back to vitess, I bet if the project team had decided on a
JVM, .NET, Erlang, Ada,... system it
would achieve pretty much similar results.

The only reasoning for choosing Go seems to have been "because we like
it better than other options".

As for the other projects, most Go presentations tend to be about web
sites or RPC servers, both use
cases are already well served by other languages.

Even the concurrency use case is well served by frameworks in other
languages, specially if one is aware
of the high performance systems done in Erlang, JVM and .NET
environments doing almost real time transactions in
stock exchanges and telecommunication networks.

Hence my remark about any modern language.

Sorry if I offended anyone, even though I tend to dabble more around
other languages, I wish all the best for Go's
future.

--
Paulo

On 23 Mai, 18:37, minux <minux...@gmail.com> wrote:

[Ian Lance Taylor]

On Thu, May 23, 2013 at 10:09 AM, Paulo Pinto <paulo....@gmail.com> wrote:
>
> The only reasoning for choosing Go seems to have been "because we like
> it better than other options".

That is true, but it seems to me that it is true for pretty much any
language choice at all. It's rare that a new programming project is
actually required to use a specific language.

As a new language, Go certainly does face significant barriers to
adoption. This is true of any new language. It's always easier to
keep doing what you have done in the past.

I think you're right that there is no single compelling business
reason for why people should use Go. We think it's better in a number
of ways, but none of those ways is compelling in a business sense.
That means that Go faces a slow adoption curve. I think that will be
true for any new general purpose language. Certainly it took many
years for C++ or Java to gain significant adoption, more years than Go
has been around as of yet.

I think the right approach for Go is not to try to develop a
compelling business case, because I don't think that can succeed and I
think that attempts will simply look desperate. The right approach is
to continue to reduce barriers to adoption, by continuing the improve
the documentation and the tooling, by continuing to describe success
stories with Go, by continuing to improve performance.

Ian

[GreatOdinsRaven]

A lot of languages become popular after someone somewhere develops a "killer app" that captures people's attention. 

Ruby languished in relative obscurity *for years* until Rails. When Rails was new, it was common for people to be surprised to learn that Ruby had existed prior to Rails or that it was a general purpose language at all. Ruby now is *huge*, yet it offers relatively few "killer features" in the language proper. I really can't think of any real, measurable reason why anyone would choose Ruby over Python (or vice-versa) outside of personal taste as far as syntax goes or "community feel" (hard to describe this one, but the communities are definitely different). 

They're both 90's era, single-threaded, global-lock, interpreted languages that offered productivity gains over C/C++. That's really it, isn't it? Compared to Go, both are pretty mundane and boring, yet both became massive successes. But only after being single-man projects for nearly a decade! Compared to those two, Go is already a flabbergastingly stupendous, humongous success. Think about it - 3-4 years old an already used in production in Google for critical projects. Python after 3-4 years of development was probably never used anywhere outside of Guido's and a 2-3 other brave souls' personal PC's (no offense to Guido/Python, etc, just trying to put things into perspective). 

Let's look at the other behemoths - C++ and Java. 

C++, which in my opinion is a horribly designed language (really, 3-4 languages lumped together, but that's a different topic), had a *massive* marketing push and massive industry support because it was sold as a better C. It just happened to be in the right place, at the right time and convinced (swindled) our entire industry into adopting it. We're still paying the price for that. Were C++ designed *now*, in *this* century, it would not be taken seriously. 

Java - I don't believe Java would have ever been such a success had C++  not been a failure. Had C++ delivered on sane memory management (C++11 finally gets most of it right), package/dependency management and a clean syntax, together with decent compile speeds), I don't think there would have ever been a reason for Java to exist/succeed. In a way, Java was also in the right place, at the right time - the Internet was taking off and companies needed to release a product without spending 10 years to train up a C++ programmer only to have them leak memory all over the place. 

This is why Go faces an uphill battle - we now have lots of *good* languages, so the case for Go is just more difficult, but not impossible. There can be no reason why it can't succeed - all the signs are there. I chose it for my cloud app (may it live to see the light of day) over C#/Java, and those are the two I'm most comfortable with. I'd have *never* chosen PHP (older, more mature) over Go, and I don't see a compelling reason to choose Ruby/Python over Go either (yeah, they do have *more* packages, but Go is catching up), and those have a decade or even two of history over Go. From what I can tell, I'm not alone in this way of thinking either. 

I think some might people might just be too impatient. Go just hit 1.1. People are learning of its existence, giving it a try. Some stick around, some don't, but eventually, a killer app *will* be developed, by someone on this mailing list, and Go will just ... *explode* in popularity. Of this I have no doubt. 

On Wednesday, May 22, 2013 3:01:10 AM UTC-6, Bienlein wrote:

Hello,

I found this statement in http://go-lang.cat-v.org/quotes:

“I have reimplemented a networking project from Scala to Go. Scala code is 6000 lines. Go is about 3000. Even though Go does not have the power of abbreviation, the flexible type system seems to out-run Scala when the programs start getting longer. Hence, Go produces much shorter code asymptotically.” — Petar Maymounko

This sounds really exciting and puzzles me. I would like to know whether it is true and, if so, how it can be explained. At first sight it seems as if the advances in programming languages since C were almost of little use as what expressiveness is concerned (aka lines of code). Some modernized C comes along like Go and beats the heck of all languages that are supposed state-of-the-art like f.ex. Scala (you know what I mean, so please no discussions whether Scala is state-of-the-art or not ;-)).

How can this be explained? Delegation and implicitly implementing interfaces results in such code reduction? I wished I would understand this better. Any ideas?

Cheers, Bienlien

[Joshua Marsh]

On Thursday, May 23, 2013 11:32:04 AM UTC-6, Ian Lance Taylor wrote:

As a new language, Go certainly does face significant barriers to
adoption.  This is true of any new language.  It's always easier to
keep doing what you have done in the past.

In talking with my colleagues, we came to the a similar conclusion.  They've been using Java for a while and changing seems too difficult. This is in part because the engineers are seen as cogs that can easily be replaced with any other Java cog. For them, finding a Go replacement cog is too high of a risk. The only reason we are still using Linux, Perl, C, etc. within my team is because we were acquired and switching over is not cost effective.

[Nigel Vickers]

Thankfully, no! Writing Cobol would be like fighting a whole forest full of bengals. We have a bunch of guys with extremely long, manly beards for that sort of work.

 Would you guys please leave COBOL out of the discussion! The power of COPY REPLACING / CALL COBOL CHAINING running on Multiple workspaces on Multiple machines without JSON/BSON, protocolbuffers, SQL, JDBC, ODBC or whatever, makes the early 70's seem so clean and simple... or maybe I am so old I am forgetting what it was really like.