I'd have written this exact comment two years ago. After two years using C# and .NET in anger, I'd pick it for almost any project. It's better than Python, Ruby, Go, Elixir, Typescript, Etc. and better than Rust unless you absolutely must squeeze every ounce of performance out of something, and even then, sometimes C# is better.
I know it's not cool, but I spend very little time on distracting stupid shit in C#. No other ecosystem does it as well as .NET. It seems like such a low bar, yet almost no one can get over it.
I sit down to program for what feels like 30 minutes in a moment of inspiration, and I look up and it's been 5 hours and I got more done than I was expecting. Every other language often has me dealing with some distraction having nothing to do with the actual problem I'm hoping to solve, and sometimes robbing me of the desire to solve the problem at all.
Other languages drive me to mess with my editor config, because it's more fun than trying to convince my environment that a business problem is more important to solve than why some dependency that was importing fine a week ago is now broken. Other languages have me trying to get AI to build me something I've built before without typing any code. C# wants me to ship something quickly that works and it wants to help me do it. It's a remarkable ecosystem, and it makes it really hard to put up with the hoops the others make me jump through. 5/5, would .NET again.
All that said, you .NET folks need to let your patterns die in a fire. Modern C# doesn't require any of this crap anymore. Use functions. They're great. The world of nouns is behind us.
Honestly, I could see myself writing this some time ago, but I somewhat disagree with it now. The problem isn't the patterns themselves, the problem is the overuse.
C# provides many tools to allow you to defer needing to apply patterns (which you should when possible) until they are actually necessary, such as extension methods. But some patterns can provide lots of utility and prescribed ways to approach problems that provide uniformity to large codebases.
Yeah, .NET developers have been passing CancellationTokens around in the places where they have needed them for 15 years. The tokens are basically invisible until their existence emerges when someone decides they want to cancel a long-running API call or something. At that point, they are plumbed as deeply as seems fit for the problem at hand and then hardly thought about ever again. CancellationTokens are generally a delightful pattern, especially when the language allows sensible defaults.
"It's not exactly making me feel valued as a community member"
Neither is not getting paid for work/services. If one works hard on things and can't pay their bills, that's unsustainable. Why is developer time worth nothing to other developers? If you can write it and host it, do it. If you can't, and the folks that can charge for it, hand over your credit card so they can continue to do it. Or watch it die when they have to abandon it to make a living writing code for someone that will pay for it I guess.
I do support many FOSS projects. Obviously I can't provide the kind of funding that element is looking for. And that's really where it rubs, none of us in the community can. It's their choice to position this as a massive enterprise level solution.
Can you actually buy that for a handful of seats? All the benefits they're touting apply only to massive installations. So it sounds to me that they wouldn't be interested in selling this to home users. They'll probably refer you to element one or the community version.
Yea I am also not that familiar with the different editions that are available and the whole ecosystem is confusing to me with matrix/element/dendrite/synapse etc.
I feel like though they would have some accessible paid plan for “smaller” users that want to support the development of the project long term - I believe this is the most sustainable way to build complex “big” FOSS projects - apart from having someone sacrifice themselves for the greater good I guess
Which seems to me they want to talk to purchasing departments, not end users. But let's pretend I'm trying to give them money anyway. No Buy/Sign Up link, the Get Started link in the top right and Get In Touch link on each price box lead to the same place: https://try.element.io/get-started?utm_source=pricing-busine...
Again, "consumers go away and use the free tier" or "learn more" about their enterprise offerings. Learn more brings you here: https://element.io/server-suite with a generic sales pitch and a "Get Started" link on the bottom.
Which sends you right back to the second page. So right now, apparently you can't pay Element money
So I'm not sure if Element has made an improvement to this page since, or it's a layout difference based on screen size, but on my windows tablet, the page was as described above, but on my Linux desktop, there is actually a lead generation form. Still a pretty onerous process that individuals are not going to do, which is clearly by design.
I came here for the bad takes, and I have not been disappointed. Dynamo slays when you know your access patterns and need consistent performance and no operations requirements. Turns out, that's the case most of the time. Think about it as application state instead of a db. It's not key-value like Redis. GSIs with compound keys allow access to data across multiple dimensions on virtually unlimited data with consistent performance. Its weakness is querying data across dimensions you didn't plan on. If you need that regularly, it sucks. If you need that once in awhile, write a migration.
Agreed. It's wild to me how many people think they need arbitrary queries on their transactional database and then go write a CRUD app with no transactional consistency between resources and everything is a projection from a user or org resource -- you can easily model that with Dynamo. You can offload arbitrary analytical queries or searches to a different database and stop conflating that need with your app's core data source.
Well my experience has always been the opposite. New query patterns are always appearing. The difference between an OLTP and an OLAP query is not as clear cut as one might imagine that justifies huge changes to an existing system.
- Low-cardinality partition key leading to hot keys, trashing capacity utilization.
- Bad key design means access patterns are off the table forever, as nobody wants to take on data migration with BatchWriteItem.
- Read/write spikes causing throttling errors. The capacity concept is difficult - people don't understand how capacity relates to partitions and object sizes, or wrongly assume "On-Demand Capacity" means throttling is impossible, or that Provisioned Capacity Autoscaling is instant.
- Multiple GSIs to cover multiple access patterns = "why is our bill so high?".
I've seen these issues over and over again while working with real organizations.
Of course it's impressive technology, it's just so littered with traps that I've stopped recommending it except in very specific cases.
People act like managing lots of git repos is hard, then run into monorepo problems requiring them to fix esoteric bugs in C that have been in git for a decade, all while still arguing monorepos are easy and great and managing multiple repos is complicated and hard.
It's like hammering a nail through your hand, and then buying a different hammer with a softer handle to make it hurt less.
> all while still arguing monorepos are easy and great
I don't know anyone who says monorepos are easy.
To the contrary, the tooling is precisely the hard part.
But the point is that the difficulty of the tooling is a lot less than the difficulty of managing compatibility conflicts between tons of separate repos.
Each esoteric bug in C only needs to be fixed once. Whereas your version compatibility conflict this week is going to be followed by another one next week.
And the tooling to handle this is not even particularly conceptually complicated - a "versionset" is a set of versions - a set of pointers to a particular commit of a repository. When you build and deploy an application, what you're building is a versionset containing the correct versions of all its dependencies. And pull requests can span across multiple repositories.
Working at Amazon had its annoyances, but dependency management across repos was not one of them.
> And pull requests can span across multiple repositories
This bit is doing a lot of work here.
How do you make commits atomic? Is there a central commit queue? Do you run the tests of every dependent repo? How do you track cross-repo dependencies to do that? Is there a central database? How do you manage rollbacks?
Thad exactly the problem. At least tooling can solve mono repo problems.
But commits , which should span multiple repos, have no tooling at all. Except pain. Lots of pain.
This article is the what, but it is missing the why. I'm supremely biased against scrum, so basically ignore what I am saying if you're a fan of it. Fundamentally, Kanban is pull-based, and Scrum is push-based. That's the difference.
Scrum spends time determining how long things will take, and then attempts push it into a schedule via story pointing and other ceremony where people pretend they're not guessing how long thing will take by using points and t-shirt sizes and anything other than time to guess how much they can get done in some arbitrary amount of time. Then devs do what they were going to do anyway, and everyone slaps each other on the back because they're measuring the success they're having. It's a dream for people who like to count things and build check lists and check them off. Its success has little to do with the process and much to do with the team's ability to gather requirements and do their job. It's ideal for contract gigs where it's as important to track how much time it takes you to do things as it is to actually do things.
In Kanban you put what you want to do in a list, and pull the things from the list in order as you complete them. If customers need things quicker, you change the order of things in the list while communicating to them what will slip and what will accelerate. They take as long as they take (because that's how the world works, yes, even in scrum), but with 100% less ceremony and pointless coordination. Kanban is about constantly managing constraints and eliminating waste. You don't need to strictly measure how long things are taking. You pay attention when things don't move off the board, and modify resourcing in whatever way will get things unstuck. It's less fun because you don't get to pretend you know how long something will take, but it's more fun because you get to be an adult professional instead of a servant to the processes of people who don't actually build things.
This is somewhat tongue-in-cheek, but in my career I've never seen switching to pull-based patterns make things worse, and I've often seen them make things better, including morale. It doesn't seem like it will work, but in practice there are so many efficiencies gained in pull-based processes that it usually ends up being faster and feeling better while doing it.
The clustering is what makes it feel so different, and what makes it such a compelling runtime for certain types of problems.
It's not an accident that large distributed chat programs or MQ systems are often written in erlang. From inside the code, writing a distributed system feels the same as working on one node.
With go, you can't do channels to a go process running on a different server without significantly changing the language. In erlang, you don't notice because that's just how it works.
Write an app that runs on two nodes and sends updates to all clients via websockets. In erlang, you just write it. In EVERY other language, you're loading a non-idiomatic library and probably running an MQ cluster or using an MQ service... probably written in erlang.
