Type annotations have improved things a bit, but since it's not real, or enforced by anything, every library types things differently & often incorrectly, if at all, and the type annotation system itself still has massive limitations.
That's not to mention the package management ecosystem.
I'm getting into Go and Rust. Go is fine but it would be a million times better if it had proper enums & pattern matching for result & options types. Being able to define a class of errors as an enum in Rust makes handling them so easy.
Rust is really cool, but I know I am barely scratching the surface with it and it would be hard to convince any of the Python shops I have worked in to go to Rust due to the learning curve.
All the Python shops I have worked have eventually started to write some stuff in Go, except the one shop which is just data/PySpark stuff .
Poetry is good but not good enough to use at work yet. Also - not Poetry’s fault - many Python packages are miserable at listing and versioning their dependencies correctly.
Re: everything else, you’re right but it gets really tiring writing tests that are handled by the type system in other languages.
Go has this problem too to a certain degree since multiple error subtypes can’t be expressed as an enum. Just errors.Is and errors.As everywhere.
What's the IDE like? How are dependencies managed? Is there a solid framework, as opposed to "move fast and break things" frameworks or "scores of amateurish third-party add-ons to choose from" to solve everyday problems? What's the programming community like? What kind of companies use these solutions, and what's the culture like there?
Tools a big part of what we do. If I were a mechanic, I would rather work on Hondas with a good set of tools than I would Ferraris with tools bought at WalMart.
Personally, I've done only a tiny amount of C# development. I'd have no problem going back to that.
I've worked at a place where developers didn't do any IDE configuration. The IDE (Visual Studio) was customized by another department then was pushed out to developer machines. This meant that developers could focus on building software and not messing around with configuration and plugins. It also ensured that everyone's code compiled the same, ensured library compatibility, etc.
IDEs may not matter so much on small web apps, but one cannot extend that fact to all of software development.
Personally, I loved never fucking around with IDEs.
Also in my experience, "compatibility" is best enforced by API/ABI/FFI contracts, and commitments to support released versions for a given length of time.
Even though that may make sense in some large environments it's not something I could put up with. I'd never take a job somewhere like that.
I mean I do use them quite voluntarily. That's the thing that annoy(ed) so much.
Like they wrote the UI in 1999 and never updated it
I wonder what you'd say about the command line. The interface has not changed for like 40y+.
I 1st started using eclipse in 2006 or so, while writing some plugins (post compilation byte code editing) in 2003-2004. The UI has been updated somewhat since, not drastically, though. I've got pretty decent understanding how it works internally and what functionality is available.
Truth be told, updating the UI just to look modern might find some fans but to many it'd make it less usable for no good reason. For instance I don't want my hand drill to feature an OLED display, coupled with bluetooth just b/c it's cool and dandy.
I still enjoy Python, but I don't consider it an exception to any general principles here.
- Visual Studio, probably the best IDE ever created.
- With .NET (Core 3.1~6), code that usually "just works" x-platform.
- Mostly-workable application development ecosystem as of .NET 5.
- Ecosystem of first-class CI/CD/Cloud/et. al. products & features.
- World-class debugging experience, even across the network.
- Stable versioning scheme with dependable LTS options.
- Confidently run mission-critical loads on latest Windows Server platforms.
- Very large library of high quality 3rd party dependencies (nugets).
- Trivial to configure own nuget server for internal/private use.
- Virtually everything you need is a first class dependency.
- LINQ
- Very good GC, especially when configured and used correctly.
- Strongly-typed with very expressive language features as of C#8.
- Fast compilation times, even on monster projects.
- Principally maintained by largest software company on earth
- Maintained by the open source community as well
- Extreme performance (.NET Core optimizations, Kestrel, Disruptor, et. al.)
- Extreme productivity (VS tooling, Self-Contained Deployments, Blazor, etc.)Also 'brown' languages being older and more established, there are plenty of older engineers who RTFM first, look at man pages first, etc then ask questions.
The real difficulty though, is addressing the alternative hypothesis that language design improves over time. This is obviously the view of language designers or else they wouldn’t make languages.
In that case, you would see the languages turn brown in your analysis, and even in more robust cohort analysis. But it would not be because of a honeymoon bias, it would be because you don’t want to use a horse-drawn carriage if you could use an automobile.
I do think there's other stuff going on as well though. For example, newer languages are often designed to address perceived problems with existing popular languages. I'm a long-time Kotlin and Java developer, and Kotlin feels a lot like Java 2.0 - it specifically addresses a number of pain points people were experiencing with Java. So of course I'd rather be working with Kotlin, and going back to Java can feel like a drag.
I wouldn't be surprised if cognitive modeling shows that graph-manipulation engages different chunks of one's brain than step-by-step procedural description, but I do not know.
Java is arguably used in many of the same companies, but also seems much widespread across a more diverse range of different types of companies.
Python and C# seems like outliers here though. People really love them.