Comment by klabb3
3 months ago
The fact that people love the language is an unexpected downside. In my experience the rust ecosystem has an insanely high churn rate. Crates are often abandoned seemingly for no reason, often before even hitting 1.0. My theory is this is because people want to use rust primarily, the domain problem is just a challenge, like a level in a game. Once all the fun parts are solved, they leave it for dead.
Conversely and ironically, this is why I love Go. The language itself is so boring and often ugly, but it just gets out of the way and has the best in class tooling. The worst part is having seen the promised land of eg Rust enums, and not having them in other langs.
This.
Feeling passionate about a programming language is generally bad for the products made with that language.
> Crates are often abandoned seemingly for no reason, often before even hitting 1.0.
That is the one of the first things my colleagues told me after trying Rust for a few weeks: a laaaarge number of crates under 1.0, and so many abandoned crates, still published in crates.io. Some of those have even reported CVEs due to heavy `unsafe` usage for... nothing.
I love Rust, but I have the feeling that the language (and its community) lost the point since the release of the 2018 edition.
I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.
Probably the intersection of people who (a) want an advanced ML-style language and (b) are interested in a CLR-based language is very small. But also, doesn't it do some weird thing where it matters in what order the files are included in the compilation? I remember being interested in F# but being turned off by that, and maybe some other weird details.
That ordering is generally considered a feature to keep dependencies and modules well-organized.
1 reply →
I don’t want to use a language with unknown ecosystem. If I need a library to do X, I’m confident I can find it for Go, Java, Python etc. But I don’t know about F#.
I also don’t want to use a language with questionable hireability.
Haven't used F# too much myself but one of the strong points is because it shares the CLR with C# you can use any of the many packages meant for C# and it'll work because of the shared runtime.
That's all part of my point, really.
To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields.
They've effectively dropped it a couple times in the past, and while they're currently putting effort in, the company as a whole does not seem to care about stuff like this beyond brief bursts of attention to try to win back developer mindshare, before going back to abandonment. It's what Microsoft is rather well known for.
.NET is one of the easiest to install and robust cross-platform systems out there. It's actually very impressive. I don't know of a single other platform that nails cross-platform so well.
The effort of .NET Framework to .NET Core to .NET 5 and now up to .NET 9 is well over a decade long of steady and increasing progress.
2 replies →
> To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields.
This is provably wrong, unless you want to insist despite the facts because that's what your social bubble tells you to do.
The most popular deployment target for .NET is Linux: https://dotnet.microsoft.com/en-us/platform/telemetry
Equating whatever else MS is up to with the way .NET evolves and is managed is no different to equating YouTube and Golang.
4 replies →
Huh? Usually languages that are ”ignored” turns out to be for reasons such as poor or proprietary tooling. As an ignorant bystander, how are things like
Cross compilation, package manager and associated infrastructure, async io (epoll, io_uring etc), platform support, runtime requirements, FFI support, language server, etc.
Are a majority of these things available with first party (or best in class) integrated tooling that are trivial to set up on all big three desktop platforms?
For instance, can I compile an F# lib to an iOS framework, ideally with automatically generated bindings for C, C++ or Objective C? Can I use private repo (ie github) urls with automatic overrides while pulling deps?
Generally, the answer to these questions for – let’s call it ”niche” asterisk – languages, are ”there is a GitHub project with 15 stars last updated 3 years ago that maybe solves that problem”.
There are tons of amazing languages (or at the very least, underappreciated language features) that didn’t ”make it” because of these boring reasons.
My entire point is that the older and grumpier I get, the less the language itself matters. Sure, I hate it when my favorite elegant feature is missing, but at the end of the day it’s easy to work around. IMO the navel gazing and bikeshedding around languages is vastly overhyped in software engineering.
F# compiler is cross os and allows cross compilation (dotnet build --runtime xxx), its packaged in most Linux distros as dotnet.
2 replies →
It's been around for a long time and sponsored by Microsoft. I don't know its exact status, but the only reason for it to lack in any of those areas is lack of will.
Agreed. For the same reason I unironically prefer Java, Go, C++, JS/TS to solve real problems.
I see Java, Go and C++ but js/TS is even worse than rust with regards to package deprecation
My main gripe with npm is the massive complexity of packaging when you have transpilation and different modes in the package.json file. Especially with component libs that need to be packaged.
> My theory is this is because people want to use rust primarily, the domain problem is just a challenge, like a level in a game.
So you mean, Rust is more of an intellectual playground, than an actual workbench? I'm curious how high the churn rate of packages in other languages is, like python or ruby (let's not talk about javascript). Could this be the result of rust being still rather young and moving fast?
> Conversely and ironically, this is why I love Go.
Is Go still forcing hard wired paths in $HOME for compiling, or what was it again?
> So you mean, Rust is more of an intellectual playground, than an actual workbench?
Both. IMO rust shines as a C++ replacement, ie low level high performance. But officially its general purpose and nobody will admit that it’s a bad tool for high level jobs, it’s awful for prototyping. I say this as someone who loves many aspects of rust.
> Could this be the result of rust being still rather young and moving fast?
My hunch says it’s something different. Look at the people and their motivations. I’ve never seen such a distinct fan club in programming before. It comes with a lot of passion and extreme talent, but I don’t think it’s a coincidence that governance has been a shitshow and that there are 4 different crates solving the same problem where maintainers couldn’t agree on something minor. It makes sense, if aesthetics is a big factor.
> Is Go still forcing hard wired paths in $HOME for compiling, or what was it again?
Nothing I’ve noticed. Are you talking about GOPATH hell, from back in the day?
Can you speak more of this best in class tooling?
The official `go` command does dep management, (cross) compilation, testing (including benchmarks and coverage reports), race detection, profiling reports, code generation (metaprogramming alternative), doc generation etc. Build times are insanely fast too.
The only tooling I use personally outside of the main CLI is building iOS/Android static libraries (gomobile). It’s still first party, but not in the go command.
I haven't tried Go in a while, but 8 years ago, I felt the tooling was a disaster. The V1 ways of doing things were really janky, and the improved versions didn't seem to be universally adopted yet. It's nice to hear that seems to have changed.
2 replies →