Depends on what are you doing. For any programmer working on a bigger project, where compilation time is greater than 2s, (let's say) 4x more power is superb.
If your code compiles in ~16 seconds, reducing that to 4 would add comfort.
If your code compiles 60 seconds, reducing that to 15 would allow not losing concentration.
If your code compiles in 60 minutes, reducing that to 15 minutes would actually allow to do any work on that (not that it's not possible, but it's really not pleasant).
That's assuming it's sufficiently parallizable. If you only have a single thread, an ordinary Intel desktop CPU is still faster than any Xeon: https://www.cpubenchmark.net/singleThread.html
I thought about 4-core vs newer 8-core desktop CPUs when upgrading, but decided that I more often do work on less than 4 cores (with 1 you get the "Turbo" capacity). The only multi-threaded program is PyCharm which can use up all those cores when recalculating its static type checking of Python code (which it seems to do quite excessively).
And luckily, code compilation tends to be one of those things that can actually be effectively parallelized.
Another thing useful for a programmer is being able to benchmark things - with a multicore machine you can tie off one core (or multiple cores!) exclusively for a benchmark, which can really help reproducibility.
The platform is not only for deploying Haskell apps - it can host any web server written in any language including JS. I think the platform is simply written in Haskell.
Hi, I once tried that, but I ran into problems with lazyness. In particular my data structure was rather simple (famous gap data structure), but editing "large" files (>1000LOC) became rather unpleasant (too big input-feedback latency).
However I managed to build a _very_ basic proof-of-concept editor (no dependencies) in just a few hundreds lines of code which I could explain, but until now I was too shy to share it as it did not involve magic abstract Haskell-foo ... ;)
It's got an amazing (I'm not sure if that's in a good or bad way) system for reloading config. Config is code. Reconfiguration means recompiling. If you reload the config, you recompile yi and reexec it - file handles and other information is left laying around so you end up in exactly the same state as before. It's slightly scary from the programming side...
Yi is really nice, overall. The code is clean too.
I don't remember all of the issues, but there are a ton of small things that make the editor unusable to me. I used it for a couple of weeks, and I spent some time working on these issues, but never had PR-worthy code. Here's what I can remember off the top of my head:
- Startup time is very slow because of the way configuration works. In my local copy, I made a version without runtime configuration, and that solved this problem. This conflicts pretty badly with the whole architecture, so I didn't make a PR.
- :n :N don't work. Opening multiple files from the command line doesn't work.
- :cq doesn't work. I fixed this, but my fix was a hack, so I didn't make a PR.
- Operating on regions with '{' and '}' is off by one line in some directions.
- You can't replace regions with shell commands. For example, using '!}sort' to sort a paragraph.
Possibly (dunno). But they refer to that on slide 7:
- We also introduced new safer APIs like reallocarray()
- I wrote a big diff for nginx to adopt reallocarray() other such techniques
- And it got rejected.
It's OpenBSD specific. But it's also just 10 lines of portable C that are permissively licensed and can be added to any project without problems. It's even in a separate source file for this very purpose [1]
If your code compiles in ~16 seconds, reducing that to 4 would add comfort.
If your code compiles 60 seconds, reducing that to 15 would allow not losing concentration.
If your code compiles in 60 minutes, reducing that to 15 minutes would actually allow to do any work on that (not that it's not possible, but it's really not pleasant).