Go Developer Survey - Too Bad Xojo Never Does This

I’ve participated in several of the Golang surveys and thye publish the results. The latest one is at Go Developer Survey 2023 Q1 Results - The Go Programming Language. They seem to take the results pretty seriously and seem to be very honest with the conclusions. Changes/solutions get planned into the development cycle.

Oh, how I wish Xojo would do such a survey. But then they’d assume that those that responded were such a small subset of the language that they know better.


Yeah if you start with the assumption that the respondents are only a specific subset of overall users so the results arent representative then you might as well NOT do the survey at all

We’ve seen Xojo claim that in several ways

  • the users that come to XDC arent representative of the overall user base
  • the users that post bugs or vote for them arent “average” users
  • members of the beta testers group arent the target user group (or some variation of this)
    and that the results of their surveys arent representative of the overall user base

This Go survey seems to take seriously the fact that the people who DID respond are infested invested in a way that they ARE going to listen to their feedback.
And those who cant/dont/wont provide feedback maybe shouldn’t be taken into account based on what is assumed about them ?

Thanks for sharing the read !

1 Like

5,844 survey responses isn’t a lot to be honest, but it looked like a decent range in newbies and experts. If anything, I’d expect the experts to take it more seriously as they know the warts. The Key Finding section is pretty accurate with our usage with a mix of newbies and experienced folks.

If Xojo were to do the same style survey how many do you think would respond? Couple hundred? If that?

On a related note I fired up the Xojo IDE today for the first time in a while. What a pig!

1 Like

You’re right
I’d have expected the dev community using Go to be much larger
But response rates are notoriously low
However, there are some interesting things they did to try & get truly representative samples and how they sliced the data up.
Esp the part where it was “followers” of social media vs random prompt in VS Code.
At least they recognized they might have an issue if the only respondents were just “followers” and tried to mitigate that.

No idea
I honestly never knew how many they sent out when I worked there OR what the response rate was
I’d be surprised if they got 1000 responses
But they also dont ask the kinds of questions that are asked on the Go one.

Yeah I fire up VS pretty much daily, not VS Code, and the Xojo IDE’s arent nearly as responsive.
And I dunno what thieve one lately but I find more issues in the code editor now than ever before. A lot of times it doesnt refresh completely, autocomplete mostly doesnt present any options, and so many other screwy issues
It gets to the point the easiest way for me to work is open code in Bbedit, edit it there (and it even magically DOES offer autocomplete) and then in the IDE just use Revert To Saved all the time to test
Its way faster

1 Like

Infested? Sure you are not taking about Xojo? :wink:


Whoops ! :stuck_out_tongue:
dang autodestroy

edit : revised but left original typo in strikeout :slight_smile:

1 Like

Hundreds of thousands? :crazy_face:

well there are millions of developers sooo … :joy:

Funny, happened to me too the other day. At first I was amused at how long the IDE was taking to load, and then I was annoyed at why I was doing this to myself for so long.

If I (have to) restart IntelliJ or GoLand etc., I don’t even notice the loading time. Even if the Inc. won’t or can’t admit it, if nothing changes, in a few months they will be laughed at even by beginners. Even as a hobbyist, you should no longer have to work in this style in 2023.

I notice quite a lag in my Windows VM running VSCode with a shared repo from my Mac. But even with that lag it’s still useful long before Xojo is available.

1 Like

Yes, unfortunately. And I may sound spiteful, but I feel more sorry… it’s just ugly to see the green car being driven into the wall :frowning:

This is now only annoying for many, but soon it will simply be a no-go.

1 Like

The Ice of Xojo is nothing what can be rescued. Slow and buggy. And it will always be. The concept behind the IDE is old, feels like same age like the boat Noah was building in the Bible story. It can’t compete in any relation with IntelliJ. Not in speed, not in functionality, not in reliability, not in stability. You can’t compare them.

