olikas

It checks if any of the deprecated features are used. 4.0 removes classic queue mirroring, changes the underlying metadata storage to khepri and introduces many improvements. Instead of asking many questions, it analyses the definition file locally in the browser.

Yes, JIT is enabled. Slowness is quite relative to the use case. Which part do you find slow?

httpc is good for a one off request, but it is not very up-to-date with the latest features of the web. So building application logic on top of it is not ideal.

This was (is) the case for classic queue mirroring. Quorum queues use a raft implementation and can synchronise the delta. As of now, the two major features missing from quorum queues are message TTL and priority. The former will come soon. It is true that QQs have different runtime characteristics but they are much more stable in a clustered environment.

I use instagram and my own webpage. The single biggest problem I have is consistency. For me art is a hobby, so I don't always have the time. So my instagram engagement is all over the place. The webpage is good, but hardly anybody reads it (which is not necessarily a bad thing).

This happens a lot in mathematics. Definitions that depend on intuition usually have very weird edgecases. When you formalise a definition and explore the definition to a “wider” domain, then the intuition usually breaks and can have surprising consequencies. It also happens a lot in calculus. Things that work beautifully to continuous smooth functions can have an a strange edge cases. Eg if you add infinitely many continuous and smooth wave functions the result can be a non continuous function. Same here, the intuitive definition of a prime, when formalised, and applied to non positive number sets have unintuitive consequencies. One is that it can actually work.

I had a similar experience early in my career. To me it was eye opening to see some masters keep investigating problems without getting emotional. I learned how not to care about the time it takes to figure things out, but to start and carry on. This way given enough time, almost all problems are solvable. The time pressure doesn't change this fact.

In case of a time pressure, I just focus on workarounds instead of analysis. Once the problem is no longer burning, it's up to the project priorities to investigate the root cause.

I also learned that panic never solved any of my problems, so when I notice that I am moving into panic mode, I stop for a minute and cool down. This is a skill that can be learned.

If f is linear, then f(a)=f(a+0)=f(a)+f(0). So f(0)=0.

Most native speaks have little knowledge of the grammar and syntax beyond intuitive.

The fact that they don't know the scientific names of the grammar rules doesn't mean that they don't know grammar. As somebody how's native language is very dissimilar to English, my intuitive language rules are no help speaking English. The grammar you are taught at school is descriptive of English and not a prescription. The distinction s very similar to "laws in physics". Nature doesn't really care about the rules we impose on it.

Learning grammar alone is not enough. Learning vocabulary alone is not enough. Immersing yourself to a language without a guide (like your parents guided you into language) is completely ineffective.

Grammar, vocabulary and pronunciation are equally important if you want to get fluent in both spoken and written communication in a different language.

I know what you mean, and a number that is not infinitely precise is an interval (i.e. a set of numbers). e is a number that is quite hard to pin on the imaginary number line, because the chances of hitting it with a pin is virtually zero. But the same argument can be made about the number 2 or 3. Those are just notations to abstract ideas, even though it is easier to formulate analogies for some of those numbers.

Now, formalising that above sentence even with symbols is quite difficult.

RabbitMQ runs perfectly fine on Windows too. As others mentioned in the comments, RabbitMQ supports a great variety of use cases. If you want to reach out for help, you can find my contact in the article.

I recommend going through presentations of the RabbitMQ Summit. https://www.youtube.com/channel/UCp20sSF_JZv5aqpxICo-ZpQ

There are some big companies talking about their experience.

It is a great book, indeed. I always recommend it.

With clustering, you can have more nodes and you can shard (distribute) your queues over the cluster. You don't need to mirror every queue on every node. But you are right, mirroring alone will add more load.

Author here.

I've seen quite a lot messages going through RabbitMQ. I wouldn't worry too much about scaling, because the possibilities depend very much on the architecture. With some tuning RabbitMQ can take you a long way. I would give clustering a go and see where the limits are before exploring more complicated architectures like federation.

I was in similar situation. I didn't quit, and spent quite a lot of time figuring out what was the real issue that me miserable. It turned out it was something I could change without quitting. I managed to change it, but I first needed to understand the real root cause. It is like debugging your life. Mindfulness and introspection are great tools in those times.

Co-author here.

The problem with number crunching or maths is that it is very difficult to cut the whole computation into smaller units and pre-emptively schedule it. If it is possible for a specific use case, then it is moderately easy to replace that part with NIFs. For effective maths you need to convert the internal tagged number representation to machine native code that is also expensive. Solving these two things in the generic case is very difficult while preserving all the good parts.

I have played with this idea recently lately. I consider almost all code out there as legacy. I was talking about it at a conference also explaining how I like working with legacy code. (https://youtu.be/n0XCMHrSbwc) I think I’m the odd one who actually like working with legacy code.

Regarding debugging, I left a comment higher in this thread: https://news.ycombinator.com/item?id=20359699

BEAM based languages lack "good" debuggers, because they historically depend on tracing instead of debuggers. I recently wrote a blogpost about the tracing landscape in Elixir. https://www.erlang-solutions.com/blog/a-guide-to-tracing-in-... But the main reason is that BEAM languages are mainly used for concurrent computing which is a very difficult problem to debug with classical debuggers. I know it is not a mainstream way to "debug" but a very useful one once one learns it.

I've spend my career reading code. I find it particularly difficult without guidance. I would recommend using some old school technology (pen/pencil and blank paper) and draw diagrams, write down every question and observation, notes. Others may recommend using some digital tool, but be mindful how much energy you spend organising your thoughts, drawing with a digital tool. If your goal is to understand a software, then don't waste time creating beautiful documentation first.

It is also important to have a clear goal. Let's say you want to understand how webpack starts up, or how it does a specific feature. Make this question your main concern and don't wander around. Don't try to understand everything at once. Divide and conquer.

It is also useful if you can ask questions, but please spend some time coming up with a theory first why things are the way they are. Formulate a hypothesis (e.g. "this piece is necessary because it handles an edge case", or "this piece of code looks uglier than the rest, is there a reason?") and try to prove it. If you can engage with the community, the better, but please don't outsource your "thinking efforts" to other project members. You can't learn how to reason about code, if you don't reason.

The most important one: be humble. Just because you would've solved a problem differently, it doesn't mean that the code is bad. Don't spend time judging the code. You are there to learn from others, so be open to other solutions. Whether it is a good or bad example is so difficult to judge... be patient and you will realise what kind of code is easy to understand. Once you have some idea, take that knowledge to your next project. This may take weeks/months/years depending on the project size.

Solving a problem by experimenting is rarely useful. I'd call it accidental solution. You can improve by doing it the hard way. Do not write down anything unless you understand why you do it. As a test, try to answer the following question: "Why will it work?" It is also useful to think about other solutions before committing to one. Try to come up with pros and cons.

You can improve your reasoning skills by fixing bugs. First observe the bug, try to make a hypothesis. Try to support it by reading the code (do not run it, don't use a debugger at this point). Once you have a plan, find evidence that support your theory. Once your theory is right, find a solution, and answer the question "why".

It will take time, but you will improve over time. For me, the key is patience.