Most of the tools that make an IDE an IDE. Refactoring abilities are very limited and basic. Quickly navigating complex code bases becomes tricky. The code completion and type annotations are often missing or just plain wrong. When compared to something like essentially any IDE offered by JetBrains it just doesn’t stack up. Prior to RustRover being released I briefly tried to use VS Code for Rust using its LSP plugin, but it was just really bad in general, it utterly failed to analyze the code and provided almost no contextual help.

Not sure how to say this without sounding like a bit of an asshole, but why should we care? What does Theia do better than VS Code? For some relevant context I don’t consider VS Code to be a good IDE, but it’s not a bad editor. I use it when I need to crack open some random file (typically markdown or JSON) with maybe a bit of syntax highlighting, but I would never use it for programming.

Article was a bit light on who the intended audience is for Theia. VS Code’s big selling points are that it’s super fast to open and has a robust extension ecosystem, is Theia going to provide the same, and how are they planning to convince current VS Code users to switch?

Yep and that’s fair, but it’s still really critical that those of us that can migrate do so. It’s a chicken and egg problem. Developers won’t feel pressured to support Linux if there’s no sizable user base, but the user base won’t grow until developers provide support for Linux. He even mentions that in that video. There’s a reason I’m only this year planning on switching my primary desktop from Windows to Linux and it’s because of how good Proton has gotten. I’ve already checked every game in my Steam library and while it’s not 100% of the library that runs, everything that doesn’t is something I don’t care about.

Nah, Linux still only accounts for about 2% of all users on Steam (active per month) so it has a long way to go still, but at least it’s heading in the right direction. If you count only English speaking Steam users that number climbs to over 5%. If Linux can get to and reliably maintain 10% that’s probably good enough to make it a first class target for even AAA releases, but it’s not there yet. The fact that so many games run fine under Linux these days is almost entirely down to the effort Valve has sunk into Proton making it relatively easy for devs to check Steamdeck support off without needing to really put much work in at all.

Going to guess his pain points are the fingerprint reader and possibly wifi/blutooth chipset. There are some of those supported but that’s still the spottiest in terms of driver support under Linux. Maybe also webcam but generally those work fine these days.

We don’t need everyone to migrate, just enough that companies and developers feel obligated to support Linux. We’re slowly getting there. Valve throwing their weight behind Linux for gaming was a massive win for Linux. Another important factor is the rise of the mobile first generations and the fact that at its core Android is Linux based. It’s not completely trivial to port an Android app to Linux but it’s at least no worse than porting it to Windows.

Microsoft may still have a stranglehold on corporate desktops, but they’ve long since lost the battle for servers and their hold on the home desktop is slipping a little more each day. Losing a significant chunk of gamers to Linux would be a massive blow to MS because it has been one of the few really unassailable markets for them historically.

I’m hoping to make the switch next month. Building out a new gaming system and going to try going all in on Linux again. Long ago I was a full time Linux user, but with the rise of Steam and the spotty support of wine I couldn’t justify staying with it. Now that Proton is good enough to cover 90%+ of my games library I’m returning to where I started.

This is a wild guess but you probably need to rerender the framebuffer when you get the resize event. I’d expect most libraries/frameworks/engines would take care of that for you, but if you’ve rolled your own using the base X11 and OpenGL libraries you might need to set that up. X11 has a lot of strange quirks due to its network centric design.

All of what you mention is possible. Which is why I’m wondering if I need android studio to learn? Or can I use something simpler for now?

So, lets unpack what exactly you mean by learn in this context. There are multiple layers of skills necessary in order to program an Android app.

At the base layer, you’ve got conceptual skills like Object Oriented Programming (OOP). There are a variety of languages that are classified as OOP, Java/Kotlin happen to be among the more popular ones at the moment. But all OOP languages will have certain design principles in common and understanding those will allow you to not only structure your own code well, but also to understand why certain APIs are designed the way they are. You don’t even need a computer to learn these skills, although having one to play around with will certainly help.

Next up from that you have the actual language. Kotlin and/or Java in the case of Android. Technically you don’t need an IDE to learn the intricacies of these languages, although it will probably help mostly in regard to your interactions with the standard libraries. What an IDE will give you is the ability to quickly navigate to class, method, and property declarations, both in your own code and in libraries. It will also provide you with auto-completion of all of the above, so you can explore library APIs in a more organic way by taking an instance of some class and simply scrolling through what methods and properties it has available. That said, if you have a web browser open you can technically accomplish the same thing by just keeping the language reference open, so this is really more of just a time saver.

