reminds me of an project I made many years ago to manage dependencies in between repositories. So if project A was waiting for a fix in project B to be in production, you could draw a line between the two commits (from project A to project B) and get notified when the commit in project B gets into the "production" branch. And then merge and deploy your feature branch from project A.
I worked on a toy programming language (that compile down to golang), which is a fork of the go lexer/parser, but it changes how functions can only return one value allowing the use of Result[T]/Option[T] and error propagation operators `!` and `?`.
It has enums (sum type), tuple, built-in Set[T], and good Iterator methods. It has very nice type inferred lambda function (heavily inspired by the swift syntax)... lots of good stuff!
I guess accusing someone of being someone they are not, then accusing them of lying, then demanding they dig up old forum posts for you to prove a point that other individuals have echoed, isn't considered being hostile or abrasive to you?
By all means, believe whatever you want regarding the health of the Nim community. Just don't expect me to share your sentiments.
I like how he kept "tabs" (and display it as 9 spaces) to make it as ugly as possible for the bad example, then proceed to use 4 spaces for the other examples.
I suspect this is substacks default styling. It actually doesn’t set the tab-size which defaults to 8. However there seems to be some funky font-rendering going on so it adds an extra half (or maybe three-quarters) of a space per tab-character.
You can see this your self if you edit the markup in your browser’s inspector and add `contenteditable` attribute to the surrounding <pre>, then navigate down a line... it will jump forward just by slightly less then a column per indent level.
I'm well aware of it. But I don't think I have ever seen an editor/website which would display it as 9 spaces. Github for example default to 4 spaces width.
Yes, this is very weird. But Go Playground[1] has always been using 8 spaces per tab for some reason. I always found that very jarring, particularly where almost every other editor or documentation has settled on 4 spaces per tab.
> But because of the later stage when it becomes 600ms vs 60s.
What later stage though, as I said I worked with big code bases on old hardware without issues.
I'm simply not convinced that there exist a situation where incremental rebuild of the crate you're working on is going to take 60s, at all, especially if you're using hardware from this decade.
I must be doing something wrong because incremental builds regularly take 30-60 seconds for me. Much more if I add a dependency. And I try to keep my crates small.
As a sibling comment points out, it's likely to be mostly link time, not compilation time.
The most recent Rust version ships with `lld` so it shouldn't be the case anymore (afaik `lld` is a bit slower than the `mold` linker, but it's close, much closer than the system linker that was previously being used by default).
That's strange. Humongous k8s Go projects (>500k LOC) build in a third of that time. Do you have lots of deps in your `go.mod` ? Is the project abusing codegen ?
On a Macbook M2 Pro, on a project with loads of services, 210k loc, a full rebuild takes 70 seconds. Incremental takes 36s.
For one service, full rebuild in 16s and incremental 0.6s.
It's not blazing fast but considering the scale of the project, it's not that bad, especially since I rarely rebuild every service at the same time.
Consider upgrading your hardware if/when you get a chance to (obviously this is expensive). My builds (Rust not Go, but it might well be similar?) got 10x faster when I upgraded from a 2015 MBP to an M1. I suspect 2019 to M4 might be similar.
There's no “big tutorial” though. There's a section about compilation time performance[1] but it's arguably not “big”, and the most impactful parts of it is about linking time, not compilation time. And half of the section is now obsolete since rust uses `lld` by default.
For case like this, I'd say your text editor should definitely just be able to tell you right away that this variable is a "string" when you mouse over it.
