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.
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.
> 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!
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.
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?
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.
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.