I would expect WSL to mostly be used in the desktop/workstation usecase... I guess there must be people using RHEL for that, but I would have thought Fedora was more common?
> I would expect WSL to mostly be used in the desktop/workstation usecase
It's heavily used for enterprise and production use cases in organizations (often legacy type orgs though ik a F250 tech company that does this as well) who don't want to use additional spend building a dedicated Linux fleet and a dedicated Windows fleet.
Before you'd have to use Cygwin and deal with some level of non-reproducibility, but with WSL you can essentially get a MS supported Cygwin.
> but I would have thought Fedora was more common
The Linux workstation usecase is extreme niche compared to the dual server usecase.
I also think there is a chunk of the audience that would like to develop on the same distro they would be deploying to. There is a fair amount of RHEL in production environments. Larger operations may be running Windows for business purposes and being able to work with WSL/RHEL on the same (or upgraded for developers) machine makes some business sense.
I did recently, while on a distro-hopping journey. It was super nice experience, IMO, next best to Ubuntu for development. It looks nice, and it runs smooth, getting up and running with my stack was super simple, no issues with JB IDEs, etc... The only reason I switched to Pop_OS was basically that I am far more used to apt commands and general Ubuntu ecosystem, not to mention most of the VMs I work with are Ubuntu server, so I don't get cognitive-stall when looming around servers...
I also end up avoiding python not because it's a bad language, but because it's so much more convenient to work with compiled artifacts that worry about shipping around a bunch of source or object files and a full compiler. Not to mention the speed of using Go and the ability to write concurrent code without a lot of effort.
The only time I really use python is when I need a quick and dirty script.
I'm an OS developer and in my view using printf is like seeing only half the world at once. There's a whole world of platform specific decisions that are made at compile time and runtime that you can only see through the lens of a good assembly debugger.
You're also talking about debugging apps running comfortably in the idillic world created by the OS. It's much harder to debug foundational pieces with printf's when the program immediately panics or early printing isn't available.
In my opinion it's good to build habits that can be generalized to all sorts of software and not limit oneself to writing code in a highly structured environment where most of the work is done for you. I can trace through a program faster than someone can insert/remove printfs and recompile their program, and I don't need to think about what to print. I can look at everything at that point in time, covert data to strings, look at the stack, registers, etc. Very powerful stuff.
I've seen so many editors come and go, and yet I've been using Vim for the past 20 years and have never had a problem. As stupid as it sounds, if I could give one piece of advice to any entry level SWE, it would be to learn Vim or Emacs and just stick with it for your whole career.
I find this and the emacs sentiment really weird. I use vim daily for quick edits, but for any sizeable codebase, especially new/unfamiliar, IDE's are just better. It's like depriving yourself of a bunch of tools and helpers for no visible benefit.
Since I graduated, I've had people try to sell me on the following editors, which were going to be the future: BBEdit, TextMate, Sublime Text, Atom, Komodo Edit, NetBeans, and Eclipse.
Each was going to kill Emacs.
Somehow, I think I'll be using a version of Emacs until the day I can no longer type.
Meanwhile, everyone else is wasting months getting up to speed on the latest and greatest thing every 8 years or so.
This adds up over a career.
Oh, and by the by, this was written in Emacs using GhostText as the link between Firefox and Emacs.
>Meanwhile, everyone else is wasting months getting up to speed on the latest and greatest thing every 8 years or so.
Yeah I used to think this way, because you're right: becoming proficient in emacs takes significant effort and time.
But becoming proficient in VS code takes maybe 25 minutes. 25 minutes to change IDEs every 8 years or so doesn't seem like an onerous requirement to me.
Emacs just has extremely poor defaults and out of box UX.
>But becoming proficient in VS code takes maybe 25 minutes.
Becoming proficient in kicking a ball takes 5 minutes. Becoming proficient in football takes slightly longer. Magit alone makes VS Code look like a child's finger painting.
>Magit alone makes VS Code look like a child's finger painting.
Magit is indeed a great git client, but I don't see what that has to do with emacs having bad defaults and an out of box experience that could be charitably described as antique.
>You'll understand in 20 years when you're on your 4th IDE which will change the world^tm.
How condescending.
But no, I probably won't mind changing editors every few years because I am capable of learning new things and do not require a safe space to keep me insulated from the outside world.
An editor is the least interesting thing to learn in computer engineering. If you enjoy wasting your time may I suggest something like stamp collecting that doesn't create billions of dollars of lost productivity for the rest of us?
Plus I’m changing editors every 8 or 4 years because the “new one” is better in some regard. VSCode is a very good editor. Sublime was a good editor too, but VSCode was better enough to make me switch. Whatever comes after VSCode will be that much better!
So there is nothing wrong at all with switching to a new editor… it just means things are getting even better!!!
Bad defaults for who? Emacs userbase is quite heterogeneous, not everyone is a swdev, not everyone is young. All it takes to have great defaults is maybe ten instructions in init.el.
So true! Now don't get me wrong, I quite like VS Code as it's so easy to set up and there is a plugin for almost anything, but I find myself always coming back to Emacs.
He's right about the defaults though. Use something like Spacemacs or Doom if you just want to dip your toes in the goodness that is Emacs.
I typed up some thoughts about the nth time I tried out Visual Studio Code to see what all the fuss was about and if my productivity could be improved vs. Emacs. I might turn it into a blog post, if I can be arsed to start a blog again.
One header read: "Not better enough". Inasmuch as Visual Studio Code does anything better than Emacs, it doesn't do things better enough to justify expending the high activation energy of switching, unlearning my Emacs workflow and learning all that I need to know to do things Visual Studio Code's way.
I honestly believe emacs UX to be fairly superior. I watch my colleagues struggle to find open files among tens of open tabs in vs code every day. Or endlessly navigating on the filesystem tree with the side bar before finding what they need.
Things that take half a second in emacs take minutes for them. And the UI is so cluttered.
There are a number of neurodiverse hackers who've "switched off the targeting computer" precisely because it's disruptive to thought to always be having to constantly juggle the state of code in your head with the fucking video game appearing before your eyes as you type. I am one of them.
Maybe i just never gave the heavyweight ide tools a fair chance, but i always found them more distracting than helpful. Focus is king for me, and vim gives me that.
idk, I find I don't miss anything from heavyweight IDEs. I switched to neovim like 6 years ago. 95% of working with a codebase, familiar or not, is navigation and editing. LSPs enable pretty much any editor to intelligently navigate to definitions and find usages of a given construct. Anything beyond that is quickly hitting diminishing returns.
The one exception is maybe untangling particularly gnarly git conflicts.
Emacs is fine, but it's not really about the visual diff and more that you get syntax checking and other features in the diff view that afaik aren't available in lighter weight tool. Neogit is quite good and is heavily inspired by magit, so it's not like they're appreciably different.
Not OP, but I was confused as well, but found that a lot of people who did this had basically created an IDE-like experience with tmux, etc around vim, etc.
Not really my thing but I guess it works for them.
What tools, what helpers? I hear this comment a lot and it's just ignorance on the part of people who clearly have never tried to actually learn how to use (Neo)vim or Emacs. I've used Jetbrains, VSCode, Atom, Xcode plenty and there's nothing that I can do in those IDEs that I can't do in Vim besides things related to platform specific SDKs.
My current codebase is a liberal mixture of C, C++, Java, and mksh. The whole project uses CMake and GNU Autotools and ndk-build and whatever the heck calling mma with AOSP does.
There's no way to unify it given how many different moving parts are involved. Trying to fit this all within an IDE would be a project of its own...
A similar mix took me under 20 minutes to get a C++ + Rust + C# + TypeScript codebase working between VS proper and VS Code. In fact, I don't remember doing anything at all to get it working except installing damn node for TS and choosing CMake configuration in a dropdown.
Everyone's brain is different, but I'd bet you'd be surprised by how good you are at things you rely on an IDE for (autocomplete, go to definition). For other stuff, sed and grep will cover 90% of your needs. Source: me, and I'm pretty good at this.
Strongly disagree, but I am in a niche field, Linux kernel development. Emacs is really struggling with it's tools. But for Neovim: the plugins and good keycombos are absolutely essential to get certain functionality for my productivity.
* rg with telescope window to quickly find text in very large code basis is essential.
* Pressing spc, spc, to bring up a telescope window of my open buffers and typing in text to narrow them, very important.
* To date I still struggle to get the LSP to work the Linux kernel on VSCode, but on Neovim I got it working.
IDE's have a lot of menu clutter that I struggle to make good use of-most programmers working on user-space apps, it is likely fine, but for the kernel, we often need more control.
First I've heard of this. As a long-time vanilla Emacs user, I'm using consult-ripgrep and rg-project for ripgrep interfaces, consult-buffer for fast buffer and file switching, Eglot for LSP integration (mainly with clangd), etc. I've also got org-mode for note taking, magit for speedy Git manipulation, etc.
And all without any visible menus or clutter.
I suspect that a power Emacs user and a power Neovim user are more akin here to each other than to VS Code users.
I mostly use kickstart.nvim in Neovim. I really like using mnemonic key bindings (which do show a menu) with the functionality above. One real issue was the lack of a telescope competitor (and I noticed you did not mention one above). I really like the quick overlay for those actions is how Telescope in kickstart is programmed. I really do not like the results smushed at the bottom of the screen like how Doom handles it.
Spacemacs got me into mnemonic key bindings, but it was too buggy and development had slowed. I got some things working with Doom Emacs, but it had a lot of bugs as well. Part of that reason is projectile also seemed to no longer be worked on. They were converting over to project.el but that seems to be slow.
I struggle to find good bundles for Emacs. Doom Emacs is struggling with migrating their plugins. Most programmers I know use Emacs with few plugins and not the better IDE like plugins in Neovim.
I probably used vim exclusively for about a decade. I've worked with a handful of developers who've only used vim and I've only known one who was anywhere near as effective with it as most IDE users. A few examples
-- debugging with print statement because they don't know how to use a command line debugger
-- using find and grep to find files/methods
-- hand-formatting files because they don't have a inline formatter or something to notify them when they've missed a semicolon or spelled a method wrong.
I strongly encourage them to move to an IDE because I can't stand looking over their shoulder and watching them code so inefficiently. There probably are vim plugins to handle many/all of these things, but if a developer doesn't put the effort in to find them than they're just hurting they're own productivity.
I'm kind of doubtful of this. Just to take print debugging as an example. While there is definitely a time and place for debuggers, i think print debugging can be shockingly efficient in many circumstances.
Besides, typing speed is usually not the limiting factor in programming speed. I think overall efficiency needs to take a broader look.
Those developers frankly sound like idiots, I don't think they should be coding at all. Also yes, all of those things are easily done in both vim and emacs.
It takes seconds or more to grep for a function, especially if it has a common name. It takes milliseconds to Go To Definition / Find Usages (either with an IDE or a LSP extension for any text editor).
If they're not using fzf, ctags or LSP at all, sure. But find and grep absolutely have their place, and I tend to use them even when using IntelliJ/VSCode.
Yes, no one said find or grep are useless, far from it. The original premise was people using grep to look for a function in a code base, or find to get to a file (presumably to get to an include file or imported module by name). And they are definitely sub optimal for this - as you mention, even outside of an IDE, there are plenty of better tools to integrate with vim or nano or ed (the standard text editor!) or whatever you prefer.
And then you go full circle when the project is bigger and Find Usages no longer works across projects (specifically in the context of a typescript monorepo) and it's back to grepping for usages.
The premise is that using proper code navigation functions will increase productivity over grep. Not that using an IDE will increase productivity over vim, assuming you use actual code navigation tools in vim.
As for the click: all IDEs and all code navigation tools for popular text editors like vim or emacs have full keyboard support. And M-. Or F2 or whatever are much quicker to type than "grep function_name".
But this is people that use their autocomplete, F8 step through debugging and the like.
I was like that about 20 years ago, working with Eclipse and later NetBeans for Java and Visual Studio for C# .net v1 (anyone remembers whole tomato extensions?).
I needed the IDE , the autocomplete, the debugger and all that. Nowadays, I do mostly Vim and Vscode for more complex projects. I don't know why, but I "grew out" of needing an IDE.
Shudder to think that in 20 years (or less!) there will be a generation of programmers who suckled at the teat of ChatGPT and firmly believe that software is impossible to write without LLM help.
No worries, I think maybe I replied to the wrong comment - I would have expected to reply to someone who can't see how an Emacs (or vi) user could be as productive as an IDE user.
As someone who programs Java daily and uses Neovim daily, I don't think I could be any less productive than when programming with Java in nvim.
Some features that I do not have in nvim, but use daily in IntelliJ: Run configurations, proper debugger, SQL integration, hot reloading, and most importantly everything just working OOTB (auto complete, snippets, docs, ...). Can (n)vim do these things? Probably, but it'd take me days or even weeks to get it configured to the point where it's as seamless as IntelliJ.
I do use the IdeaVim plugin, so not all of my muscle memory is wasted.
Java is really unpleasant to program in without IntelliJ IMO. I strongly prefer NVim for Python and C++, but still use IntelliJ for anything non-trivial in Java.
one thing missed is intellij can cross-complete over several domains, like correctly showing tables in a sql statement in a java string in your project, if you also have the database added, etc.
ive never seen any vim-with-plugins setup come close to this
Vim is great but I think VSCode really is the one tool to rule them all going forward. It's extremely well designed, snappy, and I think does the correct thing of first treating everything as a text file and allowing plugins to provide semantic meaning. I never liked visual studio because it was too specific to writing software and using the GUI to do what I wanted. Editing msbuild files directly was a pain for example. If I wanted to do some shell scripting or system debugging, I had to leave that environment.
Whereas with VSCode, I really never have to leave the VSCode environment to do what I want. I can pop open a shell within VSCode and don't have to switch windows. I can easily open random files not associated with my project and VSCode does the right thing (usually). It opens images easily, renders markdown well, etc. my favorite feature is that you can pipe cli output directly to VSCode in the shell and then it opens a tab displaying that output. You'd be so surprised how often that feature comes in handy.
I mean, nothing stops you from not using it. It's just a really well designed piece of software and it does a good job of getting out the way something a lot of IDEs don't do well (visual studio for example).
You can do all the things you mentioned in Vim. I also can't imagine that you would be comparing the performance of VSCode and Vim, my vim with all of its plugins and vim script starts up in 95ms. That's faster than the threshold of human perception.
I think you missed the point of my comment you are replying to. You can get things done in any editor. The point is that Vim/Emacs have been around for decades and last your whole career, VSCode has been around for a fraction of the time and killed off the previous editor, Atom, that everyone though was "the editor".
In college I used exclusively plain text editors, and like 80% of my edit-compile-run cycles were wasted on noise like symbol names and the ordering of positional arguments. When I got into professional life and started using JetBrains IDEs, I felt like I was flying.
I'm one of those people that doesn't like polluting his brain with a ton of keyboard shortcuts and likes clicking with a mouse on stuff and is just more efficient with it. I've seen video clips of "efficient" terminal text editor use, and while it looks cool in a hacker way, it just isn't any faster than what I do without all of the overhead of memorizing a ton of keyboard shortcuts and editor commands.
I would definitely much rather install VSCode or an IntelliJ product on a Jr's machine, show them how to setup their terminal, get their dev environment setup, how to run and debug the app, and off they go. Edit code. Run code. Debug code. Rinse repeat.
Much more reasonable and preferable to having them spend months learning Emacs. Let's remember, they likely don't know how to use the terminal either these days.
> I've seen video clips of "efficient" terminal text editor use, and while it looks cool in a hacker way, it just isn't any faster than what I do without all of the overhead of memorizing a ton of keyboard shortcuts and editor commands.
Would that still be true if the ordering of your menus (and the items within, recursively) were randomly shuffled each day, and which side submenus opened on were also randomized? How about if the speed of your mouse or mouse acceleration behaviors varied?
I think you may be discounting memorization which benefits your workflow because that memorization is spatial rather than symbolic. Perhaps there's an argument to be made that such memorization is more natural, gradual, or easy, but there's definitely memorization involved in mousing around with any degree of efficiency or speed.
> Let's remember, they likely don't know how to use the terminal either these days.
Which is a huge issue. If all you know how to do is crank up a GUI and write code, you are easily replaceable in a world where the demand for SWEs has gone way down. The best thing I ever did in my career is invest in learning how things actually work. Learning how something like Vim works is just a litmus test for absorbing and applying information quickly. Vim is just one in hundreds of tools I've learned how to use and string together.
How can you possibly be as productive as someone working in Visual Studio? I'm asking honestly - working without the solution explorer, being able to look at any immediate variable, instruction pointer dragging, and others seems like it would slow me down immensely.
With vanilla Vim, you're right. I recently switched to NeoVim after years of using VSCode, and after about 2 weeks, I am probably back at about 90% of my productivity as VSCode. I had to spend a little time learning Lua and learning the internals of a text editor, but I wanted to learn those skills anyway so I'm glad to have had an excuse. If you have no interest in those things, then I wouldn't recommend leaving VSCode.
I am also excited by the fact that the text editor configuration is programmable in a Turing-complete language, as opposed to pure JSON configurations that VS Code offers (correct me if I'm wrong, but settings are just a JSON file right?). It means that anything is possible.
In VSCode, my biggest complaint was that, for the Vim extension, the status bar was not configurable - I wanted to make the whole page change color when in "Normal" mode, versus "Insert" mode. Not possible in VSCode, but it's only a handful of lines of Lua in Vim.
Is that a huge productivity boost? No, but it makes me happy. Just as much as I want to be productive, I also want to be happy while programming
I'd give the opposite advice. Learning a new editor is fun and thankfully they are mostly inexpensive. You will build up a suite of editors that you use in different contexts and be able to talk about the differences based on experience and not just dogma.
I was a heavy Emacs user for just short of 10 years. I don't use it now because I am more productive with JetBrains IDEs. Your advice seems too rigid and dogmatic to me.
Just posting to balance things out for any entry level SWEs reading.
I don't even know what to say to this other than that you are right that it does sound stupid and it is stupid. A software developer should not be afraid of learning software, learning new things is fundamental in our work. Comparing an IDE with basic editor like vi, really, that may have worked out for you since you started 20 years ago when that worked, but it should not be the advice today.
I learn new tools and platforms all the time, but editing needs muscle memory and I don't want to abandon that every five years for the new hotness. IDEA is just starting to show some longevity for Scala and Kotlin.
Mainly, a seftware developer should not be afraid of creating neW tools to solve their own specific problems. Programmable editors like Vim allow you to do that, proprietary corporate IDEs do not.
Ok, but now every time you switch commits you have to wait for clangd to reindex. Grepping in the kernel is just as fast and you can do it without running a 4GB+ process that takes 10+ minutes to index
Sure. I wasn't intending to claim that there is no reason to care about greppability. Just providing some tips about getting clangd to work with linux for those who might find that useful.
Your argument is a false dichotomy and thus a logical fallacy. Not all steps forward in abstraction or code generation are necessary good steps and have to be considered on their own merits. If LLMs are indeed superior, then you should be able to articulate their merits without condescending to fallacious attacks.
I mean, what's holding you back from using neovim? Great plugins, same LSPs, anything that's missing you can code up yourself in Lua, works over ssh... what are you really gaining by using VSCode?
The out of the box experience is vastly superior to neovim, you have to configure a lot less stuff.
The default keybindings are not esoteric.
Adding support for a new language is just clicking a button to install the extension, you don't have to configure or install the LSP yourself (or even know what an LSP is).
For me personally, better support for c#/.net.
You can make a nice IDE with neovim and plugins and a GUI but you do have to make it, whereas you just have to install vscode and you are done.
Astronvim[0] is plug and play. Easy to add LSPs (Mason), easy to add syntax highlighting (TreeSitter), and easy to configure (Lua, no JSON).
I can't stand VSCode due to personal preference [1], but I won't fault someone else using it. If configuration is stopping you from using neovim, use Astronvim or another pre built solution.
[0] https://astronvim.com/
[1] my main beef is lack of support for my ingrained Jetbrains shortcuts and the find window being in the sidebar. How anyone can use the search results easily is behind me. I know you can move it, it's just annoying.
You can just simply ignore that find window and instead use the "Go to Symbol" feature by pressing Ctrl + T to navigate quickly between symbols (variable + function + classes + etc).
As a long time neovim users and promoter, I switched because of community support of plugins. More of them, they are up to date with libraries immediately (important in JS more than other languages), and easier to google solutions.
Also I tried switching to Astrovim so I spent less time maintaining my vim config and it ended up breaking as often as atttempt at switching to Linux distros (regardless of years of experience) so I chose stability.
i'm a Python main trying out neovim (using kickstart) and couple of weeks in my journey is a bit frustrating as switching between virtual environments is a hassle, jupyter notebooks aren't quite useful outside the browser and setting up the dap has been a challenge.
Setting up a fresh vscode install with all of the plugins 'launch.json's and takes me ~20 minutes at this point.
Not giving up on neovim as telescope, treesitter and the no-electron experience are a joy
The seemingly lack of support of jupyter notebooks was the thing that kept me from giving it a honest try. I want the same experience as in the code editor.
Have you ever tried to daily drive them? They're simply not polished enough for serious work.
Text editors seem to fall into this open source software trap where everyone has to have a pet project so you end up with 700 different text editors that are all like 70-80% done in terms of features.
Sure, but how concretely does that hold you back? Not saying I can’t imagine any possibilities, but guis aren’t universally better for editing text. In fact I usually find the gui is what is holding me back, since I end up needing access over ssh/mosh or easier access to a terminal, and tools such as tmux provide much better (imo) ergonomics than I get with terminal-in-ide especially with the ability to zoom one split to fullscreen.
It's not the GUI per se that people want, but it's the useful default configuration.
If I'm working on a project I want to see the file tree, I want multiple editor tabs for different files, I want to be able to full text search the project I have open, I want a terminal window to execute commands on, and most importantly I want to be able to switch between these elements without needing to learn a new set of opaque keyboard commands.
VSCode/Codium gives you this out of the box with zero friction so it's no wonder that it's consuming market share like nobody's business.
I wish it wasn't electron and I wish it wasn't Microsoft, but until there's a better alternative that's what I'm using most of the time.
I honestly don't remember the last time I used a terminal to edit files. I don't really miss vim that much since I still use vim shortcuts in VSCode. I briefly tried Emacs but a lot of the major modes for languages I used were too buggy and those were distracting me too much for it to be my daily driver (maybe I have ADHD, dunno)
For what its worth, VSCode also works over SSH. There's a collection of plugins for working remotely or in containers.
The main thing that drew me to VSCode originally was pretty good support for fonts and ligatures. And I think I also like some of the QoL plugins I use. The config is just JSON, and it's pretty easily tweakable to how I like it.
I've heard good things about nvim and zed though, and I'm tempted to try them. But there's a bunch of idiosyncrasies and quirks that you get used to, so switched kinda feels like a chore
Fair enough! Definitely not trying to make anyone change their editor of choice. But I do feel people forget (or maybe never knew) how productive terminal based workflows for editing / compiling / running tests can be once they get used to how their specific IDE exposes those features. I personally can’t think of anything I couldn’t add to terminal workflow except for things like markdown preview or image preview. There are certainly inconveniences like difficulties with copy/paste or mouse based split selection/ scrolling etc that can be worked around in more or less complete and or painful ways. But for the general tasks IDEs are used for i am not aware of anything else a gui really helps with. Hence my question.
I'm a die-hard nvim/tmux/mosh user so take this with a grain of salt, but to answer your question, many people use their IDEs as project dashboards. For example (depending on the project/ecosystem):
1. GUI editor (for UI)
2. Debugging (as in standard debugging tools like breakpoints, REPLs, etc)
3. Building the project, and build management
4. A terminal emulator
5. A container orchestrator manager (or as I like to call it, an orchestrator orchestrator)
Personally I think those tools are better separted from the IDE, but there is a real convenience in having them integrated.
Sorry, but neovim or doom Emacs or any other nerd editor configuration that doesn't have table stakes features out of the box is a complete non starter.
As far as I'm concerned, running 100,000 lines of Lua or elisp written by literallywho is no better than downloading random vscode extensions.
So what are your general thoughts on Rust? Would you use it again? How does it compare to using C or C++? Did you enjoy working in it? What was disappointing/motivating about the language?
No disrespect intended, but I find this comment pretty funny. SOAP/XML has been exactly this for 20 years. It definitely has some major warts, but gRPC isn’t doing anything new.
And CORBA/IDL was doing exactly the same 20 years prior to that.
We get tired of things because they accumulate cruft, or are deemed "ugly" by younger developers. So we replace them with newer alternatives, that are more light and easy to reason about for newbies entering the profession. But then we eventually find that we needed more features after all, so we gradually re-implement them again until the cycle repeats. The industry wheel just keeps on spinning...
I think this is a bit of an oversimplification. The modern approach to RPC is very different than CORBA or even SOAP/XML.
CORBA was designed around the idea of distributed objects. The core idea was that you have a reference to an object but you don't know (or care) if the object lives in your address space or on a remote computer somewhere. When you make a "remote procedure call", CORBA tries to make it behave as if it were just a regular function call. The call would block the thread until it completed, and any communication errors would be marshaled into some kind of language exception.
It turns out that RPCs are different from regular function calls in a lot of ways. Trying to make them the same just makes things overall more complicated and less flexible. Also, making "remote objects" stateful creates a lot of problems for little benefit.
So XML/SOAP did away with these ideas. Instead of being designed around remote object references, it was designed around request/reply to a network endpoint. No statefulness was designed into the protocol, though of course it could be layered on top by enclosing your own data identifiers.
But SOAP was based around XML, which was never really designed to be a object serialization format. Compared to alternatives like Protocol Buffers, XML is big, slow, and not a clean mapping to the kinds of data structures you use in programming languages. Protocol Buffers are a much better match to this problem. (More at: https://developers.google.com/protocol-buffers/docs/overview...)
My point is that these new technologies aren't just repeats, there are real improvements that justify inventing something new.
well I would guess the difference between soap and grpc is that soap was developed as a standard, while gRPC became one (or is becoming one).
Also the biggest difference is, that soap had like a trillion implementations which all worked kinda differently. code generation, etc..
GRPC somewhat does not have this problem because basically there is only one client implementation managed by google (now the cnf).
also in soap you basically built your server first, because writing a wsdl from scratch is like... akward. the idl of grpc is extremly simple to actually start without any implementation at all. and as a bonus it works way better if you need to add/change fields.
> But then we eventually find that we needed more features after all, so we gradually re-implement them again until the cycle repeats.
If the protocols and standards were designed lock-step with concrete implementation, I'd agree with you.
But too much of SOAP, CORBA, yada-yada was designed _before_ any implementation occurred. So they are nasty and cruft-filled long before even version 1.0.
Protocol Buffers ain't perfect, but they've been vastly deployed and hugely battle tested, so their ratio of cruft/useful remains tolerably low.
SOAP was overdesigned and yet somehow still underspecified at the same time. You could implement two different implementations that both followed the specs religiously that could not interop at all.
It's hard to overstate how crappy working with SOAP really was. I think as the industry matures we really will see serialization formats and protocols stabilize, I think we've already seen a bit of it with JSON.
I actually think that the design of gRPC must have been a great deal of effort. The project proposes an scalable solution with simple enough interfaces that smaller teams have been able to adopt quickly. I admire that very much!
No love for Open Network Computing (ONC) Remote Procedure Call (RPC)/xdr? (the rpc in rpcd for nfs).
In all seriousness grpc and protobuf isn't bad. Not sure if I'm sold on the http2 transport - but at least it has somewhat reasonable support for crypto.
I was bummed waiting for for the actual rpc-part to become usable - and now I think I'd rather build on capt'n'proto. But really, if we can just get some standardization that's better than json/soap, I'm willing to have another look.
If I never have to base64-encode an image or other binary to fit it into an api request, it'll be too soon. Or invalid deserislization error.
gRPC has significant technical advantages to SOAP/XML.
- The gRPC protocol is built on top of http2 - a protocol designed to overcome many of the shortcomings in http, primarily performance.
- protobuf is a much simpler serialization format that achieves far better performance than XML
- gRPC allows message streaming in both directions. For some use cases this is vital for achieving performance.
- there's a growing ecosystem to make it easier to work with large distributed systems. I could list a bunch, but I will just point to one: gRPC has many options for the load balancing of requests: https://grpc.io/blog/loadbalancing.
gRPC is clearly the better solution if you intend to build a large, multi-service, distributed system or want to build cloud APIs for mobile devices. And it's not just because developers hate XML.
- It was more common than not that these earlier rpc libs had no async support. And because language support for futures wasn't that hot back then, a ton of apps would come to a network tx and essentially hang until something happened. grpc doesn't have this problem.
- No major rpc impl (eg. corba, soap, rmi, etc) had versioning / backwards compatibility support, until grpc.
REST & the web won because the most up to date client is distributed to the user at each usage, which solved the versioning issue a different way. Imo, if grpcs works in the browser (see my later comment), then it's essentially better at everything.
i don't think the grpc team pretends it's "new", and some presentations even mention (with humor) stuff like soap and corba (particularly the ones by ray tsang).
The designers did well in picking datatypes, though they erred in not including a null value it's a real pain in the ass going to json and losing binaries and datetimes.
The library ecosystem is more mixed though. Python's support is great, Ruby's is serviceable, because it's schema-less Java is very verbose and not very fun, and PHP's stdlib support is just horrendous (though ripcord is good).
Seems like a bad comparison. On the one hand you are apparently willing to overlook a 100x performance penalty associated with XML compared to protobuf. And then you apparently assign no value to the safety of a strongly-typed representation in C++ vs Doc*-you-figure-out-what-this-means.
This is true for languages that try to be all things to all people (a la Java). All languages are DSLs, and if you target just a few specific domains and beat back the masses who want the language to expand beyond its intended purpose, than simplicity remains possible.
>No one would argue that SQL is bad because some implementations are Turing-complete
They do actually. Though when people do say that it tends to be phrased "keeping business logic in stored procedures is a bad idea".
People argue that all the damn time.
Accidental turing completeness usually signals a design flaw somewhere (would you also consider it too controversial to argue that C++ templates mentioned in your link are nasty and people complain about them a lot?).
reply