October 12, 2020
On 11 Oct 2020 at 16:46:13 CEST, "Ola Fosheim Grøstad" <ola.fosheim.grostad@gmail.com> wrote:

> Ada, Java, Eiffel are supposed to.

Yes... beside Java, the other two are already in the exotic department...

> I'm not sure if Go is a success in that department either. I suspect it tanks when programs get large.

Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits.

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


October 12, 2020
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:
> Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits.

Yes, it is a good fit for web services with medium sized code bases.

Or for Google Cloud Functions. Then you write one program for each request handler. This is where I am heading.

The advantage with such a solution is that you can write one handler in Python, another in Go and perhaps one in node.js.

October 12, 2020
On 11 Oct 2020 at 21:10:20 CEST, "tastyminerals" <tastyminerals@gmail.com> wrote:

> And I feel like you guys will just pick Go because it will get stuff done.

That's the main focus from a company perspective. We try to waste as less time & money as possible.

> When I just started learning about D ecosystem, vibe frequently popped up as one of the popular frameworks available for the language AND also a reason for ppl to jump in and try out D.

I love D, like it a lot, follow it for many years, use it from time to time... but it's not about me, but a team and a product we need to develop and maintain. There are much more non-technical aspects important then technical...

And, deciding about your tech-stack base is a path-dependent decision. Turning to something else, has a very high cost impact.

> However, as time goes, I also pick up many complaints about vibe, its performance and ease of use compared to competitors. This post just solidifies the impression. Bad documentation is the worst thing that can happen to a project which gets promoted as a one of the gems of the language ecosystem and actually hurts the language image much more than does good. Sigh...

Well... I expect a lot of people taking a look at D do it like we do with other solutions: I take a list of things I want to try out and start the timer to see how long I take to get it done. This gives a good impression of the eco-system, etc.

Taking a step back, D looks a bit scattered. A lot of stuff is there, the standard lib is pretty good, many half-done packages, many corners to take a look at. D is a big language, with a lot of concepts to learn and building up experience is not fast.

> I will never advice vibe to anyone because I know that better alternatives exist. People will use Go, Python, Ruby, Rust whatever has better docs to get it running fast and not risk wasting time.

I'm pretty sure Vide is suitable for all kind of applications today. But you need to have a higher "experimentation" scope in what you do. Once you build up experience with all this stuff, I think there is no big difference to other approaches. But the question is how long is this? 1, 2, X years?

> Sadly, this is how some languages grow and some don't. And it's not all about the corporate support, hype, GC or random luck, it's about cases like the above.

I think less is more, and D is pretty huge tpday. And, it's an OS project, so people do what makes fun.

Go is mostly driving from a corporate perspective and the OS part is a side aspect. That has some merits too.

Viele Grüsse.

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


October 12, 2020
On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad" <ola.fosheim.grostad@gmail.com> wrote:

> Yes, it is a good fit for web services with medium sized code bases.

We don't have a lot of "big project" experience with Go yet, but we would use it for a plain-old desktop application.

Even most people seem to use Go for the web services stuff, I think it might be underrate for desktop apps.

Viele Grüsse.

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


October 12, 2020
On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote:
> On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad" <ola.fosheim.grostad@gmail.com> wrote:
>
>> Yes, it is a good fit for web services with medium sized code bases.
>
> We don't have a lot of "big project" experience with Go yet, but we would use it for a plain-old desktop application.
>
> Even most people seem to use Go for the web services stuff, I think it might be underrate for desktop apps.
>
> Viele Grüsse.

Just to avoid a wrong impression, there are also a lot of projects using vibe-d with great success (small companies and big size enterprises).
In my case I needed a websocket server, which will run on Kubernetes. The documentation was available and usable. Also a sample was available as far as I remember. I had here the "get things done" experience.

Kind regards
Andre

October 12, 2020
On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote:
> Even most people seem to use Go for the web services stuff, I think it might be underrate for desktop apps.

Go is good at what it has Go libraries for, and I believe it has gotten quite a few over the past years, some that has been translated from Python. If you look at some of the awesome-go-lists on github then you get a picture of whether it will be a good fit for your project.


October 12, 2020
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:
> Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits.

Btw, Go has some major weaknesses related to tricks and surprises:

1. No exceptions... they encourage old 70s-style checking of errors everywhere. That makes code much less readable. It is possible to roll your own mechanism using their panic() feature, but most Go enthusiasts frown upon that. (ignore them, they are clueless)

2. Not as strong typing as it should have. Things related to interfaces may not be detected until runtime if you get sloppy with it. (avoid very generic interfaces)

3. I believe dynamic arrays are reallocated automatically, like in D. So in Go, if you extend a dynamic array it will relocate and old slices will peek to the old copy:
	a := make([]int, 3)
	b := a[:]
	a = append(a,4,5,6)
	b[2] = 3;
	
	fmt.Println(a)
	fmt.Println(b)
output:
[0 0 0 4 5 6]
[0 0 3]

So you have to define your own coding standard to avoid such issues. Basically, ignore what is touted as Go idioms and create a ruleset that makes sense for you.

October 13, 2020
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:
> On 11 Oct 2020 at 16:46:13 CEST, "Ola Fosheim Grøstad" <ola.fosheim.grostad@gmail.com> wrote:
>
>> Ada, Java, Eiffel are supposed to.
>
> Yes... beside Java, the other two are already in the exotic department...
>
>> I'm not sure if Go is a success in that department either. I suspect it tanks when programs get large.
>
> Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits.

Aside all the issues with the D ecosystem... which requires writing certain stuff yourself. And things like vibe.d not well documented, here's one thing that D gives that I don't get anywhere else.

D is a great language that is capable of solving any problem easier than what it'll take to do in equivalent languages.

D's ecosystem is not currently where I would want it to be... simply not enough dub packages and alternatives.

Vibe.d for instance is great but it's currently moving at slow pace because Sonke isn't able to work on it as much as he used to. Personally I think it should just focus on the core base and let others extend on it.

But it's only a matter of time. Certain things are very doable in vibe.d but I guess there's not enough blog posts on vibe.d.


D is a language you learn once and use every. Just hope the ecosystem gets better to meet business needs... getting things done.

October 13, 2020
On Saturday, 3 October 2020 at 11:31:27 UTC, Robert M. Münch wrote:
> On 3 Oct 2020 at 13:14:57 CEST, "0xEAB" <desisma@heidel.beer> wrote:
>
>> On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:
>>>  On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin
>>>  wrote:
>>>>  Because standard implementation worse?
>>> 
>>>  What do you mean with "worse"?
>> 
>> It's said to be pretty slow…
>
> Well, then it should be fixed... it doesn't make sense to spread N version because everyone things, A or B is not fitting for such a code framework.
>
> And, this argument sounds like pre-mature optimization. Who has a real life use-case where the std lib JSON thing is too slow? By how much?


The community discord is a great place to get help BTW. Wherever issue it is, I'm sure you'll find solution there.

October 13, 2020
What is weird is that rails is THE ruby application , that flask is the python application, and that dlang can't have something like that in their standard library.
An opportunity missed.
On the other hand I don't understand the interest in Java/swing when there is a good working gtkd which is a good working and beautiful framework.