While Xojo is written in Xojo we have the next problem: Xojo is slow. For example String concatenation. it is at least 54 times slower than Java. And at least 65 times slower than C++. While the Xojo compiled code is slow as heck it will never be much faster. That would need an own compiler.

Benchmarking Xojo shows what is going on. And we are not speaking about a bit slower or about database connectors which are slow. Simple things. And that is a problem. Dealing with big amounts of Data for example.Costs much time with Xojo. is done lightyears faster with Java, GO, C++, C. And that makes the difference between a professional environment and a not professional one.

That shows even that the Xojo environment beside the aged ecosystem is not the right way for todays computing needs. The time is gone. But not to forget: people which are not programmers can have success with Xojo, no question. And they will be able to write applications. Also no question.

But there is a big leak of professionally. That will never go.

1 Like

I had the same. It is painful to realize that. It was not even on purpose. I had VSCode installed on my parallels Windows Installation. I needed the editor and double clicked it. And on the other Monitor I double-clicked Xojo. So I could see a race between them. Ok. Not a race. VSCode opened immediately. Xojo…you know. The only difference was: Xojo was native on that machine, VSCode on parallels. Same Situation you had.

I don’t know how people can even say that the IDE is better than IntelliJ, Rider, CLion and so on. But, what ever, I am only happy not to be in the need to use it anymore.

1 Like

I did some experiments a while back and found that workers sucked for working on things in parallel even if the tasks took a while. No idea what they are/were doing but opening a sqlite db across many workers eventually failed. But not across many help applications. Both just got a full path to the db and opened it to put results in. Workers failed when I did that with more than a hundred. Helper apps I could swing up as many as I wanted and it never failed.

But for small things workers and the severely limited ability to pass data to / from them are WAY too heavy handed. Process start up time starts to take over the delay. Real preemptive threads that can be spun up nearly instantly would be much more useful

So some of the start up could be parallelized but NOT using workers

I have a sample in C# that using tasks & async await on a group of tasks (about 300 of them) and it “just works as expected”

1 Like

Yes, you are right. That is the evidence for all that what we discussed long time. That car runs into the wall and nobody can stop it. How you want to get around that problems without even having a compiler Team and without even having native compilers? The Solution with LLVM is a good Idea. But it is not working as performant as it is needed.

Xojo has some problems exactly there. GC is slow as heck for example. And the Command Line Apps are not really the fastest ones. And there is no difference when comparing Xojo with C++, Lazarus (a Delphi Clone), Java on JVM, Java native compiled, Xojo is always: slow against them. And that should not be so.

I even have no Idea why it is so.

1 Like

I have more Thelma and Louise in my head

I’d forgotten the car is that blue green color :stuck_out_tongue:

That’s the only downside of not using the Xojo IDE anymore: that meditative time you just have for yourself and your thoughts is kinda missing ;-).

This could be another opportunity for marketing: we boot slowly so that you can optimally prepare for your coding session.

Now but there ARE some compiler issues that get in the way
But its not because of LLVM

There ARE optimizations inLLVM that CANT be used because of how text makes it way from text to LLVM to be compiled

And that could mean that code CANNOT be optimized as highly as it might be

see above :stuck_out_tongue:

GC ? if you mean garbage collection there isnt and never has been garbage collection in Xojo or its runtime

I do, or have a good idea why, but am not entirely free to say WHY this is the case

It was just an experiment to see IF workers could help and how to make that happen

They didnt/couldnt (as I noted)

But the IDE sure could work
In fact I’ve made use of it in a different project and it opens “project files” very fast because it uses a data structure that ISNT inherently single threaded

We boot slowly to give you a chance to reconsider your life choices :stuck_out_tongue:

Ah that explains something. That’s why that is so slow. While the result is done by LLVM and that does not work. Following to them there is no problem to do GC by Xojo.


So there is no Xojo made one. What results in a stupid misimplementation. Not a good Idea. Never a good Idea.