Finally there’s the Android APIs. These are distinct from the standard library of Kotlin/Java and are going to be the most opaque portion of the learning process. Due to the size and complexity of these APIs, you really do want to be using an IDE here. You can write an Android app without one, but it’s going to be much harder and far more error prone.

Tutorials I find seem to want you to use AS.

That’s because Android Studio is the official IDE that google has endorsed for Android development, much like XCode is the IDE that Apple has endorsed (and developed) for iOS (and OS X) development. Unlike in the case of iOS/OS X you don’t technically need to use Android Studio, it’s entirely possible to cobble together your own set of scripts and tools to accomplish the same thing, but once again you’re going to have a much smoother time if you use Android Studio. While the actual code can be written in almost anything, Android Studio is going to provide you tools to do things like UI design, easy access to launch your code in an emulator (or connected device), as well as a very easy to use debugger, plus the benefits I mentioned previously for exploring and understanding the Android APIs.

Does it do anything special?

Basically all the stuff I mentioned previously. The ability to very easily navigate to class and method declarations or instances of interfaces is invaluable when understanding and designing your apps, and being able to easily breakpoint and step through your code is absolutely critical for fixing bugs.

Overall I’d say take a layered approach. First make sure your OOP fundamentals are good, for that you can work with anything you happen to be comfortable with. Next learn Kotlin. Once again you can use anything you want for this, although it would be a good idea to at least use something like IntelliJ community edition or Android Studio. I recommend not writing an Android app for this, instead make something simple that just prints to the CLI like a hello world type app, although hopefully with a little more going on.

Only once you’re comfortable with the above, then I’d explore making an Android app, and I would also recommend using Android Studio to do so. Once you’ve got a good understanding of OOP and Kotlin then a lot of what Android Studio provides will start to make sense.

Your issue seems to be less to do with electron or JS than it is to do with IDEs in general. Everything you said you dislike is an IDE, the ones you said are less confusing aren’t IDEs they’re text editors (some with extra macro buttons, but still not actual IDEs).

I’m confused what exactly you’re having issues with in IDEs? Part of what separates an IDE from a simple text editor is that it provides much more information to help you understand and modify complicated code bases. Perhaps your issue is that you’re simply not dealing with anything complicated enough to actually need the power of an IDE. Another possibility is that you don’t really understand the languages or systems you’re dealing with so you become confused about the extra info the IDE is providing you. Information overload, particularly as a beginner can be a very real problem as modern IDEs can be a little like drinking from a fire hose. They are by their nature information dense.

finding a high contrast theme so at least you can mostly see where one visual area stops and the next one begins

I don’t intend this to be rude, but do you perhaps have some kind of visual impairment? Could adjusting your display to use a higher UI scaling help? Maybe bump up the default font sizes? Have you tested to see if you have some kind of colorblindness? Many IDEs will have themes or options to help with these cases.

Android Studio is based on IntelliJ, it is not an electron based IDE.

In the early days of the internet that was actually the correct way to do things. Websites were supposed to be hosted at the www subdomain, while other content was supposed to go to places like ftp.whatever.com. Technically they should redirect thisstupidcompany.com to www.thisstupidcompany.com not the other way around. All that said though that concept has kind of fallen by the wayside as it became increasingly apparent that most hosts exist primarily to host websites with other uses as secondary so it became the norm to just assume the www when navigating to the root domain.

Lol, the traceroute has lyrics from Dr. Horribles Sing Along Blog as the host names.

True, but ownership does eliminate a lot of the possible sources of them.

It also massively helps with productivity

Absolutely! Types are as much about providing the programmer with information as they are the compiler. A well typed and designed API conveys so much useful information. It’s why it’s mildly infuriating when I see functions that look like something from C where you’ll see like:

