4,763 karma · joined August 8, 2010
Only when your requirements are low.
Things get very expensive when you start requiring real performance.
> Scaling is a nice problem to have. If you get to the point where you actually need to improve performance, you'll be able to afford to spend time on it.
You don't know that. If you're a startup, it's very likely that you're still not profitable at that point.
That's only relevant if you hold the unscientific belief that men and women are interchangeable and that the reproductive organ is the only thing that's different.
There are many ways where attitudes towards a person must be adjusted depending on the person's gender.
For example, women are physically weaker than men, so if a man was to hit a woman in public, he would be arrested, where as if a woman was to hit a man in public, no one would blink an eye.
> I do not see how there can be disagreement that this is sexism.
Because you are implying it's a bad thing. You can't just take away the context of the conversation and pretend that we are arguing about semantics.
No matter what you say or do, someone will find a way to call it sexist.
I personally just never engage with work colleagues in those terms. Keep everything formal and polite.
If you think I'm cold, well, too bad. But you can't accuse me of any kind of harassment.
If you have a server side application that you hope to be successful then the code will be running all the time and you will pay the price literally because cloud hosting services charge for CPU and RAM usage, which will be off the charts if your server is in Python.
Not to mention all the time you will spend firefighting the performance issues that will inevitably arise. Which also literally costs money in terms of developer salaries and opportunity cost (you can't spend that time to develop new features).
But if you're writing server code, I think choosing an interpreted language like Python/Ruby is the single worst mistake you can do.
The reason premature optimization is evil is that it consumes a lot of time and makes the coder more difficult to read and reason about.
If there's no clear benefit to this, then all the work done to optimize it resulted in _negative_ value. There was no gain, only time wasting and more complicated code.
An example of where performance doesn't matter: a piece of code is only executed once every 10 seconds and it finishes executing in 5ms. Spending time to reduce its execution time to 1ms does not produce any tangible benefits.
An example of where performance does matter: a piece of code is running all the time and it takes 500ms. If you can reduce it to 20ms, it's totally worth it.
> (...)
> why were you thinking of writing it in Python at all?
They simply have no awareness of how slow it is, or how important performance is.
> IME thinking about language performance at all is premature optimization
Are you serious? Python code is about 10 times slower than equivalent code in Go.
People want to switch away from python because of all the pain they feel from it.
Premature optimization would be something that makes the code more complicated and more difficult to follow but produce better performance.
Writing the same code in a fast compiled language is just the default thing that you should be doing when you are not doing premature optimization.
Writing in a slow interpreted language is more like premature "deoptimization" (if that's a word).
It seems like a useless academic term that doesn't work so well in the real world, maybe?
But, this is not the kind of thing that justifies, for example, having 20 engineers to work on this one problem for three weeks.
It's still a simple thing for one person to handle in a couple of days.
I don't get why people use feature lists as an excuse for why things take a long time and require many many engineers.
I counted 9.
- channel is muted and message not in a thread the user is subscribed to
- user in dnd-mode and there's no dnd-override
- this is a @channel mention but @channel mentions are suppressed
- message is for a thread user is subscribed to but channel notification perf is nothing
- notification preference for device is set to "never"
- @here mention but user is not active (not here)
- highlighted word in a thread message the user is not subscribed to
- channel notification preference is set to nothing
- I couldn't understand this condition (@mention in a comment on a file not owned by user?)
You can check these conditions sequentially and if any of them match, return false.
The last statement in the function would just `return true`.
The function needs a struct representing user preferences and a struct representing what's being currently parsed as inputs.
It's really not that complicated.
It will be a complete failure when things get so hairy with so many layers and failure points that you can't tell what's going on anymore.
> WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.
If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case.
Can probably be implemented in a regular function with about 30 lines of code?
Maybe you don't know what a conservative attitude about libraries is because you've never seen one.
Your original comment:
> You can be conservative about adding dependencies and still end up with hundreds
No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies.
> Database driver
About the only legit thing on the list.
> database utilities
Not needed.
> gRPC framework
Not needed.
> monitoring & metrics
Not needed.
> CLI & configuration tools
NOT NEEDED!
.. etc.
> Drop any item on that list and you are either losing capabilities or have more software to implement yourself
What are you losing by not using grpc? You can do a lot of things by just using the builtin rpc package or the encoding/gob with the http package.
Being conservative about adding dependencies means resisting the urge to add them and figuring out a way to do without them.
Every dependency you add is a potential point of failure and headaches.
Just like every layer of abstraction you create.
The cost for dependencies is huge, so every dependency has to justify itself by giving such a huge benefits that it's worth the cost.
> Cobra
Do you need a special library to handle command line arguments? How complex is your CLI interface? How many commands and sub commands do you have? 10? 20? It's trivial to handle that much manually using the builtin libraries.
> Viper
How hard is it to just read a json file using builtin libraries? How much do you lose by not using "Viper" or whatever?
How many times will you have to read config files? One time when the app launches? Does not justify adding a dependency.
> it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto
You don't even need to re-implement anything. Just do the simplest thing that works using the standard library.
You know the standard library comes with a crypto package, right?
The mindset you are presenting is the exact opposite of conservative. You are just grabbing every library that you think can save you 20 lines of code.
Just about anything that's not facebook/twitter/google.
I think you underestimate how much load it can handle.
Really? _that_ is complicated?
Serious question, do you find it complicated because you're still a beginner, or is there something I'm missing?
What language(s) did you use?