www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - My choice to pick Go over D ( and Rust ), mostly non-technical

reply HackFlackRepeat <hackflackrepeat gmail.com> writes:
https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:

 Is Go perfect? Hell no ... but one needs to way the positive 
 and negative. And to me it feels like Go has made more positive 
 decisions that actually help people develop, then D on doing 
 too much everywhere. Go is here to stay for the foreseeable 
 future, where as D... not sure and that is scary.



I totally agree. Golang is fast, well documented, therefore easy 
to learn and well-scaled. Troubleshooting and performance 
monitoring are extremely convenient with lots of tools available 
- TICK stack, New Relic, Prometheus. There are lots of guides on 
how to monitor its performance and boost it, just check this 
article out: 
https://yalantis.com/blog/go-application-performance-monitoring/
Dec 03 2020
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 3 December 2020 at 10:49:39 UTC, HackFlackRepeat 
wrote:

 https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

 On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:

 Is Go perfect? Hell no ... but one needs to way the positive 
 and negative. And to me it feels like Go has made more 
 positive decisions that actually help people develop, then D 
 on doing too much everywhere. Go is here to stay for the 
 foreseeable future, where as D... not sure and that is scary.



 I totally agree. Golang is fast, well documented, therefore 
 easy to learn and well-scaled. Troubleshooting and performance 
 monitoring are extremely convenient with lots of tools 
 available - TICK stack, New Relic, Prometheus. There are lots 
 of guides on how to monitor its performance and boost it, just 
 check this article out: 
 https://yalantis.com/blog/go-application-performance-monitoring/


If this is what matters most for you, than golang might be the 
right language for you.
For me it is every line coding I write, wheter it feels good or 
painful. I do not know any other language which makes me as 
productive and happy as D. Therefore I accept some gaps as I know 
they will be solved other time.

Kind regards
Andre
Dec 03 2020
next sibling parent reply Guillaume Piolat <first.name guess.com> writes:
On Thursday, 3 December 2020 at 11:14:57 UTC, Andre Pany wrote:

 If this is what matters most for you, than golang might be the 
 right language for you.
 For me it is every line coding I write, wheter it feels good or 
 painful. I do not know any other language which makes me as 
 productive and happy as D. Therefore I accept some gaps as I 
 know they will be solved other time.


Realized this is a 2018 thread.

The original post remarked the lack of PDF generation, now you 
can use
https://code.dlang.org/packages/printed

it's not perfect but does the job for the accountant. Unlike fpdf 
it can embed truetype fonts.
Dec 03 2020
parent reply Ogi <ogion.art gmail.com> writes:
On Thursday, 3 December 2020 at 14:47:33 UTC, Guillaume Piolat 
wrote:

 The original post remarked the lack of PDF generation, now you 
 can use
 https://code.dlang.org/packages/printed

 it's not perfect but does the job for the accountant. Unlike 
 fpdf it can embed truetype fonts.


Cairo binding for D exists since forever[1]. AFAIK, Cairo is 
capable of generating PDFs with embedded fonts.

1. https://code.dlang.org/packages/cairod
Dec 05 2020
parent Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 5 December 2020 at 14:10:24 UTC, Ogi wrote:

 On Thursday, 3 December 2020 at 14:47:33 UTC, Guillaume Piolat 
 wrote:

 The original post remarked the lack of PDF generation, now you 
 can use
 https://code.dlang.org/packages/printed

 it's not perfect but does the job for the accountant. Unlike 
 fpdf it can embed truetype fonts.


 Cairo binding for D exists since forever[1]. AFAIK, Cairo is 
 capable of generating PDFs with embedded fonts.

 1. https://code.dlang.org/packages/cairod


Yes, also imap and grpc are solved issues.

Kind regards
Andre
Dec 05 2020
prev sibling next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 3 December 2020 at 11:14:57 UTC, Andre Pany wrote:

 For me it is every line coding I write, wheter it feels good or 
 painful. I do not know any other language which makes me as 
 productive and happy as D. Therefore I accept some gaps as I 
 know they will be solved other time.


Exactly so.
Dec 04 2020
prev sibling parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 3 Dec 2020 at 12:14:57 CET, "Andre Pany" <andre s-e-a-p.de> wrote:


 For me it is every line coding I write, whether it feels good or 
 painful. I do not know any other language which makes me as 
 productive and happy as D. 


From our experience if you want to get things done in a team, on a product
that lasts for years and needs to be maintained, where you want to reduce any
tricks, complicated language constructs, etc. Golang really adds a lot to the
game.