pub fn draw_circle(x: i8, y: i8, red: u8, green, u8, blue: u8, r: u8) -> bool {

rather than a better strongly typed version like:

type Point = Vec2<i8>;
type Color = Vec3<u8>;
type Radius = NonZero<u8>;
pub fn draw_circle(point: Point, color: Color, r: Radius) -> Result<()> {

Similarly I think the ability to use an any or dynamic escape hatch is quite useful, even if it should be used very sparingly.

I disagree with this, I don’t think those are ever necessary assuming a powerful enough type system. Function arguments should always have a defined type, even if it’s using dynamic dispatch. If you just want to not have to specify the type on a local, let bindings where you don’t explicitly define the type are fine, but even in that case it still has a type, you’re just letting the compiler derive it for you (and if it can’t it will error).

Hmm, sort of, although that situation is a little different and nowhere near as bad. Rusts type system and feature flags mean that most libraries actually supported both tokio and async-std, you just needed to compile them with the appropriate feature flag. Even more worked with both libraries out of the box because they only needed the minimal functionality that Future provided. The only reason that it was even an issue is that Future didn’t provide a few mechanisms that might be necessary depending on what you’re doing. E.G. there’s no mechanism to fork/join in Future, that has to be provided by the implementation.

async-std still technically exists, it’s just that most of the most popular libraries and frameworks happened to have picked tokio as their default (or only) async implementation, so if you’re just going by the most downloaded async libraries, tokio ends up over represented there. Longer term I expect that chunks of tokio will get pulled in and made part of the std library like Future is to the point where you’ll be able to swap tokio for async-std without needing a feature flag, but that’s likely going to need some more design work to do that cleanly.

In the case of D, it was literally the case that if you used one of the standard libraries, you couldn’t import the other one or your build would fail, and it didn’t have the feature flag capabilities like Rust has to let authors paper over that difference. It really did cause a hard split in D’s library ecosystem, and the only fix was getting the two teams responsible for the standard libraries to sit down and agree to merge their libraries.

I’ll look into OPAM, it sounds interesting.

I disagree that combining build and package management is a mistake, although I also agree that it would be ideal for a build/package management system to be able to manage other dependencies.

A big chunk of the problem is how libraries are handled, particularly shared libraries. Nix sidesteps the problem by using a complex system of symlinks to avoid DLL hell, but I’m sure a big part of why the Windows work is still ongoing is because Windows doesn’t resemble a Linux/Unix system in the way that OS X and (obviously) Linux do. Its approach to library management is entirely different because once again there was no standard for how to handle that in C/C++ and so each OS came up with their own solution.

On Unix (and by extension Linux, and then later OS X), it was via special system include and lib folders in canonical locations. On Windows it was via dumping everything into C:\Windows (and a lovely mess that has made [made somehow even worse by mingw/Cygwin then layering in Linux style conventions that are only followed by mingw/Cygwin built binaries]). Into this mix you have the various compilers and linkers that all either expect the given OSes conventions to be followed, or else define their own OS independent conventions. The problem is of course now we have a second layer of divergence with languages that follow different conventions struggling to work together. This isn’t even a purely Rust problem, other languages also struggle with this. Generally most languages that interop with C/C++ in any fashion do so by just expecting C/C++ libraries to be installed in the canonical locations for that OS, as that’s the closest thing to an agreed upon convention in the C/C++ world, and this is in fact what Rust does as well.

In an ideal world, there would be an actual agreed upon C/C++ repository that all the C/C++ devs used and uploaded their various libraries to, with an API that build tools could use to download those libraries like Rust does with crates.io. If that was the case it would be fairly trivial to add support to cargo or any other build tool to fetch C/C++ dependencies and link them into projects. Because that doesn’t exist, instead there are various ad-hoc repositories where mostly users and occasionally project members upload their libraries, but it’s a crap-shoot as to whether any given library will exist on any given repository. Even Nix only has a tiny subset of all the C/C++ libraries on it.

So, it’s C#?

No, that’s what Java would look like today if designed by a giant evil megacorp… or was that J++. Eh, same difference. /s

This did make me laugh though. Anyone else remember that brief period in the mid-90s when MS released Visual J++ aka Alpha C#? Of course then Sun sued them into the ground and they ended up abandoning that for a little while until they were ready to release the rebranded version in 2000.

Rusts ownership model is not just an alternative to garbage collection, it provides much more than that. It’s as much about preventing race conditions as it is in making sure that memory (and other resources) get freed up in a timely fashion. Just because Go has GC doesn’t mean it provides the same safety guarantees as Rust does. Go’s type system is also weaker than Rusts even setting aside the matter of memory management.

Eww… you’re probably right. TIHI.

On a related note, I’ve always preferred t-shirt sizing over story points. You can still screw that up by creating a conversion chart to translate t-shirt sized into hours (or worse, man-hours) or story points, but at least it’s slightly more effort to get wrong than the tantalizingly linear numeric looking story points.

If I was truly evil I’d come up with a productivity unit that used nothing but irrational constants.

“Hey Bob, how much work do you think that feature is?”

“Don’t know man, I think maybe e, but there’s a lot there so it might end up being π.”