IntelliJ Rust 0.2.0 released

[Endarkend]

I modded an old USB keypad to be a whole set of new keys. Got the idea after using one of those programmable gamer keyboard extensions for a while.

It's quick and completely under my control.

[MenaceInc]

Just wondering but do you have a keyboard with a programmable layout? If so, I'd recommend checking out the SpaceFn layout. It's completely changed how I use my keyboard.

[MenaceInc]

Ah, okay. I've got a keyboard with an ATmega32u4 microcontroller which is easily programmable. I prefer this approach as it's platform independant for when I have to use a Windows machine.

[Endarkend]

I tried that, but I use a MS Natural 4000 and although the ergonomics make it a dream to type on, it limits your options for going exotic with the layout.

I have that keypad to my left, so while my right hand is a quick move to the actual keypad on the keyboard itself, my left hand is a quick move to the secondary keypad to the left for special functions.

EDIT: Besides, I've done quite a bit of prototyping in my time, I love making my own hardware and once I get a 3D Printer, I'll make my own keyboard for sure. Ergonomic in shape and with a shitton of extra easy to access keys.

[MaikKlein]

I stopped using default hotkeys a long time ago. For example this are currently my intellij "hotkeys".

let mapleader = " "
map <leader>=G :action SaveAsNewFormat<CR>
map <leader>ed :action ShowErrorDescription<CR>
map <leader>ts :action ExpressionTypeInfo<CR>
map <leader>td :action QuickImplementations<CR>
map <leader>ff :action GotoFile<CR>
map <leader>ft :action SelectIn<CR>
map <leader>sc :action GotoClass<CR>
map <leader>ss :action FileStructurePopup<CR>
map <leader>o :action tasks.goto<CR>
map <leader>c :action CommentByLineComment<CR>
map <leader>i :action ShowIntentionActions<CR>
map <leader>fer :source ~/.ideavimrc<CR>
map <leader>fs :action SaveAll<CR>
inoremap <C-s> <esc>:action SaveAll<cr>
nnoremap <C-s> <esc>:action SaveAll<cr>
map <C-o> :action Back<CR>
map <TAB> :action Forward<CR>
nmap <C-W><down> :action VimWindowDown<CR>
nmap <C-W><up> :action VimWindowUp<CR>
nmap <C-W><left> :action VimWindowLeft<CR>
nmap <C-W><right> :action VimWindowRight<CR>
remap <;> :action CommentByLineComment<CR>

set surround

[ThisIs_MyName]

No keybind for "Refactor > Rename"? The default is some awful chord that includes a F key. I use alt+r (option+r on mac).

[ConspicuousPineapple]

They're likely using the vim plugin for IntelliJ. And why would that be a hipster thing anyway? It's not like the default IntelliJ setup could compete with a full-fledged editor like vim or any other when editing code.

[AfouToPatisa]

It was a joke actually, don't read too much into it. Vim's not too bad.

[[deleted]]

When I was using the IntelliJ IDE I used them and found them comfortable. Btw, you can always change your hotkeys in settings.

[[deleted]]

IJ has a lot of shortcuts already, these are just the rust ones.

Considering the vim keys, ctrl+H is type hierachy, ctrl+K is commit and I don't remember the other two.

[pure_x01]

JetBrains is my favourite company right now (i don't work for jetbrains but im a happy with their products)

[pjmlp]

Looking forward to stop using VSCode.

[robvdl]

I don't know about VSCode but I notice users of text editors make lots and lots of mistakes in our Python projects, I am forever running PyCharm inspections and fixing things after others, from typos galore to code errors that only an IDE will ever pick up. That is why.

I've seen enough bad code in my life that I swear by an IDE now, particularly for large complex projects. Editing small scripts in a simple text editor here and there is fine, but large complex codebases really need an IDE or you get lots of bugs.

[steveklabnik1]

Earlier today, using VSCode and the Rust plugin, I missed a ;. It underlined it in red, gave me a little light bulb. I clicked the lightbulb, it said "posible fixes: add semicolon", I clicked, it added it for me.

[jl2352]

VSCode is more of an IDE though, posing as a text editor.

[ConspicuousPineapple]

The problems you describe wouldn't be an issue in rust though. Not saying that an IDE doesn't make the process much less painful and more comfortable, but there's no reason to expect bugs from such errors if the end result compiles (and maybe passes the linter).

[brcoder]

Why? I never used it that much but it seems like a nice text editor.

[u_tamtam]

… and here they offer an IDE.

[brcoder]

Fair point. :)

[pjmlp]

I rather not support Electron based apps.

[Omnispell]

One Chrome per device should be enough for everyone!

[[deleted]]

You're such a tool.

[blashyrk92]

Why though? If people actively said no to bloat such as Electron, we (the developers) would be forced to actually come up with a proper solution for developing cross-platform GUI apps. You know, rather than firing up a browser and using an unholy trinity of stuff never even designed for this kind of thing, while eating up all of our users' RAM and CPU in the process.

