bb1234

I don't like them either. I find it hard to articulate why I don't like them. I definitely have experienced problems with them where they get into some state where the cell results are incorrect. Then, if I restart the kernel and run the cells again, I get the correct result. But I don't like them for reasons other than this one, and cannot explain why. I prefer the ipython REPL to the notebook.

Same here. I have the same issue with realtime services. They are either free (and, hence very limited), or over $50 per month. I wish the usage-pricing step function had smaller jumps.

My websites run on https because how easy Caddy makes it. Caddy made it possible for me. Cannot thank Matt Holt enough for creating Caddy and making it available to all of us.

That is a good practice for any statistical software you are using. You should validate your R code with Python or Julia.

Vocal minority might be one of them. But I think that is not the only reason. I think it also because a lot of very useful and performant tools are being written in it. Also, the fact that so many programs are being created likely suggests to newcomers (like me) is that it is not unreasonably difficult to write code in it.

This has been said many times, but I think it is because of not having AOT compilation as an option. Due to this, not only do we have the "Time to first plot" problem, but apparently the memory used by the process is also large. I love Julia and use it for my data and computational work. But for CLI apps and for web apps I am learning Rust because the start up speed and memory usage for CLI and webapps matters.

If interested in benchmarks comparing different dataframe implementations, here is one:

https://h2oai.github.io/db-benchmark/

> 2. No language server (apparently it's just impossible due to the way the language works). Tbh, I'd be happy with just "Go to definition" but alas, no-can-do!

This works on Doom Emacs!

I used Crystal to create a web application a 2-3 years ago. It is running great without any problems. There are not that many users (only about 300-400) at any time. Anyhow, I did not touch the application in the last two years, and did not use Crystal in the last two years for anything else. I used Rust to write some simple personal CLI apps, which was fun but also hard. For some reason, couple of days back I returned to Crystal for a CLI app that I am making. I will say this: Crystal is a lot of fun to program in, easy to use and performant all at the same time. I cannot explain the reasons objectively, but it is really a joy to use Crystal. I think I will be using it from now on. I just wish it had a bigger community and as a result more libraries.

That means chew your food thoroughly so that it becomes almost liquid and you “drink” it. Also, don’t gulp your drinks down quickly. Drink slowly, as if you are chewing each sip.

Yes, Caddy is awesome! About 3-4 years ago it made it super-easy (and possible) for me to serve my websites with `https`. Before that, I was using nginx, and the process of obtaining certificates seemed quite complicated. Matt Holt, thank you for creating Caddy.

If you are going to rewrite, you may want to consider Julia. It will give you close to C speed, but will be as high level (or higher level) than Python.

Thank you.

For someone who does not know much about NIFs, will it be a lot slower if the Rust service is coded as a command line application and then invoked using System.cmd? Is that a good alternative?

Greatest Of All Time

You said "The thing about Julia is that you can code without caring about performance (and the performance will be Python-like)."

This is not my experience. Even if you code without caring about performance it is way faster than Python. Also, it is not any harder to code in than Python. It is as high level if not more.

This is a good point. I think products like these have strong network externalities (more the number of people use it, more beneficial they become). For this reason, a new product may not replace an incumbent product even when the incumbent product is slightly inferior. I spent a lot of time learning and using ConTeXt. Wrote one of my articles using that. When the time came to send it to a journal, they wanted it either in Word, or formatted using their LaTeX style files. At that time I gave up on ConTeXt, since I did not want to keep learning and using two different systems.

Do you have an alternative to suggest?

For me the main selling point is speed. I had coded a simulation in Python which was slow (would have taken days for the whole thing to run). This version did not use Numpy. Then I coded it in Python so that I could use Numpy. Just to be able to use Numpy I had to use arrays, where it did not seem natural for the problem I was solving. The numpy version gave me a 5 times speed up compared to the original Python version. I then coded it in C, which was about 20 times faster than the numpy version (and 100 times faster than the original version). Then I coded it in Julia, which was much easier to code in than coding it in C as well as Numpy. I could use loops where they felt more natural to me. It was essentially like the C code, but using many high level functions that Julia provides. Not a least bit difficult than the original Python version, would even say that it was a bit easier. The Julia code ran just as fast as C.

Other benefits (not over Python, but I believe worthwhile when choosing a language): very friendly community to beginners. You ask simple questions and get answers without any attitude. As I noted above, many high level functions that make dealing with data much easier.

If you are going to try it out, I would recommend using the Long term support release, rather than the current stable release. With the latter, I have had issues where some packages often don't work for me. With the LTS release, I have yet to experience that. Maybe I am doing something wrong, but for me LTS release works great.

Any modeling approach can be implemented/used in an incorrect way. The so-called analytical approaches also often make very specific assumptions on functional forms to be able to obtain analytical solutions. By performing extensive sensitivity analysis one can reduce the drawbacks you mention. Of course, this needs to be done, and you are probably right that many papers don't do this. But that is hardly a problem with the modeling technique, which can be quite effective if used appropriately.

Is there a way to fix this?

If you care about a rich standard library, and static self-contained executables, I would strongly suggest Crystal. I have used both Go and Crystal, and the latter is much more productive as well as simpler. It’s standard library is richer. See, for example, the things you can do with strings with the provided functions. I used to love Go. But after some time the verbosity got tiring. I moved to Crystal, and there is nothing I miss from Go. Two big caveats: 1. I dont work in a big team. 2. My main use case is a web-backend.

I would second this. I moved from Go to Crystal. Crystal has been great to work with. Due to a rich standard library, the absence or fewness of third-party libraries may not be much of a problem, especially if you are looking for developing web applications and command line tools (two areas where I have used it). It also has a very friendly and helpful community.

According to the benchmarks at https://github.com/kostya/benchmarks, Crystal is about twice as fast as Go.

Question: For someone who does not know either Rust or Zig, would you say that Zig also has tools that help the programmer protect from data race conditions (I have read that Rust is helpful in this regard)?

Since you are asking about performance of some languages, you may find this helpful https://github.com/kostya/benchmarks

I believe you mean to say prisoner's dilemma, rather than a zero sum game.