December 05, 2014
On Thu, 04 Dec 2014 14:12:48 -0300
Ary Borenszweig via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Twitter has some real value for the humanity.
( /me eats his cigarette )


December 05, 2014
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
> It's an argument for Java over Python specifically but a bit more
> general in reality. This stood out for me:
>
>
> !…other languages like D and Go are too new to bet my work on."
>
>
> http://www.teamten.com/lawrence/writings/java-for-everything.html

High risk, high reward.
December 05, 2014
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
> It's an argument for Java over Python specifically but a bit more
> general in reality. This stood out for me:
>
>
> !…other languages like D and Go are too new to bet my work on."
>
>
> http://www.teamten.com/lawrence/writings/java-for-everything.html

Also relevant:
http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application
December 05, 2014
On Fri, 05 Dec 2014 02:39:49 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote:
> > It's an argument for Java over Python specifically but a bit
> > more
> > general in reality. This stood out for me:
> >
> >
> > !…other languages like D and Go are too new to bet my work on."
> >
> >
> > http://www.teamten.com/lawrence/writings/java-for-everything.html
> 
> Also relevant: http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application
i didn't make it past the contents. too hard for silly me.


December 05, 2014
On 2014-12-04 14:12:32 +0000, Ola Fosheim Grøstad said:

> I did not find that odd, they are not perceived as stable and proven. Go is still working on finding the right GC solution.

There are quite a few companies using Go in production.

-S.

December 05, 2014
On Friday, 5 December 2014 at 07:33:21 UTC, Shammah Chancellor wrote:
> On 2014-12-04 14:12:32 +0000, Ola Fosheim Grøstad said:
>
>> I did not find that odd, they are not perceived as stable and proven. Go is still working on finding the right GC solution.
>
> There are quite a few companies using Go in production.

Yes, but I will not consider Go ready for production until they are out of Beta on Google App Engine. Google has to demonstrate that they believe in the capability of their own language ;-).

https://cloud.google.com/appengine/docs/go/


December 05, 2014
Well, his choice may make sense, but I see no connection between pet projects and proprietary paid work. They can't share code.
December 05, 2014
On Fri, 05 Dec 2014 08:22:03 +0000
Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Well, his choice may make sense, but I see no connection between pet projects and proprietary paid work. They can't share code.
hm. but they can. my proprietary paid projects sharing alot of code with my hobby projects. it's like i'm writing some libraries for my own use and then including parts of that in my paid work, 'cause it's much easier to simply use tested and familiar library than to write brand new one.


December 05, 2014
On Friday, 5 December 2014 at 08:34:18 UTC, ketmar via Digitalmars-d wrote:
> 'cause it's much easier to simply use tested and familiar library than to write brand new one.

Why not? There are always things to improve.
December 05, 2014
On Fri, 05 Dec 2014 08:41:57 +0000
Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 5 December 2014 at 08:34:18 UTC, ketmar via Digitalmars-d wrote:
> > 'cause it's much easier to simply use tested and familiar library than to write brand new one.
> 
> Why not? There are always things to improve.
my customers paying me for making the work done, not for experimenting and researching. that's why i'm doing researches in my hobby projects, and then just using the resulting code in my paid projects. well-tested (heh, i don't want my projects go mad from bugs, so fixing 'em is a must here ;-) and mature code. this way everyone is happy, and i'm not blocked in trying another approach or breaking some API.

if i wrote code especially for payed project, i can't use that code anywhere else: my customers payed for it, so they own it. i don't want to go into legal things with them, it's too boring.

but it's generally ok for customers if we'll saying that we will use some of our internal libraries to deliver a product faster. they don't claiming ownership on those libraries and everyone is happy.