Post:
If youâre still shipping loadâbearing code in C, C++, Python, or vanilla JavaScript in 2025, youâre gambling with house money and calling it âexperience.â
As systems scale, untyped or footâgunâheavy languages donât just get harder to work withâthey hit a complexity cliff. Every new feature is another chance for a runtime type error or a memory bug to land in prod. Now layer LLMâgenerated glue code on top of that. More code, more surface area, less anyone truly understands. In that world, âweâll catch it in testsâ is wishful thinking, not a strategy.
We donât live in 1998 anymore. We have languages that:
- Make whole classes of bugs unrepresentable (Rust, TypeScript)
- Give you memory safety and concurrency sanity by default (Rust, Go)
- Provide static structure that both humans and LLMs can lean on as guardrails, not red tape
At this point, choosing C/C++ for safetyâcritical paths, or dynamic languages for the core of a large system, isnât just âold school.â Itâs negligence with better marketing.
Use Rust, Go, or TypeScript for anything that actually matters. Use Python/JS at the edges, for scripts and prototypes.
For production, loadâbearing paths in 2025 and beyond, anything else is you saying, out loud:
âIâm okay with avoidable runtime failures and undefined behavior in my critical systems.â
Are you?
Comment:
Nonsense. If your code has reached the point of unmaintainable complexity, then blame the author, not the language.
TypeScript and safety-critical paths should not be in one sentence.
wut ?
Why ?
Genuinely curious to learn from your arguments
Itâs Javascript with types. You are still using one hundred NPM packages to do the simplest thing. Any string can be JSON. And Node is single-threaded, so if you plan to create some kind of parallel computation, youâd need to run 16 Docker containers of your Node server, one per CPU core, with NGINX or some other load balancer at the business end, and hope that your database engine wonât reorder transactions. And yeah, Docker is mandatory, because Node version in your latest Ubuntu release is already outdated.
Iâm not even going to bother commenting on that train wreck of a post, but I just wanted to mention that I hate the writing style of programming-related LinkedIn posts. Theyâre just chock-full of sweeping generalizations presented as absolute truth in an extremely patronizing tone.
Why canât people just say, âIn my opinion, X technology is a better fit for Y situation for Z reason,â instead of âEvery time you encounter X, you must do Y, otherwise youâre dead wrong.â
Itâs just simultaneously so arrogant and also aggressively ignorant. If someone spoke to me like that in real life, I would never want to speak with them again. And these people are broadcasting this shit to their entire professional network.
Yeah, particularly the broadcasting really irks me.
That is an opinion you can hold for yourself and then make compromises as you encounter reality. I do expect programmers to hold strong opinions.But when you broadcast it, you strip yourself of the option to make compromises. Youâre just saying something which is going to be wrong in one way or another in most situations. I do expect programmers to be smarter than that.
Just donât do bugs. How hard is that?
According to all teams Iâve worked on.
Pretty fucking hard.
I know this is satire, But really though better languages that make various classes of defects unrepresentable reduce defects. Itâs wild that such a statement needs to be made, but our industry is filled with folks who donât critically think about decisions like these.
Like the age old advice for getting better at Smash Brothers - Donât get hit.
My second favorite prompt, behind âDo not hallucinateâ
If I donât have documentation or defined features, then I canât do bugs!
The evolution strategy: if you donât know what youâre doing, every function is a feature!
As an embedded dev, good luck not using C
Not an embedded dev. Whatâs the Rust situation in the embedded world? Is it ever used?
In my corner of the embedded world, it feels like everyone is practically jumping to integrate Rust. In the sense that vendors which havenât had to innovate for 10+ years will suddenly publish a Rust API out of the blue. And Iâm saying âout of the blueâ, but I do also regularly hear from other devs, that theyâve been pestering the vendors to provide a Rust API or even started writing own wrappers for their C APIs.
And while itâs certainly a factor that Rust is good, in my experience they generally just want to get away from C. Even our management is well aware that C is a liability.
I guess, I should add that while I say âjumpingâ, this is the embedded world where everything moves extremely slowly, so weâre talking about a multi-year jump. In our field, you need to get certifications for your toolchain and code quality, for example, so lots of work is necessary to formalize all of that.
Iâve been an embedded developer for coming up on 20 years at this point, and recently went through a job hunt. Of the three that made it to the offer stage, two used Rust almost exclusively in their embedded stack and one used Rust in their embedded LInux stack and was trying to decide if they were going to use rust in their bare-metal/RTOS stack. I ended up at on of the Rust places, though I had no Rust experience. I have to say, while I do find many parts of the syntax too cute by half, in general Iâm pretty happy with it as an embedded language. My current target architectures are ARM Cortex-M7 and Cortex-A53. In general toolchain, and debugger support has been good, peripheral support has been ok but could use improvement.
Itâs not widely used. Some car manufacturers(Toyota if I remember correctly) have started testing it. Some parts are really nice.
There is exactly one hal for i2c, spi and Io pins. As long as both your chip and peripheral driver implement against it, it just works. There are more unified abstractions in the work for things like DMA, but they are not officially stable yet.
Cooperative Multi threading can easily be integrated thanks to Async rust and executors like embassy.
All the crates that are no_std compatible can be included.
Itâs not perfect, but itâs getting there.
Bindings have been getting added to the Linux kernel so drivers can theoretically be written in Rust
Android has moved its IPC mechanism, Binder, over to Rust
Rust is more of a C++ replacement, no? Rather go with Odin or Zig or C3 for systemic stuff?
Rust is more of a C++ replacement, no?
Itâs fast and memory secure, so itâs good for stuff you might do in C but you donât want to risk a memory leak or segmentation fault.
I thought more in the way of atomic dependencies and how it handles features in-language vs. in-code and reliance on toolchain vs. standalone. In short, how you as a programmer are supposed to use it.
Not really. The things where C++ used to shine are usually best done in higher level languages.
Rust is a great C replacement.
You often just want to go with whatâs popular, since hardware vendors will only provide APIs for select languages.
Well, and depending on the field, you may need to get certifications for your toolchain and such, so then you have to use whatâs popular.
I know that some people have managed to get it working but I have yet to see it in practice. Granted, my experience in the industries is currently only what I learned during my studies and 2 internships.
In general, C is supported. C++ is sometimes supported and very few people even talk about Rust.
You could use Forth.
Go, Forth, andâŠ
âBlame the author, not the languageâ
Says the person who screams they have never worked professionally with a team before.
There is no excuse to not use statically typed, safe languages nowadays. There are languages that let you build faster like Python and Typescript, but faster does not mean safer. Even if your code is flawless it still isnât safe because all it takes is a single flawed line of code. The more bug vectors you remove the better the language is.
Even if your code is flawless it still isnât safe because all it takes is a single flawed line of code.
If there is a single flawed line of code, the code isnât flawless.
Even if the code is flawless now, all it takes is a single flawed line of new code. This is of course true for all languages, but type safety helps a lot as some types of flaws would not compile.
I am not arguing against type safety, just pointing out the glaring contradiction in defense of it.
let you build faster like Python
I have to write so much boilerplate code to make sure my objects are of the correct type and have the required attributes! Every time I write an extension for Blender that uses context access, I have to make sure that the context is correct, that the context has the proper accessor attributes (which may not be present in some contexts), that the active datablock is not None, that the active datablockâs data type (with respect to Blender, not Python) is correct, that the active datablockâs data is not None⊠either all that or let the exception fall through the stack and catch it at the last moment with a bare
exceptand a generic error message.I used to think that static typing was an obstacle. Now Iâm burning in the
isinstance/hasattr/getattr/setattrhell.I loved python when I was a junior dev. Now I hate it (except for things like computational math). I have to add debug statements to figure out that someone snuck in the wrong type into the code.
Type checkers are your friend if you can enforce them. Iâve started using them in my new projects and find that they make those types of bugs harder to sneak in, especially if youâre strict about requiring type hints/definitions in your functions and classes.
I like
ty, but itâs immature. Check out Pyright as well.
I have to write so much boilerplate code to make sure my objects are of the correct type and have the required attributes!
That is the trap that, sadly, my company fell for too. The POC was written in python. very fast i might add. but it was only that: a POC. if the whole backend crashes due to unexpected user input - noone cared. if the frontend displayed gibberish because the JSON made wrong assumptions about not defined data types - sweep it under the rug, donât do that during presentations.
but if it came to building a resilient system, which can be shipped to customers and preferably maintained by them (with minimal consulting contract for access to our guys)⊠we cursed the way python worked.
There are definitely use cases where something like C is still the best option because itâs faster. For the most part consumer software itâs unnecessary, but itâs not obsolete for all applications.
Hell, assembly code is still necessary for the lowest-level init code. Once you have a functional stack and some var init logic you can graduate to C.
Thatâs ridiculous. Everyone knows its best to write modern bootloaders in Matlab.
You joke, but my first âlets make facebook, butâŠâ comment was from an electrical engineer buddy that wanted to use matlab. That was the whole pitch. âFacebook, but matlab.â
It did not go far.
Real men use Scratch for everything.
There have been multiple operating systems written in Haskell
I believe you and Iâm sure they were fine.
I wrote an XML parser in LabVIEW once. Just because you can doesnât mean itâs the right thing to do lol.
A little hair-splicy, but an assembly-free bootloader is definitely doable on some platforms â Cortex-M processors load the stack pointer from the vector table, and the initialized memory setup can be taken care of with memcpy.
True, but youâre not gonna be setting the access levels or doing anything else with control registers on a Correx-M in pure C, let alone boot to a safe state with zeroed registers.
Yeah, if your bootloader is expected to handle that youâre going to need assembly. That can also be delegated to the kernel, RTOS, or bare metal reset vector later on in the boot sequence, though. I had to write a bootloader for an embedded system like this once and it basically just applied firmware updates, validated the firmware, and handed control over to the firmware.
Youâre just describing more components that are written in C and assembly.
My point is that assembly isnât strictly required. You can do memory-mapped reads and writes from C all you want, which is enough for plenty of I/O: storage, serial, sensors, GPIOs⊠You can build quite a few things with these without touching system registers.
Iâm not saying we should abolish assembly. Just that it isnât a universal requirement.
In my 15+ years of experience many of the actual field problems are not language / programming related at all. Unclear requirements or clear but stupid requirements cause loads of issues. These are often caused by communication problems between people and / or organizational issues.
It depends a lot on the industry of course. For embedded software, low level networking etc I mostly agree with you. However, in business applications or desktop applications itâs from my experience mostly bad requirements / communication.
Donât forget to add incompetent leadership to that list. If feature needs to be shipped by some arbitrary deadline and the engineers are forced to rush through the design process, you end up with a patchwork hack of tech debt that leads to more tech debt.
So there is apparently a problem with languages such as JavaScript and the solution is to use languages such as TypeScript.
Wut?
Well, yes. TypeScript mitigates one big problem with JavaScript (type safety). Thatâs why it exists. Itâs a dumb idea to choose vanilla JS over TS if youâre starting a new project today, IMO.
Whether or not you should use TS as your core language is debatable and situational, but in terms of using TS instead of JS, yeah, thatâs a no brainer.
Some people disagree with it being a no brainer.
Thatâs only article-worthy because it is a rare occurrence and an increasingly controversial opinion. And even that maintainer didnât abandon TS completelyâhe said that would be âdaftââhe just moved to types via JSDoc which is run through the TS compiler, as well as to
.d.tsfiles.he just moved to types via JSDoc which is run through the TS compiler, as well as toÂ
.d.ts files.Congratulations, you read the headline.
But âjustâ is doing a lot of heavy lifting here. It is literally why he moved.
Congratulations, you read the headline.
Learn how to have a conversation
You didnât even bother to argue my point. You repeated the headline of the article that I send you. Are you sure that I need to learn that?
I would have given you a proper response if your response would have been. Calling something âcontroversialâ is literally saying that there are conflicting opinions on the matter, which means it is NOT no brainer.
Your point was âsome people donât think itâs a no-brainer,â which I addressed, and then you whipped out that line. Iâve been around long enough to know what that means: that your replies would be inflammatory garbage from then on. Learn how to interact with people online in a civil way and maybe youâll actually be able to maintain a conversation long enough for it to be constructive
Python isnât âuntyped;â it is, in fact, strongly-typed. (And is markedly different than and superior to JavaScript on that point.)
This rant feels like it was written by an OO programmer who was never able to wrap his head around functional programming.
Yeah, plus it has type hints and tooling to make said type hints mandatory.
Also, like, fuck golang, itâs such a shit language and the compiler does very little to protect you. Iâd say that mypy does a better job of giving you AOT protection.
Also, like, fuck golang, itâs such a shit language and the compiler does very little to protect you
I never understood why people like it. Itâs a ânewâ language, and it still doesnât seem to get the basics right. No proper null handling, and donât get me started on
interface{}. Itâs like they set out to build a better alternative to C++ while ignoring the other developments outside C/C++ for the past 15 years. The compiler is damn quick, though.Iâve dumped 18 years of C++ experience for Go in 2018, and never wanted to come back. Took me a couple of months to become accustomed.
The main Goâs feature is a green light for ignoring OOP baggage collected for decades, which makes writing code unnecessary burden. And Go have tools for not doing that.
Yes, sometimes it can be a bit ugly, but if youâre ready to trade academic impeccability for ease of use, itâs a real blast.
Iâve seen a lot of bad code in Go, which tried to do OOP things taught in school or books. Just donât. Go requires a different approach, different mindset. Then everything falls in their places.
deleted by creator
Why are you talking about functional programming? Python sure as hell isnât FP.
Do you mean python has something to do with functional programming, or did I misread? Because I would say e.g. Typescript is (slightly) closer to FP than Python.
Yes. Python is a multi-paradigm language, but IMO proper âpythonicâ python looks a lot more functional than OO, with liberal use of duck-typed list comprehensions and such.
You might be confusing using functions with functional programming. Python is Object Oriented language at itâs core, most people use it as
procedural, and like most modern languages it supports also functional paradigms.Itâs also dynamically typed and inferior to TypeScript.
Depends enirely on the usecase. Python is loved for data processing but python GUIs get messy. And so do JS and TS GUIs.
Iâve never met a desktop GUI bigger than a single page with buttons that wasnât messy and complicated.
Granted, Iâm used to Qt in C++ and python, so I donât think Iâm the best sample collector.
Delphi could do complex GUIs pretty well. That makes me miss it sometimes.
Typescript fucking sucks.
Why?
donât just m-dash
chat gippity
Maybe, but always remember LLMs are trained on real people. Some people naturally use similar styles to some LLM tica as it was stolen from them in the first place.
If you see more than 3 EM dashes in a body of text, itâs 100% AI. I have found random online articles where there is at least two em dashes every paragraph. No human wrote that shit. A human is lucky to get away with one em dash (and itâs been that way before AI).
one heartbroken anti-AI human who loves em dashes replying âčïž weâre split into two classes: the type who abandons our typing habits to avoid being told our human efforts are definitely AI, and the type who stubbornly carries on using em dashes
Donât just stateâregurgitate!
itâs just negligence with better marketing
Good damn I hate that tone it reeks of LinkedIn llm-powered personal branding. Weak ideas with writing that tries to sound strong is the worst.
Weak ideas with writing that tries to sound strong.
I move to make this the new definition of âMarketingâ.
I guess I used to associate marketing speak with âletâs say something so bland nobody can really disagree with itâ but this trend of writing platitudes like they are ground breaking expert insights is really grating to me
So much. It feels like an offshoot cousin of clickbait, basically.
I agree with the post. Setting up typescript takes an hour or two if you have no clue what youâre doing. In return you get the absence of (the equivalent of) null pointer exceptions.
I chuckle every time I find an NPE in the Java backend. Doesnât happen to me. Canât happen to me.
Sidenote, while Iâm already gloating: Once the backend code had an error where they were comparing two different kinds of IDs (think, user ID and SSN), which gave wrong results. This error canât happen to me either, because I type my IDs such that they are not comparable. A strong type system really is a godsend.
Setting up typescript takes an hour or two if you have no clue what youâre doing
Modern versions of Node.js have native TypeScript support. For scripts, you can just write the script then run it. Thatâs it. No build process needed. A beginner could just rely on type checking in their editor (I think VS Code has the TypeScript tooling installed by default?)
For web apps, just use something like Bun or Deno. Bun gives you practically all the tooling youâd need (JS runtime, TypeScript, package manager, test runner, bundler, and framework for building web apps) out-of-the-box. It doesnât have a formatter, but you can just use your editorâs formatter.
NPEs are the reason why my team moved to Kotlin. Well, that and all the other myriad advantages Kotlin brings to the table.
One of the backend devs started using Kotlin. From time to time I need to read backend code, and I have to say itâs very easy to write an incomprehensible mess in Kotlin.
Kotlin isnât perfect and it gives the devs quite a lot of freedom. I would argue that if your Kotlin code is messy, thatâs on you - but it will still be significantly less prone to failures like NPEs. Unless you opt out of null safety by using the dreaded ?-Operator.
I like the âadvantageâ that using any Kotlin code in normal Java automatically forces you to use the kotlin-stdlib for Java 8 and adds a additional bloat of 10MB to your projectâŠ
Well, ideally you start new projects writing 100% Kotlin while only adding Kotlin code to older codebases you canât get rid of. Personally, I donât like mixing languages anyway and I would stay with Java in Java projects. One reason is the bloat argument you pointed out quite correctly.
Ohhhhhh noooooooooo, not my 10 mbs
10MB? Oh no! How is this going to fit on my 1TB drive?
Lombok had a bunch of great things that shouldâve been part of the java language to begin with. Theyâve slowly been folded in (so now you have to work out which @NotNull annotation you want) but the language does still improve.
True⊠but Kotlin makes Lombok quite unnecessary by having its concepts built in. Itâs also worth to point out that null safety is opt-in in Java and opt-out in Kotlin.
Thatâs a good point. You can get away with that with a new language, but adding nullability as a non-default option would break existing code much like making things const by default in C++ would, I suppose.
I really like how I can turn everything into immutable
valâs and represent different paths as expressions, it can IMO really reduce the complexity of a function and makes it easier to spot bugs. Iâve been migrating some code of a FOSS app to Kotlin and was able to shrink most classes by like 30% while making it easier to read. The only thing I dislike about it is the additional syntax for various things, I could do without having multiple ways to write a constructor.Yes, there are things about Kotlin I donât love either. But I still like how it was clearly developed having developer quality-of-life in mind.
NPEs in Java usually have 2 causes and they are easily preventable:
- Parsing or deserializing data that must be present but is not. Fix: Add a validator or (introduced in Java 17 - 4 years ago) use records and do simple null validation there
- Devs coding weird shit that might or might not return null. Fix: Use annotations like NotNull/Nullable or the Optional wrapper (introduced in Java 8 - 11 years ago). There is also progress underway to be able to explicity declare type nullness, however - as always - Oracle invests more money into itâs lawyers instead of their devs, so it will take some time until this will be available.
The problem is not really language specific because quite the same can also happen in any programming language, the symptoms/errors are just different.
Nulls are absolutely pervasive in Java and NPEs are not avoidable. At minimum, most of the ecosystem uses nulls, so most any library will have nulls as part of its interface. Null is an inhabitant of every type in Java (even
Optional, ironically). You cannot escape it. Itâs a fundamental flaw in the design of the language.Btw, you also canât escape it in Typescript, either, due to unsoundness of the type system and the fact that many types for libraries are bolted on to the original JS implementation and may possibly be inaccurate. But still, itâs a lot less likely than Java.
Recently Iâve just been getting co-pilot to do it
I have an alias that calls the copilot CLI with a prompt that says âset up typescriptâ
Fuck this
Thatâs like one of the few good uses for LLMs in development - setting up new projects, but AI haters will downvote you no matter what.
Iâve seen VSCode advertise this for setting up tests, but I havenât been trusting enough to actually try it.
Does it work consistently?
Go and Python and Typescript all have their own footguns.
I assume Rust is the same, but havenât used it personally to see
Rust is the foot gun, itâs so perfect that you genuinely cannot just sit down and type out what you need.
Skill issue
- sincerely, someone making a DST crate
EDIT: To clarifyâŠ
There are some things that are only doable on nightly Rust (like specialization, const fn in traits, etc.) and the reason for that is to avoid future issues. In that regard, Rust will not be as good as C++⊠at least until those get stabilized.
Some of the nightly functionality (like
ptr_metadata) can be achieved withunsafecode and itâs fine to do that, as long as itâs only done when necessary and itâs properly documented.Itâs okay to want to use C++, but that language has itâs own issues and footguns (virtual destructors, âmove semanticsâ, C-style casts, header files and more) that Rust wants to avoid.
EDIT 2: Specialization is also kinda doable with deref coercion, but thatâs another can of worms I donât wanna open here.
EDIT 3: And if I had to mention some of Rustâs footguns:
unwrappanics, which isnât bad in and of itself, but itâs short so youâll probably want to use it instead of other error handling methods (see recent Cloudflare outages)unsafefunctions implicitly allows usingunsafeoperations (fixable by adding#! [deny(unsafe_op_in_unsafe_fn)])
For my own Rust project I require myself to have a comment for every unwrap call that explains why that unwrap will never panic. For everything else I let the function return an error, with help of the anyhow crate and error contexts.
Nonsense. If your code has reached the point of unmaintainable complexity, then blame the author, not the language.
I feel like thereâs about one person that can cast this stone, and thatâs because preventing this has turns Torvalds into an abusive bridge troll sometimes, but heâs actually been successful.
Well, the kernel is unmaintainably complex. Linux saves his sanity by not looking deeply into modules and only inspecting the surfaces.
I donât get it.
Maybe the joke is nothing complex is written in fad languages?
Maybe the joke is the discounting of peer review and testing?
Maybe the joke is the lack of devops knowledge where Python is extra steps over other scripting languages?
It seems like promotion of fad languages. When I was younger, I chased fads and lost hard. Iâll stick with C and C++. Run-time failures happen to everyone including fad languages. Hereâs looking at you Rust CVEâs. Better to have loved and lost, something, something.
Iâm completely confused by why they seem to think itâs impossible to have coding errors in rust. Iâm also confused as to why they seem to think that errors are actually a problem. You get them you fix them. Who cares about what language you do it in.
This stinks of somebody whoâs been in the industry for about 2 years and now thinks theyâre hot shit.
If the language makes common but dofficult to deal with error impossible, thatâs nice. Not critical, but nice.
If the language introduces easy to make and hard to deal with errors, thatâs an issue. Not a deal breaker, but an issue.
The idea does exist, but itâs stated with way more confidence and finality than it deserves. Thatâs social media I guess.
I still donât accept the fundamental core point of the arguement which is that rust necessarily makes it impossible to commit certain errors. Rust has its rules as such as only programming language does but that doesnât mean that mistakes are impossible.
The vast majority of errors are logic errors not memory leaks in standard functions.
Memory leaks are often difficult to deal with, and many contemporary languages basically encourage them. I know many applications that suffer significant performance issues due to memory leaks, and way too many that simply donât care about memory footprint.
A language that treats memory management differently from the start makes all these problems much easier to deal with, if they appear at all. The real question is if the other costs of using the language are worth the somewhat niche performance gains.
Plenty of complex things have been written in fad languages. And not only complex things, COBOL was one of the biggest fad languages of all time.
deleted by creator
Sounds like they want Ada Spark and not Rust.
i laughed pretty hard thinking isnât that just ada
so we got rid of ada for c++ now from c++ to rust chasing ada lmao
Sparkâs syntax reminds me of submitting an application to a bank before I had a permanent address.
Yes it looks like Iâm checking all the boxes, but I have to fudge some requirements just to get the process running, and remind myself to update the details later
Dunno, I picked python as my language for personal projects because it has type hinting now and jobs I was looking at wanted it. Iâd like to use C# but I need to find a good IDE on Linux.
Iâve gotten pretty good at C because itâs what my company uses but god damn I am tired of fixing memory errors from bad programming. Nobody uses best practices and itâs horrid. Best practices came about to avoid issues. Use them. Please. I donât want to be the guy to answer âplease fix my memory issuesâ tasks. If you donât know what youâre doing, please choose a different god damn language.
Iâve only gotten this way because Iâve tried to read the fucking manual. Stop telling me Iâm wrong when you donât know how it works. Stop telling me Iâm wrong when you donât check for errors. Iâm telling you this not because I want to talk. Iâm telling you because I learned the hard way fixing your code and I donât want to do it anymore.
I just use VS code with c# extensions on Linux. It works fine. I also use vim with lsp support for C# sometimes.
If you want more, you may also want to check out Rider from Jetbrains.
Rider here for serious work. Itâs also free for non commercial use if that works for you.
Thank you for the recommendation. I would consider it again if my day job switched to Linux (unlikely).
I did try Rider on Linux a while back, but just couldnât get my head around it. Iâve become too used to Visual Studio on Windows (with Resharper).
I donât do a lot of C# outside of my day job, though, so VS code is fine for my uses.
Yep, I feel you, itâs quite a bit different philosophy compared to VS. However, if you use other Jetbrains products, it helps that they share a lot of features so you eventually grasp the different approach. And sure, if VS Code is good enough for you, great.
I canât use codium because on sway the file open dialog doesnât work and I havenât figured out why
Unfortunately I canât help you there. I just use plain old kde plasma on Fedora. If your favorite code editor supports Language Server Protocol (LSP), you can probably get it to do code completion for C# one way or another. Vim, neovim, Kate, and many others do.
Just in case you have this problem with other software: itâs probably an XDG desktop portal issue, I havenât used Sway specifically for a while but it took me a lot of trial and error to wrangle my portals into submission without using Plasma.
I tried to set it up, and installed dolphin as well but I could never get it to work. Must have something configured wrong in my end but could never figure out what
o7
I did random bullshit written on the Internet for DAYS to get my browser to use a decent file chooser, itâs harder than it has any right to be
I believe zed has extensions for c#, and I guess more importantly, dotnet.
At this point, unless you have the money to grab sublime (or specifically want foss or even just free as in beer), and you arenât sold on the way of life of the old guard like the modern vims or emacs, zed is pretty much the best there is.
I used to be such a jetbrains guy, but that was back when they did actually have something nobody else really offered outside of Microsoft. Before that, for a good long time, I was an emacs guy, until I had to use a windows computer for work and emacs just doesnât fit well there, couldnât get a good equivalent of the daemon going consistently, had to switch. And to be frank, lisp is the fucking worst.
Nowadays, there are so many options though, even, or especially, on foss side. Or even just free. Hard to justify the jetbrains kinds of specialized tools, now that the same sugary, smooth experience is almost exactly achievable on those. And faster.
I have been happy with zed for quite a while now. Apart from the (disableable, thank god) first class AI stuff, I havenât a single complaint. It feels as fast and responsive as sublime, and while the ecosystem isnât there yet, I can get all my stacks and tooling to run currently like it was a jetbrains ide from back in the day. Rust, dotnet, deno/ts, it all just works after setup.
I would still go for sublime just for the ecosystem, but I havenât the economics at a point where I can choose convenience for a price, if a close equivalent exists with the price of nothing but contributions occasionally. The zed source being open, even if my PRs donât get merged, I can just live with my fork and have it natively the way I want, without working around the extension limitations.
Iâm confused. I looked at zed and itâs Apache 2.0. Isnât that open source? I do specifically want FOSS
Sorry, I go on tangents and end up just confusing people. It is! That was my point, though failed to deliver it. Gpl3, agpl and apache.
They do have a pricing model for enterprises with some proprietary extra stuff on top (shared billing, SSO, premium support and stuff like that), and a tier for expanded AI stuff (entirely ignorable, and the editor works with pretty much everything, so if you need those things, you can just set up whichever service you want yourself), but those can both be ignored, the main editor is FOSS and committed to remain so.