As I wrote somewhere else, Golang's focus is not a technical featureism
driven, they have a commercial, company perspective. It's not about does it
feel good for me or so. It's just highly productive and straightforward...

I think this is the USP of Golang and it looks not many (if at all) other
languages and eco-systems have such a clear focus on these topics.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 05 2020
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 5 December 2020 at 10:02:40 UTC, Robert M. Münch 
wrote:

 On 3 Dec 2020 at 12:14:57 CET, "Andre Pany" <andre s-e-a-p.de> 
 wrote:


 For me it is every line coding I write, whether it feels good 
 or painful. I do not know any other language which makes me as 
 productive and happy as D.


 From our experience if you want to get things done in a team, 
 on a product that lasts for years and needs to be maintained, 
 where you want to reduce any tricks, complicated language 
 constructs, etc. Golang really adds a lot to the game.

 As I wrote somewhere else, Golang's focus is not a technical 
 featureism driven, they have a commercial, company perspective. 
 It's not about does it feel good for me or so. It's just highly 
 productive and straightforward...

 I think this is the USP of Golang and it looks not many (if at 
 all) other languages and eco-systems have such a clear focus on 
 these topics.


 From my daily experience I can confirm that for exactly the 
scenario you describe D is working extremely well.
Maintaining a D code base over years in a multi teams project is 
a pleasant job.

The advertising Golang does might be a lot
Better than D, but it in my experience it is just the 
advertisement.

Kind regards
Andre
Dec 05 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/5/20 11:31 AM, Andre Pany wrote:

 On Saturday, 5 December 2020 at 10:02:40 UTC, Robert M. Münch wrote:

 On 3 Dec 2020 at 12:14:57 CET, "Andre Pany" <andre s-e-a-p.de> wrote:


 For me it is every line coding I write, whether it feels good or 
 painful. I do not know any other language which makes me as 
 productive and happy as D.


 From our experience if you want to get things done in a team, on a 
 product that lasts for years and needs to be maintained, where you 
 want to reduce any tricks, complicated language constructs, etc. 
 Golang really adds a lot to the game.

 As I wrote somewhere else, Golang's focus is not a technical 
 featureism driven, they have a commercial, company perspective. It's 
 not about does it feel good for me or so. It's just highly productive 
 and straightforward...

 I think this is the USP of Golang and it looks not many (if at all) 
 other languages and eco-systems have such a clear focus on these topics.


 
  From my daily experience I can confirm that for exactly the scenario 
 you describe D is working extremely well.
 Maintaining a D code base over years in a multi teams project is a 
 pleasant job.
 
 The advertising Golang does might be a lot
 Better than D, but it in my experience it is just the advertisement.


I wish I had more fluency with Go to be able to figure its pluses and 
minuses. I find it difficult (for the kind of stuff I am inclined to do) 
to reckon that you need to implement simple functions such as min and 
max several times. But when I do e.g. shell scripting I don't care for 
such things. I wonder where Go fits - someplace where sophisticated 
abstraction isn't needed yet there's still processing and networking to 
be done.
Dec 05 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 5 December 2020 at 20:04:05 UTC, Andrei Alexandrescu 
wrote:

 I wish I had more fluency with Go to be able to figure its 
 pluses and minuses. I find it difficult (for the kind of stuff 
 I am inclined to do) to reckon that you need to implement 
 simple functions such as min and max several times. But when I 
 do e.g. shell scripting I don't care for such things. I wonder 
 where Go fits - someplace where sophisticated abstraction isn't 
 needed yet there's still processing and networking to be done.


As a language, completely uninteresting. As an ecosystem, very 
useful. Lighter than Java, still solid runtime. Good cloud 
support. Decent standard lib for webservices with plenty of 
online tutorials, like Python. Many libs that you want to use in 
Python have Go equivalents. The more people who use it for 
webservices, the more useful it gets for that space.

Not unlike Perl in the 90s.
Dec 05 2020
next sibling parent reply Daniel N <no public.email> writes:
On Saturday, 5 December 2020 at 21:07:52 UTC, Ola Fosheim Grostad 
wrote:

 As a language, completely uninteresting. As an ecosystem, very 
 useful. Lighter than Java, still solid runtime. Good cloud 
 support. Decent standard lib for webservices with plenty of 
 online tutorials, like Python. Many libs that you want to use 
 in Python have Go equivalents. The more people who use it for 
 webservices, the more useful it gets for that space.

 Not unlike Perl in the 90s.