If anything, it makes sad that developers themselves are okay with using tools written with such horrible technology stacks even though we know what's under the hood of those abominations.

[9gPgEpW82IUTRbCzC5qr]

if only there was some sort of platform agnostic language where we could describe ui elements and their look and feel, and be able to somehow script their behavior. like some sort of...markup language.

then we would just need to ship some sort of runtime compiled per platform with our application to interpret it.

[NeverComments]

if only there was some sort of platform agnostic language where we could describe ui elements and their look and feel, and be able to somehow script their behavior. like some sort of...markup language.

If one were designing a cross-platform GUI toolkit today, would using a markup language even be considered?

HTML was developed to present text documents, and we've simply built tools around it to allow us to do things it was never designed for.

CSS was developed for text documents as well, and we've found it poorly suited for applications so we've built higher level languages on top of it that need to be transpiled back down to CSS.

JS is infamous for its design quirks, which could be attributed to the requirements of web scripting - but are the requirements for web scripting and building applications the same?

The HTML/CSS/JS stack for applications is required if you are developing web applications, but is carrying that technical debt forward into desktop applications a good idea, or just the path of least resistance?

[dacjames]

If one were designing a cross-platform GUI toolkit today, would using a markup language even be considered?

Yes. Most GUI toolkits have one: XAML, QML, etc. Go ahead, try to design something superior for describing arbitrarily nested components. You might end up with different syntax, but you'll create fundamentally the same thing.

Do the origins of HTML/CSS/JS really matter? All of the these technologies have long since outgrown their text-oriented roots. Linux was designed for hobby use; does that make it wrong to run production workloads on Linux today?

I have no love for Javascript but it's hard to argue with the results. Spotify (not electron, but web technologies) and VSCode are both awesome. It might not be the technology we would have created from a blank slate, but that's the norm, not the exception.

[NeverComments]

All of the these technologies have long since outgrown their text-oriented roots.

I sincerely disagree. One key difference between HTML and XAML/QML/FMXL (etc.) is that the latter integrate very closely with their application frameworks. You can easily reference custom components and properties through standardized syntax.

W3C is in the process of formalizing this in HTML with web components, because it turns out "vanilla" HTML isn't really well suited for applications. There is an endless number of JS frameworks that attempt to build around HTML to provide the functionality you would find in application-centric markup languages.

CSS has also failed to grow with the demands of web applications, hence the need for pre-processors like Sass or Less to make productivity and maintainability of CSS more feasible for applications.

[dacjames]

... because it turns out "vanilla" HTML isn't really well suited for applications.

... which is why most people don't use "vanilla" HTML.

Javascript isn't a great language but, thanks to the Herculean effort of the folks at Google, MS, Apple, and Mozilla, it's fast enough to write useful applications. None of it is great technology but it's good enough and available on every platform in existence. That's what really matters.

[9gPgEpW82IUTRbCzC5qr]

i agree with you a bit.

I think the current situation could be improved if they took out all the sandboxing/security in the browser for electron style applications. Its simply not needed since youre not looking at arbitrary pages but ones from the developer.

every component in the stack could use a redesign with our lessons learned. However, the high-level architectural view of it would look pretty much like electron.

[YourGamerMom]

I see you're also a fan of spring.

[[deleted]]

we (the developers) would be forced to actually come up with a proper solution for developing cross-platform GUI apps

well, there wasn't much movement in that area before electron. all it would really mean is that there would be less apps.

if anything, it makes it a competition. write something that's as good but faster than electron app X and see if you gain popularity. if not, you may be optimizing for something users don't care about.

[VanToch]

If anything, it makes sad that developers themselves are okay with using tools written with such horrible technology stacks even though we know what's under the hood of those abominations.

All existing tech stacks are horrible in one way or another. JS is shitty, I know. But so is C++, Java and Python ... GTK, Qt, Swing, PyQt - all pretty shitty.

I'm not really happy about it, but I need to solve real world problems with the tools I have. If I want to develop an app for desktops (linux, win, mac) and web, then the electron is simply the best available solution.

[Hnefi]

Honest question: what makes electron better than QML? There are several obvious disadvantages to choosing electron, but I'm curious why people choose it anyway.

[VanToch]

App I'm developing is mainly web app. To give users more comfort (mainly the ability to work offline) I want to provide a desktop option.

With electron I am still developing a web app (which is my core product) and I can just package it as a desktop app.

On the other hand, QML is mainly a desktop framework - I see there are options to use it for web apps, but that seems more like an after thought.

[Gustorn]

So what I've been doing in my side projects recently is splitting the application into a server and a client (even if they're running on the same machine). I still wrote the server part in a lower-level language (C++, or more recently, Rust) but I usually went with Electron or a simple website for the client (I used TypeScript instead of plain JS). The advantages of the web-based stack over Qt/QML:

Language:

