5 ms·
Presumably all their F# runs on .NET--if their goal was simply transitioning to a language with a broader talent pool, wouldn't they "just" migrate the project
by xxr 3y ago
Presumably all their F# runs on .NET--if their goal was simply transitioning to a language with a broader talent pool, wouldn't they "just" migrate the project to C# instead? I'm wondering if this is less about "the death of functional programming" and more about an internal platform unification under Java.
- neonsunset 3y agoNon-zero chance Walmart's architects didn't even know .NET runs (and is easier to deploy to than Java) on Linux for good 5+ years already... Edit: Okay, they know, I'm sorry :) Does not make it less sad and perhaps very unfortunate decision. Also, Hibernate sucks.
- mlrtime 3y agoI'm sure they know .NET runs on Linux. Changing the underlining OS for 1000's of hosts is not a trivial task.
- bravetraveler 3y agoI'm sure they've been forced to endure mono as part of 'wonderful' security software There's two kinds of Mono on Linux from what I understand... The older one is packaged with a particular piece of security software, and the packages have more problems than I can count edit: I got got! TIL that proper .NET on Linux exists. I'm more mad at Mono/this software now
- neonsunset 3y agoWhat makes you think so? Mono has never been used for back-end workloads aside from projects led by enthusiasts.
- bravetraveler 3y agoI edited my post a bit to include a vague hint; it's not "backend workloads", assuming part of an application stack/service It's security software - to be less vague, it's software made by Crowdstrike
- neonsunset 3y agoOkay, now this evokes some bad (because of Crowdstrike) memories... But using Mono in any recent years where the blessed way to do so is just using .NET is a big disservice to what the thing can do, and it requires you to really go out of your way to make a container that uses Mono over vanilla (Core)CLR. Also, not liking what is now MIT FOSS stack does not make sense. It is the unified set of repositories going forward, with Mono currently serving exotic targets like WASM and being a part of dotnet/runtime. Completely not surprising for it is the most standard myopic response you usually hear from Linux communities (which, checks notes, are supposed to advocate for OSS?) the moment .NET is mentioned.
- bravetraveler 3y agoI appreciate you making me current, being more on the architecture side than software... I get very little exposure to these happenings. I mostly glue existing stuff together, not make new stuff. My frustration with .NET is dated, really due to Mono. > which, checks notes, are supposed to advocate for OSS? I'm not sure how much to unpack here; my complaints are more with what I was given than anything philosophical
- outworlder 3y agoYou don't have to use Mono. People are talking about actually using .NET on Linux.
- bravetraveler 3y agoWell that makes me even more upset at this software
- spankalee 3y agoI've worked with former Walmart technical staff and they're quite good, and there is indeed a zero-percent change that their team doesn't know this.
- jxf 3y agoThe Walmart folks are pretty bright in general. I did some consulting for them a while back so I saw this first-hand. Organizations aren't monoliths, of course, but my experience was that they definitely did know what they were doing.
- tombert 3y agoI was on the Walmart teams that did F#. Since at least 2018 there was at least some services running on .NET Core on Linux, and by 2021 everything was on Linux. Most of us dev'd on MacOS using JetBrains Rider, running .NET Core. My title wasn't "architect", but it was "Staff Software Engineer" by the end. Does that qualify?
- phillipcarter 3y agoI was on a call with one of the more senior Walmart (non-Jet) architects about Java and .NET back when I worked on the .NET team. He seemed dismissive of the idea that F# (and .NET) ran perfectly well on Linux, and didn't demonstrate even the slightest curiosity about that. We committed strong support for their workloads, talked about our staffing for that support, talked about how they'd flown me out to New Jersey twice for some in-person feedback and learning sessions, etc. Didn't seem to matter to this person. Where my heart lies aside, I also think it's rather dumb. My understanding of the system talked about in this job post is that it's quite mature and works very well, and my default stance for any rewrite is "don't be dumb, don't do it", and that would apply here.
- VirusNewbie 3y ago.NET really lacks a lot of first class open source libraries that the JVM ecosystem has. I think C# is a superior language to Java, and I think F# made some interesting trade offs that might be beneficial in the long run compared to Scala, but I wouldn't recommend companies go the .NET route these days. It's too easy to run into a situation where the 'official' API supports Java/Python/Go as a first class citizen and the .NET library is a sad afterthought.
- ActionHank 3y agoCould you give a couple examples of libs that are missing. Not disagreeing, just curious.
- novagameco 3y agoMostly client SDKs for different RESTful HTTP APIs
- VirusNewbie 3y agoApache Beam, Kafka and Scylla at my previous job were both examples where I felt like the .NET offerings were either not official or severely lacking.
- banashark 3y agoDotnet and java usually have similar libraries for most things, but sometimes it comes down to how different they are or what they support. Let's look at general distributed messaging abstractions. The most modern-featureful one for dotnet I know of is MassTransit: https://masstransit.io/documentation/concepts https://masstransit.io/documentation/concepts. You can see it supports a handful of queues and some interesting patterns. Compare this to the list of features in Apache Camel: https://camel.apache.org/components/4.4.x/eips/enterprise-integration-patterns.html https://camel.apache.org/components/4.4.x/eips/enterprise-in... Additionally, the _support_ of the libraries for common open-source (and closed-source infra) is usually vastly different: - https://pulsar.apache.org/client-feature-matrix/ https://pulsar.apache.org/client-feature-matrix/ - Small features being first party like https://github.com/awslabs/amazon-sqs-java-extended-client-lib https://github.com/awslabs/amazon-sqs-java-extended-client-l... vs https://github.com/raol/amazon-sqs-net-extended-client-lib https://github.com/raol/amazon-sqs-net-extended-client-lib - Missing features or those that lag behind: https://github.com/confluentinc/confluent-kafka-dotnet/issues?q=is%3Aopen+is%3Aissue+label%3Aenhancement https://github.com/confluentinc/confluent-kafka-dotnet/issue... - Usually manually wired and configured vs the spring boot "starter" pattern of having libraries that automatically do some of the manual setup work for you: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-starters/README.adoc https://github.com/spring-projects/spring-boot/blob/main/spr... I wish more client library sets had the feature-matrix that the pulsar one does, because in practice most end up being the same: Java supports everything because it's either built in the same codebase or is the most used client and gets the most support, while the dotnet client codebase has many feature-requests or performance improvement issues, often leading to a "third-party client" being created.
- WorldMaker 3y agoThis was my take as well, especially with the intentional name dropping of Kafka.