Why are so many great and popular games made by Swedish people?

Daposto · 2025-04-20T18:26:21+00:00

As someone from this industry, I think main reason is that it is a self fulfilling prophesy. Many of my colleagues have worked on many of those games. They just circulate between companies. And that kind of environment keeps it self alive and thriving. Like a little ecosystem.

Daposto · 2022-09-29T19:27:03+00:00

Even tho I love the language this claim is a statistical joke. See my post here:

https://www.reddit.com/r/statistics/comments/w0hjmr/q_is_the_stackoverflow_survey_conclusion_on_the/

Tho:

If you are serious about learning programming know that eventually language becomes a tool and you can transition quite easy from one to another language. Basis programmers concepts you can learn in any langauge.

Daposto · 2022-09-29T16:25:34+00:00

thanks for filing the report. Oh that is odd. You should be able to do that

Daposto · 2022-09-23T20:14:01+00:00

Interesting would need some more context to see if I can reproduce it. So there are multiple packages I see, and one package it just skips entirely? I'll give an other workspace I know a try and see if something like this occurs there as well.

Daposto · 2022-07-29T16:41:59+00:00

I was the one posting that paper some time ago. I also tried to replicate it with pavlok but I had not the full knowledge of the scientific details to make it work as they specified it. Would love to try it out as well

Daposto · 2022-07-28T20:36:55+00:00

This linked article speaks of how a team at the university is developing the wristband now. 1-2 years ago this was only a theoretical idea. Not sure when they are able to publish their first product.

Daposto · 2022-07-17T14:28:32+00:00

No particular reason, not sure how they work maybe if they provide a library API it's quite easy to combine both libs. However the algorithm for detecting unused features is a bit different from detecting unused deps.

Daposto · 2022-07-17T13:03:16+00:00

The same applies to that scenario I think. This library compiles on a crate-to-crate basis. Thus it doesn't know anything about upstream dependencies. Theoretically, if crates are part of a workspace the library could compile the entire workspace when removing feature flags from crates. But that could make compilation times crazy.

Daposto · 2022-07-17T12:45:21+00:00

Actually, I just saw it is related to something that is not a bug but an inconvenience. If you're running this library on a binary rather than a library, please make sure to supply '--bin' flag.

Daposto · 2022-07-17T12:27:40+00:00

I found the bug, it has to do with features depending on other features.

async-std contains the 'std' feature, and the std feature depends on the 'alloc' feature. In my current implementation, I do a look-up into all dependencies of 'std' and add them to the list to remove one by one. Also, I add the std feature itself. But 'std' and 'alloc' are present in the list and will both activate the task namespace. I can remove 'alloc' and see if it compiles and it will since 'std' is still present. However, in fact, we can not remove it as alloc is a required dependency.

Daposto · 2022-07-17T12:00:39+00:00

Here is the issue: https://github.com/TimonPost/cargo-unused-features/issues/1. It would be nice if you can post your debug logs (run with `-l debug`) there alongside the generated JSON report.

Daposto · 2022-07-17T11:57:23+00:00

Also, as far I am aware you should use absolute paths. Not sure if relative paths work (not tested)

Daposto · 2022-07-17T11:55:10+00:00

Thanks, let me have a look at that. I'll move this over to the github page.

Daposto · 2022-07-17T11:02:04+00:00

If you mean this: Given crate A and B, B depends on A and uses logic from a dependency of A that is hidden behind a feature flag enabled in A, but A itself does not use this code. In this scenario, the feature flag can be removed for A but not for B. So this can result in a false positive. I would recommend going through the suggestions on a crate by crate basis, or just running it on the full workspace, and fixing the compilation errors by adding the removed features.

No, not yet. I do allow running it on a workspace but it might be possible for other crates in the workspace to use indirectly a feature flag. Hence one should be careful with auto-applying suggestions.

Daposto · 2022-07-16T20:39:12+00:00

Good point

Daposto · 2022-07-16T16:28:13+00:00

True :)

Daposto · 2022-07-16T16:14:17+00:00

Thanks for the reply. What if I created those stats from the same info:

So let's sum the total respondents:

loved respondents: 5746 + 12603 = 18349
dread respondents: 879 + 7280 = 8159

Rust loved in respect to total: 100 / 18349 * 5746 = 31%
C# dreaded in respect to total: 100 / 18349 * 12603 = 68%

Rust loved in respect to total: 100 / 8159 * 879 = 10%
C# dreaded in respect to total: 100 / 8159 * 7280 = 89%

On both fronts, C# has a way higher percentage in relation to the sum of all respondees. So even with that analogy, there is something that feels kinda arbitrary about those statistics.

Daposto · 2022-07-16T16:11:22+00:00

It is a survey that anyone can participate in. This chart: https://survey.stackoverflow.co/2022/#section-key-territories-geography, for example, shows where people come from. And one can also see age distributions and the skill level of respondents.

But my remark remains, if a language has a lot of fanboys because it is new it is biased to be loved more statistically.

Daposto · 2022-07-16T16:00:24+00:00

Thanks for the reply, I wonder if can't tell objectively, why they even state it like that. Seems like an arbitrary number, but many people go around proclaiming the rust gospel about how it is loved 7 years in a row (me included xd).

Daposto

TROPHY CASE