IMO, I’d say Dioxus is more of a portable front end framework. If you’re looking for an electron alternative i.e, something to run web applications like they are native apps, I’d recommend Tauri.

Also, this might be a bit out of date, but I believe Dioxus is using Tauri’s stuff under the hood. Although I heard this before the dev went full time on Dioxus, it could’ve changed, I know they have done a lot of work on it.

To do quick and simple explanations:

var test int = 0

assign an int, var = let in rust land

:= 

This is basically an inferred assignment e.g.

a := "hello world"

The compiler will know this is a string without me explicitly saying

func (u User) hi() {}

To return to rust land this is a function that implements User. In OOP land we would say that this function belongs to the user class. In Go, just like in rust we don’t say if a function returns void so this function is for User objects and doesn’t return anything:

func (u User) hi(s string) string {}

If it took in a string and returned a string it would look like this.

map[string] int {}

I will give you that this syntax is a bit odd but this is just a hashmap/dictionary where the key is a string and the value is an int

Bruh, I do this all the time! Can’t solve a problem? Get up and walk around the house while I explain the issue to imaginary people!

I feel like helium works as well as helix. When I search Helix I don’t get the editor but if I search Helix Editor I will get what I’m looking for.

When I search Helium editor I don’t get any exact matches, but of course SEO is a dark and mystical art so your mileage may vary.

It looks like it’s 3x faster than the previous cpython wasm compilation. Recall that most of the performance improvements in python have been done in the last ~2 releases.

My distro is debian based so it’s still on 3.10 which I would guess this new wasm implementation is much closer to in performance.

Compiling to wasm also means that you can distribute a binary rather than needing people to have python installed.

What mantra? I think this maintainer is doing the right thing here by trying to understand why this fix works.

You should always attempt to address the root cause of an issue instead of slapping band aid patches onto everything.

To me it looks like the maintainer is trying to find out what exactly is wrong. “this doesn’t happen in our C implementation” implies that there’s something wrong with the rust code specifically.

From the way I’m reading it, it sounds like a super() call in a constructor must be the first thing you do or something you don’t do? I never knew that was a thing… Looking at my old java code, I haven’t written Java since I graduated, this does seem to line up?

In the article it’s said that the JiT has similar performance to the latest stable interpreter but that it’s also very unoptimised. So I would assume it’s inferior to the pypy implementation right now.

FYI, this is from 2015 and was deprecated around rust v1.0 release. It’s not a current issue.

I really don’t get it, I suppose the setting to auto fill common patterns on a form could be useful. But why do I care about an autocompleting textbox? Do you think I’ve never used a search engine in my life?

I remember watching a video of someone writing C code and making the same thing in unsafe rust. While the C code worked just fine the rust code had UB in it and was compiled to a different set of instructions.

Unsafe rust expects you to uphold the same guarantees that normal rust does and so the compiler will make all the same optimisations it would if the code wasn’t unsafe and this caused UB in the example rust code when optimised for performance. It worked just fine on the debug build, but that’s UB for you.

And I said, if op doesn’t want to learn a new language, here are some python mobile frameworks. And was explicitly asked which of kotlin/swift I would recommend for a python dev.

Sure, but how else should I compare a language I’ve never used to python?

I’ve never used swift myself, but as far as I’m aware swift doesn’t need to have a main function so I’d say it’s closer

I’m not sure if the rules are different with macros, I’ve never written one but this lint is generally caused because you set a var to a value and then overwrite that value before you use it. e.g.

let mut a = 1; a = 2; println!(“{}”, a);

This will throw the same warning because 1 is never used, this could’ve just been:

let a = 2; println!(“{}”, a);

So first I’d double check that I NEED last at all. Maybe try:

cargo clippy

See if it can tell you how to fix it.

If that doesn’t work, it’s sometimes necessary to skip certain lints. E.g. if you make a library, most of the code will be flagged as dead code because it isn’t used and you can use an #[allow(dead_code)] to stop the linter warning. You might be able to use #[allow(this_linting_rule)].

Hope something here helps.

When it comes to mobile apps, I generally recommend native (swift/kotlin) or Flutter, they all have good tooling and have good performance

In this case though, they are all curly braces languages and don’t have much in common with python.

If you don’t want to learn at least 1 new language, there are some python libraries/frameworks which can be used for mobile dev. Like Kivy or Beeware. I’ve never used any of these though so I can’t tell you how good/bad they are.

This does strike me as odd, your commits should be cleaned up if they are a mess of “reverted X”, “fix typo”, “saved days work”, etc. on the other hand, you don’t usually have to explain your modifications if you didn’t squash your commits.

It’s already been said a couple times but if your more experienced team members are saying, “that’s a really weird task” the issue is probably the task not you.

Having daily meetings with a senior because you’re having a lot of trouble progressing isn’t necessarily a bad thing. Everyone has jobs that are absolute ordeals and sometimes it’s better to break them down even further and just go one step at a time.

Also, are you involved in your team sprint planning? Who says “this ticket is a 1 day job” that should be your teammates, or at least a subset of them? Why did they decide this was an easy task? What did they, or you, miss in the execution?

In my experience this does happen on occasion, it absolutely shouldn’t be happening all the time though.

Generally when this starts to happen my team lead puts his foot down and says, no more changes until you sign off on what we have and we’ve released the MVP. After all, if the core functionality is done, then the MVP is done and we don’t need to keep sitting on it.

Mojo is a Python superset, Python is written in C therefore mojo is written in C.

I don’t know what that rust library they benchmarked against is but given that they claim to have performed 50% better I would be sceptical. Given that most sources benchmark rust, C and C++ at about the same level.