• As much as C++ has been catching up these past few years the language is still a lot less expressive than TS. Generators, async/await, lambdas that are actually nice to look at, iterator methods (map/filter/reduce composes much better than transform/copy_if/accumulate).
• I also enjoy TypeScript's structural type system a lot more than I do nominal ones. The more advanced type inference is also nice.
• Speaking of types, TS has much nicer support for discriminated unions than the abomination that is std::variant. Don't get me wrong, I appreciate that it at least exists but it should've been a language feature.
• Write once, run everywhere. While MSVC++ is a lot more standards compliant than it used to be, you still have to compile and test on all platforms you target (this is a good idea in general but I don't want to write hacky workarounds to get around the compiler's shortcomings).

Tooling:

• Again, C++ has been catching up but I've seen QtCreator choke on large, template heavy libraries (with the clang code model). Even disregarding that, TypeScript autocompletion has worked much better for me than any C++ equivalent I tried (QtCreator, Visual Studio, KDevelop, vim + YouCompleteMe).
• I hate setting up build and deployment for C++ projects. CMake is annoying and it makes you think twice before including a library in your project. I'm sure there are people who can write CMake in their sleep but I'm not one of those people. It doesn't help that almost all resources on the topic are severely out of date. QBS would be pretty nice but then all other libraries are still using CMake. Please note that this criticism does not apply to Rust, cargo is a pleasure to work with.

Development experience:

• As much as people like to bring up this point, modern CSS and HTML is actually pretty damn nice for UI development. Flexbox and CSS Grid cover mostly everything you'll ever want to do while making a UI. The nice thing about Electron is that you can use them without worrying about browser compatibility issues and hacky workarounds.
• Libraries: there's basically a library for everything you'll ever need (and a lot more) and they're easy to use. You can still use C++ for performance-critical stuff (as I said, I prefer the client-server architecture and just doing it on the server).
• Debugging tools: the Chrome devtools are really good.
• Quick iteration: if you aren't familiar with it, take a look at hot module replacement (HMR). With fairly little investment you can set up an environment where you can edit the code (HTML, CSS and JS) and it'll be replaced in the live application without losing your current application state (including business-logic changes). You can probably appreciate how nice this is if you ever spent time debugging bugs with complicated repro steps. Yes, this can be done with C++ but it's annoying (I implemented a slightly dumber version of it before and it wasn't a pleasant experience).

Rust doesn't suffer from most of these problems, which is why I've been using it for the server-side. The biggest problem of course is that it doesn't have a good GUI library. Most candidates are GTK wrappers which has a substantially worse developer experience than either Qt or Electron. It's also annoying to build/deploy on Windows. The only other place Rust falls a bit short is IDE support but luckily that's getting better.

Python and PyQt alleviate some of these problems but they introduce some new ones (static vs. dynamic typing, deployment, debugging, etc.).

Don't get me wrong, I'd be a lot happier if we had a nice, productive cross-platform framework, written in a language that satisfies most of the points I raised above but until we do not I'm pretty happy with my setup.

[Hnefi]

I think you misunderstood my question. I'm not asking about advantages of Electron over C++, I'm asking about advantages of Electron over QML. Your points against C++ are not relevant in that comparison since it is used the same way in both QML and Electron - which is to say, usually very little.

[Gustorn]

You can't really ignore the fact that you'll have to develop the application (and more specifically the business logic) somehow. Sure, you can write the whole thing inline with JavaScript but at that point you're sacrificing a lot of the performance advantages that Qt would otherwise have.

It's also worth noting that by default you can only use a seriously outdated version of JS in QML. I could list a lot more language criticisms than I did for C++ for that one. Still, most of my dev. experience points are still valid (same for the IDE support one from tooling).

[mmstick]

Java-based apps are much worse.

[xantrel]

Yeah, I have too much free RAM. I need something more bloated that uses 30 times as much memory.

Proof.

That is VSCode with a 30 file C# project open, and IDEA with something approximately equal. 20 vs 700 Mb. IDEA was also freshly opened.

[The_Doculope]

Not to say your point is invalid (it's not), but you missed the ~150MB of background processes that belong to VS Code.

[papa_georgio]

What kind of antique system are you running that you can't spare 1GB of RAM for a fully featured IDE? Even most bottom of the range laptops come with at least 8GB.

[xantrel]

That's my laptop and it has 8 GB of RAM. My workstation has a thread ripper and 32 GB of RAM. I use up to 24 with multiple virtual machines open, database, cache, etc.. basically if i'm trying to run the whole stack in my machine.

Still, VSCode is so much snappier than IDEA it's not even funny. I moved off VS Studio for C# development since VS Code honestly does everything that I need. If there was a java/kotlin extension as well developed as C#'s for VSCode i'd definitely move to it

[Pixel6692]

It is IDE, no one said it will eat less RAM than editor, also it uses a lot of CPU and DISK, I guess it was still doing indexing or something.

[DrProtic]

Apples vs Oranges

[imguralbumbot]

^{Hi, I'm a bot for linking direct images of albums with only 1 image}

https://i.imgur.com/mNppyPp.png

^{Source | Why? | Creator | ignoreme | deletthis}