Yeah, Xcode's Metal debugger is fantastic, and Metal itself is imo a really nice API :].
For whatever reason it clicked much better for me compared to OpenGL.
Have you tried RenderDoc for the OpenGL side? Afaik that's the equivalent of Xcode's debugger for Vulkan/OpenGL.
I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with).
It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.
Funny. I've been trying rust for the past 2 months fulltime, and i'm really wondering how you can call it a "joy to work with" when compared to java, at least for server development.
Rust feels like walking on a minefield, praying to never meet any lifetime problem that's going to ruin your afternoon productivity ( recently lost an afternoon on something that could very well be a known compiler bug, but on a method with such a horrible signature that i never can be sure. in the end i recoded the thing with macros instead).
The feeling of typesafety is satisfying , i agree. But calling the overall experience a "joy" ?
I'm not discounting your experience, or saying you're wrong or anything like that. I've been writing Rust for a while, and for me, that feeling went away. Lifetime/ownership problems used to run me over but it almost never happens anymore. I think Rust has a rather severe "hump" that a lot of people run headlong into, but it does get better, I promise you. You start thinking in ownership/borrowing terms and it just fades into the background at some point. Rust is easily my most productive language now. Again, not discounting your experience at all, it can be rough starting out.
i do feel much more comfortable with lifetimes than at the beginning. I get the general concept, and i barely have to explicitely set them (i did start by religiously reading the rust book, of course).
However, at the moment i still feel i'm using a huge amount of layers upon layer of complex type definitions in order to get anything done. Just using an object's reference across async calls in a safe manner leads to insane types and type constraints, which read like ancient egyptian scripture. And at every layer, i feel like changing anything could blow everything up with lifetimes.
The language has this very special feel of something both advanced and extremely raw and low-level at the same time. It's very unique.
In my experience, beginners often make the mistake of assuming just because you can do things with references and lifetimes that you should. Unless you’ve done profiling, just start with the easy thing and clone an `Arc` (or whatever other data structure helps you avoid lifetime problems)!
Also, it’s worth saying, you probably don’t need async.
oh, believe me, cloning and Arc-ing is something i realized very early that i was going to use. But that's the point: you still end up with things like : Arc<tokio::RwLock<dyn MyTrait>> for every single dependency.
Then you want to declare an async function that takes an async closure over that dependency. And you end up with a total garbage of a method signature.
As for async, the ecosystem for server-side is totally filled with async everywhere now. I don't think it's realistic to hope escaping those issues anyway in any real-world project. i thought i might as well learn to get comfortable with async.
Not all lifetime problems are just a matter of learning. I've been picking up Rust every few years to catch up, and every single time I've eventually expressed a lifetime that either required unstable Rust at the time or hit a known lifetime bug.
You eventually learn you leverage lifetimes. You just need to get over that point in the learning curve. I very rarely run into those types of issues, and it's very freeing knowing that I can write libraries that are so hard to misuse because you can leverage the type system.
You need lifetimes in order to make the affine types ergonomic to use through borrowings and aliasing mechanics. You want the affine types to prove all kinds of things about resource management, beyond just freeing allocations, which we generally call RAII. You model file and network handles as RAII, mutex locks as RAII.
Other languages use constructs like context managers or try-with-resources to capture this, but these constructs are very limited and make it very hard or impossible for these resource types to be put into a container and passed between threads. In Rust this is trivial and actually just works.
Garbage collectors usually give much weaker guarantees about when objects are freed, so destructors (which are sometimes not even available, like in JS) might only be called much later. You can't rely on a GC to unlock a muted for you. But in Rust it happens when the guard is dropped, always, immediately after it's last needed.
Since you're mentionning it : i was surprised to find no golang "context" equivalent in rust's axum. How do you manage cancelling a long-running operation triggered inside an http request handler when the connection closes ? is it via RAII ?
Yeah due to the design rule that "futures do nothing unless polled", it's enough to simply drop them and it cancels the whole tree of work. That doesn't necessarily cancel other tasks that were spawned that the future might have been waiting on. That's really easy to build if it's needed, since we do have RAII. This is part of why Rust's futures compose really well in ways that goroutines just do not and JS promises struggle with.
> Why do I need to? Why can't I let the garbage collector deal with it?
Determinism.
With Rust lifetimes, you can statically prove when resources will be released. Garbage collectors provide no such guarantees. It has been shown that garbage-collected languages have a space-performance tradeoff: you need five times as much RAM to achieve the same performance, even with a "good" GC, as the same program with explicit memory management:
i indeed got the feeling that rust style favors macros over complex function signatures.
I'm still unsure if it's a good thing in general, because as a general rule meta programming is always harder to debug. But for simple macros it seems like a nice trick.
I am keeping up, but honestly i feel like rust dev is a bit like a trap : people like us love challenges and solving technical problems. So whenever we "triumph" over a rust tricky compilation issue, we feel intense gratification in solving it.
However, at some point you have to ask yourself why you're accepting to face all those challenges. Is it worth it ? When was the last time i faced a race condition when developping a backend ?
The reason i started with rust was for a very specific need on building a cross-platform library (including wasm), and that was a good justification, and i'm happy that i did. However now that i'm using it for the server as well and face the same kind of challenges, i seriously question whether this is a wise choice.
> I've been trying rust for the past 2 months fulltime,
> recently lost an afternoon on something that could very well be a known compiler bug
With respect, at two months, you're still in the throes of the learning curve, and it seems highly unlikely you've found a compiler bug. Most folks (myself included) struggled for a few months before we hit the 'joyful' part of Rust.
Rust is genuinely novel, so for most of us its going to be less familiar, so it will take longer to learn. It's not like learning Python if you already know Ruby, for example. The upside is that it offers some pretty great guarantees you can't (yet) find elsewhere. If you want those guarantees it will be worth it, if those guarantees don't matter to you, it may feel like a slog.
The banner one is memory safety without garbage collection. This enables is a terrific degree of library composition. Unlike C/C++, you can generally expect that libraries you pull in will also be memory safe.
The other one is thread safety, due to the compiler-enforced ownership semantics that prevent threads from accessing shared data unless they do so in a well-defined way.
I hope the same, and TBH it's the only reason i'm keeping up developing that backend in rust. I hope that in the end, it's going to improve my style.
Go felt the same way (but with a much lower order of magnitude) : you feel like bumping into language limitations, but once you learn to do it "simply" in go, your style will have changed into something much more elegant.
As for the bug in question, it has been quite "popular" for about 5 years now, and is actively tracked : https://github.com/rust-lang/rust/issues/110338. Nothing really weird. Just async hitting the limits of the current rust design.
Simply using axum with code using multiple layers of async was enough.
But then again, it looked like this bug (the error message is the same), however at this point i'm really unsure if it's exactly the same. The error message and the method signature was so atrocious that i just gave up and found a simpler design using macros that dodged the bullet.
Personally I think C# is miles ahead of Java and in meaningful ways (like a drastically better implementation of generics, not to mention value types have existed for eons at this point and an FFI system that doesn't hate you for using it)
But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
Problem with C# isn't the language, it's the enterprise ecosystem. You always feel like you're going to have to pay at some point down the road for using the tech.
Every large company I’ve ever worked at had a strict “no Microsoft on the server” policy and for better or worse, C# is closely identified with Microsoft.
The poster was talking about the ecosystem not the core platform. The wider Java ecosystem was heavily dominated by many Apache (and other) open source libraries vs commercial products for the C# ecosystem.
You can easily just not use the Oracle JDK, though, unless you're running commercial software which requires running on the Oracle runtime to get technical support.
As others have said, the problem is not the runtime, but libraries: many major .NET libraries have been going fully commercial, you can't really trust the ecosystem anymore.
Java has a strong history of OpenSource, and a great set of libraries. It also pioneered the managed dependency system early (Maven), so these libraries have been centrally available for two decades.
Moreover, a lot of these libraries are well-supported to this day. For example, Hibernate (the best ORM in business) is 28 years old, and has just released a new version. I recently consulted my former client (from 15 years ago), and I still recognized most parts of the stack that I set up way back then.
That's because the Microsoft of 2000 - 2014, the Ballmer era, was Microsoft-first. It didn't care about other platforms, it didn't care about the web, and it didn't care about open source. C# could be great, but it existed in a bubble.
Java kept growing and wound up everywhere. It played nice with Linux. Enterprise Mac developers didn't have trouble writing it with IntelliJ. It spread faster because it was open.
Satya Nadella fixed a lot of Microsoft's ills, but it was too late for C# to rise to prominence. It's now the Github / TypeScript / AI era, and Satya is killing it.
The one good thing to say about Ballmer is that he kicked off Azure. Microsoft grew from strength to strength after that.
VSCode itself, for all the promotional materials about how it's open source, is officially "a distribution of the Code - OSS repository with Microsoft-specific customizations released under a traditional Microsoft product license".
But wait, you might say, it's just like Chrome vs Chromium - so long as we have the OSS edition, it's all good! But, unless you're writing JS or TS, you need extensions to do anything useful. Python is an extension. So is C#, and C++. And all of these are partially closed source - e.g. code completion for all three, or debugging for both C# and C++.
Worse yet, the licenses for those closed source parts specifically prohibit their installation and use in anything other than the official closed source VSCode distro. And this isn't just verbiage - there are actual runtime checks in all these products that block attempts to use them in VSCodium, Cursor etc.
The same goes for the official VSCode extension gallery / marketplace - you can't legally use it from anything other than the official VSCode. Enforcing that is trickier, but even here Microsoft managed to find a way to frustrate its users: it used to be possible to download a .vsix from the Marketplace, but that feature has been removed recently, precisely because people were using that in conjunction with Cursor etc.
Maybe you don't think of it like that, but please remember that, especially with some decisions made in the past months, more and more people are turning away from everything Microsoft.
> But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
There was this guy Miguel de Icaza. From when I followed the open source ecosystem at the time, it seemed to be his personal mission to promote independent clones of a bunch of Microsoft technologies like C# on his own time even though they didn't ask him to do it.
I don't think I ever understood why someone would do this. It's like in the 2000s where people seemed to think you could solve all technical problems by inventing new kinds of XML.
The founding document of GNOME was written by de Icaza. It was called "Let's Make Unix Not Suck", and his proposal for not sucking was basically to import much of the design of Windows and specifically COM into Linux as open source.
Depends where you work. I've seen a lot of Java and .NET jobs around where I am. Having both jobs I find it easier to get performant code in .NET than Java (reified generics, value types, more primitives/less boxing in general, and other constructs not found in Java)
Definitely not. All the stuff I was used to get for free and advice I that was one google search away ... just dont exist in dotnet. Or is expensive. But most of the time, there is weaker library not doing nearly enough and that is all that exists.
It barely works on non MS platforms,has had many slightly incompatible versions so it's a non starter for many projects where I run into that might benefit from c#. I spoke to a manager recently who had invested in silverlight in the past. Based on that alone it was a no MS policy for his development teams.
Quite a few languages "loved" by "Linux communities" tend to have rather rudimentary integration with Linux kernel's facilities or worse packaging story.
For example, Go does not understand cgroups limits and needs an external package to solve this. .NET can read and accommodate those natively. It also ships with excellent epoll-based socket engine implementation. It's on par with Go (although I'm not sure which one is better, but .NET performs really well on high-throughput workloads).
Its actually quietly very popular in very boring contexts outside of Silicon Valley. Its also slowly entering new areas now that Linux builds are rock solid.
C# had the chance to learn from Java. Java was a bit rushed. Gosling said he was not given enough time to add closures. Even without generics, Java would have been quite elegant and much less verbose. The alternative, anonymous inner classes, were quite clunky.
Nevertheless, as a platform, the JVM and JDK were fantastic and miles ahead most alternatives during the late 1990s and 2000s. The only platform for large development that offered some compelling advantages was Erlang, with BEAM and OTP.
Java could have easily caught up with C# in the early 2000s. In 2001 Pizza (Scala's ancestor) showcased generics, higher-order functions, ADTs and pattern matching. Interestingly enough only generics made it to Java in a reasonable timeframe, the rest came only much later.
Aside from early versions being rushed, I feel that Java's success and adoption were the bigger issue. While Microsoft could iterate quickly and break backwards compatibility with major versions of C# and the .NET runtime, Java was deliberately moving at a much slower pace.
In fact, Java 1.5 got generics in 2004, one year before C# 2.0 added them in 2005. OTOH C# 2.0 had anonymous delegates, although syntactically they were still very verbose (no type inference for arguments) and thus only marginally better than Java's anonymous classes.
It was really from 2007 on (.NET 3.5 / C# 3.0) that C# started to get major features at an ever increasing pace while Java significantly stagnated for quite a long time.
C#'s runtime got generics in 2005 whereas Java still just has compiler-only sugar. It's a rather significant difference in the quality of the implementation. Not just for things like reflection but also means List<T> ToArray actually can return T[] instead of Object[].
Thanks, my recollection of C# evolution was blurry, I stand corrected.
So really, Sun and Oracle could have definitely moved faster around Java 6 and 7, the Java 8 release took a long time given the feature set.
I feel that records could have come quicker, their implementation isn't exactly ground breaking. Avoiding the async/await route was a smart call though, and Loom could probably not have happened much earlier.
They intentionally chose to not have checked exceptions though, and people have different opinions on it. They believed that people would just catch Exception most of the time anyway instead of selecting on a very specific type (which is often how it works, in web apps anyway.)
Java streams and a lot of other APIs are extremely ugly because of checked exceptions. Conversely, LINQ and delegates and a lot of other syntax is far cleaner in C#.
Your linked blog is pretty wild. Only throw RuntimeExceptions to crash? Why not just Exit if that's the proper thing to do?
If you treat all C# exceptions as RuntimeExceptions, then it satisfies the blog anyhow.
Side effects are not allowed in functional style programming. Exceptions are side effects, it doesn't matter whether they are checked or unchecked exceptions.
While composing methods in stream style is convenient, methods that can throw exceptions warrant more careful coding, so convenience should not always be the priority.
One of the original lambda proposals for Java - the one from Neal Gafter - also had checked exceptions.
The problem is that you then need a way to capture exception specifications as generic type parameters to properly propagate contracts, which complicates the type system quite a bit. Which is why Java ultimately went with the much simpler proposal that didn't even try to tackle this.
Yes I'm well aware, but that is uniquely a Java problem. With a sufficiently strong type system, like the one in Scala, you can easily make checked exceptions work across higher order functions.
I don't know that I'd say "messed up", but I do wish C# had checked exceptions. I strongly believe that they are superior to non-checked exceptions, basically static type signatures but for error handling. It's a real pity that everything after Java seems to have abandoned the idea.
Java itself has basically abandoned the idea, or at least the ecosystem at large has. Checked exceptions are a decent idea but Java's implementation sucks. It needs to be a lot more automatic or something
IIRC all previous conversations about checked exceptions here ended up with the swift conclusion that they are heavily discouraged throughout Java code.
And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between error and panic model. I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.
None of those arguments are convincing. In many cases, you can't handle errors more reasonably than just crashing or telling the user something went wrong. Java has RuntimeExceptions, which do not have to be declared in the function signature. Division by zero, or trying to index an array out of bounds, and the dreaded NullPointerException, are some examples of RuntimeExceptions.
You usually wouldn’t crash the entire application, the request that causes the issue will return a 500 error. (Or equivalents for non-web environments.)
Some exceptions are not recoverable and may cause 500 error. Others such as FileNotFound are recoverable, for example by reading the file from an alternate location.
> I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.
Reducing boilerplate is not a valuable goal in and of itself. The question is, does the boilerplate buy you something? I think that with checked exceptions it does. Having an explicit type signature for what errors a function can raise improves correctness a great deal because the compiler can enforce the contracts of those functions.
I agree that the Rust approach is good too, though I don't agree it has any strong advantages over the way Java does things. Both approaches are equally respectable in my view.
My opinion on that is the projects scale. Typically people came from a 10+ year Java project of 100+ engineers, to a greenfield advanced hello-world -- of course it's going to feel better and more productive.
Also, as open-source folks say, "rewrite is always better". It also serves as a good security review. But companies typically don't have resources to do complete rewrites every so often, I saw it only in Google.
I've worked in 3 of the biggest rails codebases in the world (Shopify being the last) and I can say from experience that rails legacy monoliths are infinitely worse to work with than some awful, but harmless, sea of struts XML legacy.
I find this really interesting, and meets my (limited) Rails experience and (extensive) Java experience:
I found it hard taking over an existing Rails project - it felt frail to me, that any small change might have unexpected consequences.
Whereas when I've taken over Java projects - or come in late to an existing team - I felt quite confident getting started, even if it is a bit of a mess.
Same here. I started to really like java after working with js/ts on small to medium project. I started to love java after working in on medium to little big project.
My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.
The reason I prefer the Go ecosystem to Java is cultural, rather than technical. Sure, the JVM is very impressive and the language has been evolving, but the culture around Java seems to encourage needless complexity.
Of all the languages I've had to work with trying to get to know unfamiliar code-bases, it's the Go codebases I've been quickest to grok, and yielded the fewest surprises since as the code I'm looking for is almost always where I expect it to be.
Leaning heavily into object orientation, including baking in things like companion objects, object expressions, etc. Encouraging utility classes that tack half-baked functionality onto existing types. Smart casts encouraging overly complex hierarchy.
While operator overloading and infix functions aren't a Java anti-pattern, I also think the language would be improved by their removal.
Even if you sincerely believe that OOP is an anti-pattern, surely it was firmly "baked into the language" in Java already? Kotlin is fundamentally a better Java, not a rebuttal to Java.
It is all but impossible to use Kotlin without an IDE telling you everything, and for that I find the language interesting. And for comparison, I did in fact write Java without an IDE for an extended period of time.
The don't embrace that culture. Embrace a simpler culture. Strive for simplicity. Push for fewer dependencies.
Simple example, JAX-RS running on top of Java SE. I agree, JAX-RS is not what one might call "simple". It IS complex, or I should say, it CAN be complex. But Happy Path, staying in the middle of the road, it's pretty sweet for knocking out HTTP backed services. The Jersey reference implementation will do most anything you need (including stuff not "included" in raw JAX-RS). No need for a container, no need for a lot that stuff and all that hanger-on. The core runtime is pretty broad and powerful.
Consider my current project, it uses the built in Java HTTP server. Which works! It's fast, it's functional, it's free. (Yes, it's in a com.sun.net... package, but it's not going anywhere.) It's awkward to use. It's aggravatingly raw. It follows the tenet "why be difficult, when, with just a little effort, you can be impossible."
So, I wrote a simple "servlet-esque-ish" inspired layer for response and request handling, a better path based regex-y router, and a nicer query parser for queries and forms. 500 lines. Add on a JSON library and I can process JSON-y web request/response, easily. (I also wrote my own Multipart processor -- that was another 500 lines, boy that was fun, but most folks don't need that.)
A little bit of code and the built in server is MUCH easier to use. No tomcat, no deploys, zip. ...and no dependencies (save the JSON library).
Something all of these cool frameworks and such have shown me is what's really nice to have, but at the same time, just what isn't really necessary to get work done. I mean, CDI is really neat. Very cool. But, whoo boy. So I have a single singleton to handle application life cycle and global services. It works great with tests. I have a 50 line Event Bus. I have a 100 line "Workflow Engine". 150 line java.util.Logger wrapper (which is mostly, you know, wrapper). I wrote that way back whenever they introduced varargs to java (Java 5? 6?). The modern Java logging landscape is just...oh boy. I'm content with JUL -- I can make it work.
My current project is "magic free". I think @Overide in the single annotation anywhere in it. But it's comfortable to use, the cognitive load is quite load (outside of the actual application itself, which is NOT low -- sheesh). No swearing at frameworks. It's all my fault :).
Anyway, the point is that "simple Java" lurks in there. It needs a bit of uplifting, but not a lot.
You've made your point, but note the built-in HTTPS server only supports TLS 1.2, so don't use that for production code. (For testing it's probably fine.)
Not sure, but the API docs say 1.2. Maybe the com.sun packages include their own implementation of TLS, separate from the TLS used in the rest of the JRE.
True, but the culture around go isn't any better. In my experience go developers are former java developers so they have the same culture of thinking it's ok to ignore how a unix system works. So you will have awful logging, daemons that never report they're ready, badly handmade command line parsing and so on.
funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
I think that's a bit unfair. Generally the stacktraces tell you exactly what and where the problem is. Generally shouldn't be more than a dozen lines or so.
The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.
Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.
Tip of the Day: You can wrap errors using "fmt.Errorf" in Go - this gives you a nice chain of error messages which is a pseudo stack trace. Another tip is to define and leverage sentinel errors when wrapping errors so you can test using "errors.Is" higher up when doing error handling in the call-hierarchy - like when mapping to http errors or exit codes.
Using "fmt.Errorf" is lean and painless compared to defining custom errors.
And be very careful in constructing your error messages so that grepping the error string does not return you 50 matches. It's not the same as getting the error message + file name + line number.
This is the whole story of Go, they pick something established and reimplement a heavily cut down version of it for "reasons", then slowly catch up to competition over the next decade or so.
It’s still not stack traces for every error, which is the default in every other language with stack unwinding.
In practice you have to use a combination of error wrapping and custom stack trace errors for your production logs to be useful on failure. The stdlib errors really should have stack traces.
same! mid-way through my almost 3 decade career I got bored and thought lets try some non-JVM projects, for 2 years I took projects using other languages etc… worse two years of my career :)
The actual jobs and networking aspect is fine imo, but I loathe the feed/content, even the SWE-related stuff is a lot of times bad or clickbaity.
I hide the feed + sidebar with a uBlock Origin filter and it's a much nicer experience:
linkedin.com##main[aria-label="Main Feed"],aside[aria-label="Add to your feed"]
So don't read the feeds. My LinkedIn exists as an easy way for other folks in my field to contact me who might not have my email. Works quite well for that process. I don't read any posts.
I dont understand the hate either. Yes it sucks if you follow people you don’t know, but LinkedIn allows you to hide literally everything without breaking the connection. It’s not like Twitter where you are forced to see the updates of the CEO.
One thing that non-Java devs don't get is just how much better the tooling is for Java than literally any other language.
Most jetbrains IDEs I find are indeed comparable to vscode plug-ins and a huge glob of vim plug-ins for most languages, especially the dynamically typed ones where the amount of static analysis you can do is already quite limited.
But for IntelliJ, literally no other editor comes close. Extract method/variable, all the "hey you wrote java 6 but it's 2024 that those 6 lines you wrote are 1 lambda now, do you want to replace", and so many other things.
Did you know that if you paste a maven xml dependency coordinate into a .gradle file, it auto-translates it to gradle format before the paste?
This is absolutely true, but having spent a lot of time The Java ecosystem and then much time outside of it, I now think this is a bit of a curse. It has made the average Java developer actually structure their code and build practices around the IDE, rather than the other way around. If it wasn't for modern CI practices which force a headless build, I wouldn't be surprised if most Java projects wouldn't even build without the IDE to do the building for them. In several places I worked, Even That wasn't really usable outside of the CI environment because it was just taped together as an afterthought and bare minimum since all the developers just used IntelliJ to build locally anyway.
Even little things like variable naming, explicit types, and the like were commonly neglected because in the IDE you could just hover your mouse over the variable to see its type. Because that exists and is so commonly used, developers didn't even think about The impact it might have on someone not using the same IDE. This is just one of several practices that I continually ran into when trying to use vim. There are also plenty of readability issues, such as enormously long methods that the IDE collapses for most developers so they never see it and don't have to think about it, but once you aren't using that IDE anymore, you really see all the nastiness and warts.
So long story short, I agree with you about the tooling, but I think it is actually more of a curse than most people realize.
Most of that could also be considered getting the best out of the tools at hand. Is it necessarily a good idea to always optimize for the highest common denominator? Even for a contributor that at the time of the decision is merely a hypothetical? That same attitude could be brought into a project by someone who refuses to use a build system and insists on everything being laid out for easy compilation by manually launching javac, or on writing makefiles instead of a pom.
I mean sure, there are projects out there where a healthy dose of tool-agnosticism should not be too much to ask for, but a generalized "they are doing it wrong" about people playing to the strengths of their toolkit is really not warranted. The opposite of structuring around what works well with their tooling is structuring around what works well with your tooling. You ask for exactly the thing you are refusing them. Yeah, IDE-only builds are a bad idea, but that's really a concept that has died a long time ago (even if there are probably a few cases around where it still has not stopped moving yet)
You're not wrong, but IME, if people are doing stuff like that, it's not something an IDE or lack thereof would solve anyway. Sometimes you just have to either train/mentor or (if unresponsive) fire people who write such primitively bad code.
I have an engineer on my team that loves RubyMine. I can't even argue with her choice... JetBrains does indeed make very solid products. I'm just not a fan though. Even still, I never want the code I write, or the tools I choose to be IDE/editor specific. Right now we're trying to figure out how to get Biome (JavaScript linter/formatter) to play nicely with RubyMine... it's not as simple as NeoVim/VSCode.
Jetbrains Goland doesn't make your code IDE specific at all. They don't do any magic, go build and everything else all works as expected from the command line. go fmt, go imports, revive, etc., can all be configured in the editor to run on save. My only complaint is that there are so many options, it takes a while to grok everything.
So instead of picking tooling that works with the dev tooling your developers like, you pick tooling that's dime a dozen (js formatter) that doesn't work with the best tools your devs like? Got it. How are you still a manager?
I'm confused at what your comment was designed to achieve. It seems like an attempt to troll. But here it is:
Formatting tooling was chosen before several members joined my team. It was chosen due to having far fewer dependencies than ESLint+Typescript+Prettier etc. One package... one setup.
Secondly, what exactly do you think managing is? Someone has to make the ultimate decision and be responsible for it. Perhaps you think a manager is someone who's constantly wandering around taking a vote from everyone on how they want to steer the ship? While I do strive to find concensus among my team that's not leading. Agree to disagree there.
In my experience VS Code (with TypeScript) even the main refactoring options don't work very well. For example when I rename a method, move a file between directories, or move methods, the imports are not correctly updated and I have to spend time fixing errors before compiling.
With IntelliJ + Java I can do more advanced refactors (change method signature for example) and it compiles without any manual effort.
Ah don't get me wrong, I absolutely agree. For advanced refactoring and bigger project, IntelliJ is very much ahead. I just think that vscode is itself far ahead of emacs/vim in that regard. It's in a middle ground between IDE and an editor once you get a language plugin installed.
I guess it depends on the area, but I thought Rust jobs were still hard to come by even today?
For jobs, ecosystem and general productivity my go-to is always Java/C#/Go, if you learn one of those I think you'll be set, so Go in your case. The learning curve for Rust is similar to C++, much steeper.
A friend of mine explained that there are overlapping phobias of water and deep dark spaces that this game triggers; he said it's unbearable to play the later levels.
I'd imagine anyone with claustrophobia would struggle with the last couple levels as well since they're essentially a battle against the screen crushing you.
Have you tried RenderDoc for the OpenGL side? Afaik that's the equivalent of Xcode's debugger for Vulkan/OpenGL.
reply