On Tuesday, 8 December 2020 at 00:44:57 UTC, Ola Fosheim Grostad wrote:
> On Tuesday, 8 December 2020 at 00:01:21 UTC, aberba wrote:
>> On Sunday, 6 December 2020 at 19:37:31 UTC, random wrote:
>>> On Saturday, 5 December 2020 at 21:38:40 UTC, Daniel N wrote:
>>>>
>>>> But what I don't get is, why would anyone choose Go over C# for instance, it also has an excellent ecosystem but the language is actually decent unlike Go.
>>>
>>> Learn to implement basic data structures like in C? (no generics 2020 wtf!)
>>>
>>> To use a weird way of duck typing in a typed language? (interfaces and upcoming generics)
>>>
>>> I don't get it too. The language is hilariously bad imho^^.
>>
>> We tend to focus on the language itself too much. Project managers care about delivering results ASAP. So they'll go for something with a matured ecosystem of tools and packages...to get things done.
>
> Actually, I think there should be much more focus on fixing the language and runtime. Go builds on experience with plan9, they did not start from scratch. They had iterations that predate Go.

Go builds on the experience of Inferno and Limbo. Apparently people keep forgetting Plant 9 was just the middle stop station.

http://doc.cat-v.org/inferno/4th_edition/

http://www.vitanuova.com/inferno/

And Project Oberon as well, namely the Oberon-2 language revision, https://en.wikipedia.org/wiki/Oberon-2

The container devops world has made knowing Go a must have skill, regardless how we think about its design.

On Tuesday, 8 December 2020 at 07:25:17 UTC, Paulo Pinto wrote:
> Go builds on the experience of Inferno and Limbo. Apparently people keep forgetting Plant 9 was just the middle stop

Nobody forgot anything, Inferno is a reformulation of ideas in plan 9 implemented in Limbo. Go tooling borrows from plan 9 afaik.

On Tuesday, 8 December 2020 at 07:47:10 UTC, Ola Fosheim Grostad wrote:
> On Tuesday, 8 December 2020 at 07:25:17 UTC, Paulo Pinto wrote:
>> Go builds on the experience of Inferno and Limbo. Apparently people keep forgetting Plant 9 was just the middle stop
>
> Nobody forgot anything, Inferno is a reformulation of ideas in plan 9 implemented in Limbo. Go tooling borrows from plan 9 afaik.

Just like Inferno uses the Plan 9 compilers for kernel.

Go is Limbo with Oberon-2 method syntax.

Here,

"Evolving Languages: 5 Steps to Go"

https://www.youtube.com/watch?v=gFMZgJfIEPM

I love how the presenter calls Plan 9 a diversion, after all Alef was dropped from Plan 9, only to be brought back in Inferno.

On Tuesday, 8 December 2020 at 08:50:15 UTC, Paulo Pinto wrote:
> I love how the presenter calls Plan 9 a diversion, after all Alef was dropped from Plan 9, only to be brought back in Inferno.

It sounds like he has ties to the current owners of Inferno...

The irony is that Inferno/Limbo looks like an attempt to compete with Sun's Java, with vm/jit, but Go is actually able to compete with Java because it doesn't use a jit...

On Tuesday, 8 December 2020 at 09:25:31 UTC, Ola Fosheim Grostad wrote:
> On Tuesday, 8 December 2020 at 08:50:15 UTC, Paulo Pinto wrote:
>> I love how the presenter calls Plan 9 a diversion, after all Alef was dropped from Plan 9, only to be brought back in Inferno.
>
> It sounds like he has ties to the current owners of Inferno...
>
> The irony is that Inferno/Limbo looks like an attempt to compete with Sun's Java, with vm/jit, but Go is actually able to compete with Java because it doesn't use a jit...

Yes Inferno/Limbo was an attempt to compete with Java on the embedded space.

Any savvy Java developer knows that Java has AOT support, and JIT caches since around 2000, it is a matter to care to actually use them, and having the budget to buy those third party JDKs.

Go still needs to work out on its compiler optimization story to actually compete with Java servers in performance outside hipster circles.

https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=composite

On 8 Dec 2020 at 01:01:21 CET, "aberba" <karabutaworld@gmail.com> wrote:

> We tend to focus on the language itself too much. Project managers care about delivering results ASAP. So they'll go for something with a matured ecosystem of tools and packages...to get things done.

Well said, and those project managers make the decision what to use.

And, it's not only about delivering ASAP, which implies that I can keep my team productive, which means a simpler, limited language is better.

However, maintainability is key too. I need to ramp-up new team-members as quick as possible. They need to understand foreign code ASAP, they should spend time on the code base, not fiddling around with the tools or language specs to understand what they see.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Tuesday, 8 December 2020 at 17:29:58 UTC, Robert M. Münch wrote:
> And, it's not only about delivering ASAP, which implies that I can keep my team productive, which means a simpler, limited language is better.

In Go it means more code that tends to be more difficult to read (in comparison with Python).

> However, maintainability is key too. I need to ramp-up new team-members as quick as possible. They need to understand foreign code ASAP, they should spend time on the code base, not fiddling around with the tools or language specs to understand what they see.

Actually, a powerful IDE with a language that supports high quality static analysis is the best option. They certainly should learn the tools.

Advanced metaprogramming can be hurtful to reading comprehension, which is why I think a language should fully separate library code from application code. Impulsive metaprogramming is just a bad idea for a program that is supposed to grow over time.

On Tuesday, 8 December 2020 at 00:01:21 UTC, aberba wrote:
>
> We tend to focus on the language itself too much. Project managers care about delivering results ASAP. So they'll go for something with a matured ecosystem of tools and packages...to get things done.

On the other hand, depending on what is being done, the ecosystem need might be relatively simple. For instance, if one needs just your average GUI widget library with no interest for any advanced library features, there is no major difference between D and Go. Both have fully functional GUI libraries, so it makes sense to let the language features to decide which one to prefer.

Of course, the above applies only to some applications. Not nearly every application is so independent of the ecosystem.