I’d rather use a language that doesn’t treat me like an incompetent child, removing unsigned ints because “they’re a source of bugs”.

Or use a statically typed language that’s actually modern instead of C

Why? In my experience using a real debugger is always the superior choice. The only time I don’t is when I can’t.

Huh? Main file? Do you mean main package? A module can contain an arbitrary number of main packages but I don’t see how that has anything to do with this post. Also are you saying modules are equivalent to classes? That may be the strangest take I’ve ever heard about Go.

How so?

Of course but presumably on occasion you do work in other languages? I work in all kinds of languages and so jumping between them it’s pretty handy to bridge the gap.

If I were jumping languages a lot, I definitely think it would be helpful. But pretty much 100% of what I’ve done for the last 3-4 years is Go (mostly) or JavaScript (occasionally). I have used chatgpt the few times I needed to work in some other language, but that has been pretty rare.

I think you could definitely still get value out of generating simple stuff though, at least for me it really helps get projects done quickly without burning myself out

If simple stuff == for loops and basic boilerplate, the kind of stuff that copilot can autocomplete, I write that on autopilot and it doesn’t really register. So it doesn’t contribute to my burnout. If simple stuff == boring, boilerplate tests, I’ll admit that I don’t do nearly enough of that. But doing the ‘prompt engineering’ to get copilot to write that wasn’t any less painful that writing it myself.

For small one off scripts it makes them actually save more time than they take to write

The other day I wrote a duplicate image detector for my sister (files recovered from a dying drive). In hindsight I could have asked chatgpt to do it. But it was something I’ve never done before and an interesting problem so it was more fun to do it myself. And most of the one off stuff I’m asked to do by coworkers is tied to our code and our system and not the kind of thing chatgpt would know how to do.

func randomRGB(uid int) color.RGBA {
	b := binary.BigEndian.AppendUint64(nil, uint64(uid))
	h := sha256.Sum256(b)
	return color.RGBA{h[0], h[1], h[2], 255}
}

That took me under three minutes and half of that was remembering that RGBA is in the color package, not the image package, and uint-to-bits is in the binary package, not the math package. I have found chatgpt useful when I was working in a different language. But trying to get chatgpt or copilot to write tests or documentation for me (the kind of work that bores me to death), doing the prompt engineering to get it to spit out something useful was more work than just writing the tests/documentation myself. Except for the time when I needed to write about 100 tests that were all nearly the same. In that case, using chatgpt was worth it.

If I’ve been working in the same language for at least a year or two, I don’t have to look up any of that. Copilot might be actually helpful if I’m working in a language I’m not used to, but it’s been a long time since I’ve had to look up syntax or functions (excluding 3rd party packages) for the language I work in.

I won’t say copilot is completely useless for code. I will say that it’s near useless for me. The kind of code that it’s good at writing is the kind of code that I can write in my sleep. When I write a for-loop to iterate over an array and print it out (for example), it takes near zero brain power. I’m on autopilot, like driving to work. On the other hand, when I was trialing copilot I’d have to check each suggestion it made to verify that it wasn’t giving me garbage. Verifying copilot’s suggestions takes a lot more brain power than just writing it myself. And the difference in time is minimal. It doesn’t take me much longer to write it myself than it does to validate copilot’s work.

My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.

That’s a hot take. If you want your code to be maintainable at all, it needs comments. If you’re part of a team, write comments for them. If someone else may take over your project after you move on, leave comments for them. And have you ever tried to read uncommented code you wrote a year ago? Leave comments for yourself.

The key difference is that compilers don’t fuck up, outside of the very rare compiler bug. LLMs do fuck up, quite often.

Copilot frequently produces results that need to be fixed. Compilers don’t do that. Anyone who uses copilot to generate code without understanding how that code works is a shit developer. The same is true of anyone who copies from stack overflow/etc without understanding what they’re copying.

It’s not just about learning a language. Given two equivalent languages, writing a project using one or the other is always going to be less work and less of a maintenance burden than writing it using both. A competent manager will take that into account when deciding what tools to use. On top of that, learning a new language has a cost. Of course Rust and JavaScript are not equivalent, but which one is ‘better’ is highly subjective and dependent on how you measure ‘better’. So a manager needs to take that into account. But my fundamental point is that using two languages for a project adds overhead, and learning a language adds overhead, so unless cost (including time) is irrelevant, there must be a compelling reason to choose a dual-language solution* over a single-language solution, and to chose a solution that requires your devs to learn a new language over one that does not. Not to mention switching platforms has a massive cost if your project is already mature. Even if you’re creating a new project, if your team already knows JavaScript and doesn’t have any particular objection to Electron, there’s no compelling reason.

If there is a good reason to learn a language then people will.

Sure. Except in my experience interviewing candidates and from what I’ve seen online, there are a lot of developers out there who aren’t very good. I am not optimistic that the average developer will have an easy time learning a new language. If the “we” in “Is this the electron alternative we’ve been waiting for” is you and I, that’s not a problem. But if OP meant to suggest there will be a large-scale shift away from Electron, then the average developer is quite relevant.

*As someone else pointed out, Dioxus is designed with the intent that you’ll right the frontend in Rust, so it’s not exactly dual-language like I thought.

Ah, well that’s great for folks who already know or want to learn Rust

I seriously doubt that a dual-language platform is ever going to supplant Electron. Electron has the major advantage that the entire app is written in one language. And according to Stack Overflow’s 2023 developer survey, 66% of devs use JavaScript, 45% use Python, 43% use TypeScript, and 12% use Rust. More devs use Java, C#, C++, PHP, and C than Rust. So 2/3 of developers wouldn’t have to learn a new language to use Electron, and only a small fraction of the remainder knows Rust.

If I designed the schema it is most certainly going to be structured. Unstructured databases are awful.

Sure, there are worse languages and environments to get stuck with. But I can avoid those jobs. And if I get hired as a SomeLang developer and they force me to work in Java or whatever, it’s time to dust off the resume.

I am aware of that, but Java is the most popular language that runs on the JVM. I don’t specifically dislike other JVM languages, though one of my issues is type erasure and that’s partially a limitation of the JVM.

Obviously OpenJDK is superior to dealing with Oracle’s bull. But even more superior (IMO) is simply not using Java. My life has been noticeably more pleasant since I started refusing to touch Java.