instance, it also has an excellent ecosystem but the language is 
actually decent unlike Go.
Dec 05 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 5 December 2020 at 21:38:40 UTC, Daniel N wrote:


 instance, it also has an excellent ecosystem but the language 
 is actually decent unlike Go.


My guesses:

I think it would be that Go is perceived as more light weight. 
For cloud solutions you pay for memory usage and spin up time. 


too much resources. Right or wrong.

The trend is that big servers are less attractive and with things 
like Cloud Functions you instead have just one handler per 
executable... So you want the runtime to be very light, since 
each "server" does very little on its own. Maybe Rust or some 
other language will outcompete Go eventually though. Right now, 
I'd say that eco system stability is a big win for Go.

Anyway, I guess Go is also becoming competitive for command line 
programs because of this, as libraries useful for writing 
web-services tend to be useful for writing batch processing 
programs too.
Dec 05 2020
prev sibling next sibling parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 5 Dec 2020 at 22:38:40 CET, "Daniel N" <no public.email> wrote:



 instance, it also has an excellent ecosystem but the language is 
 actually decent unlike Go.


Because you don't want to use a decent language but a simple one that just
works.


zero-dependency binary. Again IMO a very good USP: Copy, run, works.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 06 2020
prev sibling parent reply random <frederick.mueller existiert.net> writes:
On Saturday, 5 December 2020 at 21:38:40 UTC, Daniel N wrote:


 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^^.
Dec 06 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
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:


 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^^.


This comparison is from 2018, so it might not hold true today, 
but as you see the virtues of Go is the low latency incremental 
garbage collector and runtime:

https://medium.com/servicetitan-engineering/go-vs-c-part-2-garbage-collection-9384677f86f1

It would be interesting to compare with D.
Dec 06 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
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:


 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.
Dec 07 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
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:


 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.
Dec 07 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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:


 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.
Dec 07 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
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.
Dec 07 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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.
Dec 08 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
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...
Dec 08 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
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
Dec 08 2020
prev sibling next sibling parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
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
Dec 08 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
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.
Dec 08 2020
prev sibling parent Dukc <ajieskola gmail.com> writes:
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.
Dec 08 2020
prev sibling parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 5 Dec 2020 at 22:07:52 CET, "Ola Fosheim Grostad"
<ola.fosheim.grostad gmail.com> wrote:


 As a language, completely uninteresting.


That's its USP.

Go as a language is totally boring, mostly a no-brainer. Yes, you have to
write more code, but so what. It's so straight forward, that it doesn't put
any brain strain on the programmer. Exactly what they want it to be. 

With some C background you learn Go in 1h and can read it mostly instantly.
Even the CSP multi threaded part is easy to get into.


 As an ecosystem, very useful. Lighter than Java, still solid runtime.


And things most of the time just work. Add an import, use the lib, done.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 06 2020
prev sibling parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 5 Dec 2020 at 21:04:05 CET, "Andrei Alexandrescu"
<SeeWebsiteForEmail erdani.org> wrote:


 I wish I had more fluency with Go to be able to figure its pluses and 
 minuses.


Take a time-box and give it a try. It's really easy to get into it. Dig into
all the corners you want to check and you have a good idea how it works.
Really worth the time, even if you just broaden your horizon.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 06 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 3 December 2020 at 10:49:39 UTC, HackFlackRepeat 
wrote:

 https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

 On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:

 Is Go perfect? Hell no ... but one needs to way the positive 
 and negative. And to me it feels like Go has made more 
 positive decisions that actually help people develop, then D 
 on doing too much everywhere. Go is here to stay for the 
 foreseeable future, where as D... not sure and that is scary.



 I totally agree. Golang is fast, well documented, therefore 
 easy to learn and well-scaled. Troubleshooting and performance 
 monitoring are extremely convenient with lots of tools 
 available - TICK stack, New Relic, Prometheus. There are lots 
 of guides on how to monitor its performance and boost it, just 
 check this article out: 
 https://yalantis.com/blog/go-application-performance-monitoring/


I can relate to this very much.


 well documented, therefore easy to learn and well-scaled.


This one is particularly what I'm interested in helping to solve. 
It requires more content, tutorials, and videos for D...on 
various tasks. I understand there are people who prefer such a 
learning experience.
Dec 05 2020
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 February 2022 at 09:15:13 UTC, bauss wrote:

 Why are you necroing an old post?


Spammers. They seem to wake up this thread from time to time. 
Might be a bot.
Feb 01 2022