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 ?
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!
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
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.
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.
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.
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”
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.
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
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.