221–230 of 352 posts
Earlier quoted context omitted.
That con is a pretty big one. Macs have less than 10% desktop market share.
Why does this matter? It’s a server, not a desktop application.
I would prefer languages that don't dictate what hardware/software to use for writing them.
Why wouldn't you just use OCaml, Haskell, F#, or Scala, where you've got much more mature web framework options? Don't get me wrong, Rust is fine, but if you don't need its memory management then why make trouble for yourself?
Earlier quoted context omitted.
Man... I hear you, but this is only a problem compiling from a cold cache. From a warm cache, it really isn't a problem anymore.
No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to. (I know that compilation speed is a Hard Problem, I know that I'm compari…
Earlier quoted context omitted.
Perhaps my examples were a little too trivial. I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling. (OK, you could read preferences from a file, but then you'd have to optimistically write every value you'd ever want to recompile to a file. I've tried this, but it's far too much overhe…
> I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling. I know exactly what you mean. Front-end development can be this way, too. I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now.
I think that's true, but only because of the slow compile times. Which is why they're so frustrating. Rust would otherwise be an excellent language for these use-cases.
It's sad that we still have to make async I/O explicit in the code to obtain some efficient concurrency in 2020. Async/await is a huge improvement over callback hell, but this doesn't fix everything. The "function color" problem still exists [1], and seems to be more than binary in rust. This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that…
Earlier quoted context omitted.
In dynamic languages like JavaScript or Python it's necessary to continually run your code in order to validate that the API (of the standard library or of dependencies) was used correctly, that the types match, etc. Rerunning your code continually is no longer necessary in a language like Rust, because the compiler already does that for you. People complaining about slow compile times in static languages like Rust,…
But the compiler checks your code, and if the compiler is slow, the problem remains.
Earlier quoted context omitted.
Why does this matter? It’s a server, not a desktop application.
> you're bound to Xcode (and therefore macOS) for development I would prefer languages that don't dictate what hardware/software to use for writing them.
Earlier quoted context omitted.
Maybe. At the rate I hit :w, probably not :)
One of the first computer system I used frequently was Windows ME. This system used to crash (BSOD) extremely frequently (depending on what you were doing, it could be as frequently as every 20 minutes), and any unsaved work would be lost. I have therefore developed a reflex where I hit Cmd-S every time I finish typing. I actually have to put conscious effort in to stop this when using software where saving is slow.
Earlier quoted context omitted.
Wow, one of our solutions is nearly 100 projects (legacy) and the compile time for the whole solution is sub-5 minutes. I'd love to see what kind of solution would take 40 minutes to compile! (or maybe I don't :)). That being said, C# is clever enough to only need to recompile the assemblies affected by your code change, so often you can get away with 10 second compile times even for large solutions.
IIRC our solution was around 450 projects. Visual Studio just woudn't open the whole solution. So you had to work in individual projects at a time, slowly going through and changing stuff project by project. VS wouldn't even build it either, really. YOu had to build via batch file that did various ms build magic. I would make changes, set of a build and go to lunch, then come back and fix the errors. Once you checked…