When people not super into hardware say Moore's Law, they mean Dennard Scaling.
Which did roughly end in the mid 2000s. That's why we've spent so much time parallelizing in the past 20 years rather than just expecting increases in single threaded perf
The maintainer of Xlibre was not the "main maintainer" of Xorg. It is all smoke and mirrors, a fake-it-till-you-make-it strategy to be able to prematurely say "I am a X developer" without having put in the work. Their commits only go back to 2022 and they are all miniscule changes that haven't fixed any of Xorg's architectural warts.
That depends a lot on the constitutional right. They're, generally, phrased as restrictions on the federal government (assumed to apply to state governments under incorporation post civil war).
There are a lot of times the government is limited even dealing with foreigners abroad (in legal theory anyways, ymmv in reality).
I think a much better way forward is proposed by Jake Zimmerman[1] of the Sorbet team. That is to allow the runtime to parse RBS inline format comments.
That retains Sorbet’s fast static checker and its runtime checks which Typescript compiled to JS lacks.
steep and rbs don't work so well and are the wrong approach. sorbet is also the wrong approach but it works better. The Python 2 -> 3 way would've been a better way to do it but Matz chose an unwise way (separate files) that doomed it combined with a failure to type all the things and make it work. Oh, and very few Ruby gems are cryptographically signed and so most code is mostly untrustworthy. Making important things optional makes them unused and essentially worthless.
My team uses it for geospatial data. We rasterize slippy map tiles and then do a raster summary on the gpu.
It's a weird case, but the pixels can be processed independently for most of it, so it works pretty well. Then the rows can be summarized in parallel and rolled up at the end. The copy onto the gpu is our current bottleneck however.
> The idea that because software goes through a standardised workflow and pipeline over and over and over again as it’s built it’s somehow like a factory is also bullshit.
I don't think it's bs. The pipeline system is almost exactly like a factory. In fact, the entire system we've created is probably what you get when cost of creating a factory approaches instantaneous and free.
The compilation step really does correspond to the "build" phase in the project lifecycle. We've just completely automated by this point.
What's hard for people to understand is that the bit right before the build phase that takes all the man-hours isn't part of the build phase. This is
an understandable mistake, as the build phase in physical projects takes most of the man-hours, but it doesn't make it any more correct.
You're misunderstanding my meaning with pipeline: you're thinking it's just the CD part of the equation. I'm thinking about it as the whole software development and delivery process (planning, design, UX, dev, test, PR reviews, CD, etc), which can be standardised (and indeed some certifications require it to be standardised). In that context, even when the development pipeline follows a standardised process, most of it's nothing like a factory: just the CD part, as you've correctly identified. Because the output of CD will be, for mature software, 99+% similar to the output of the previous build - it is definitely somewhat analagous to manufacturing, although if you think about adding tests, etc., the process evolves a lot more often and rapidly than many production lines.
This might be one of the rare times it's worth it. The C# team alread has the experience and tooling to maintain a language. Maintaining a DSL might be a reasonable choice for them.
It's rarely a good idea for app or library devs to make a similar decision.
Yes, this reminds me of meta-programming in languages like Python, it's useful if you want to create a framework like Django, but if you work on products, chances are good you should not use it.
> The U.S. still has competition from Europe and China, no?
Not militarily, at least not the way the Soviets were competition.
If the US really is on the Roman path and transitioning from the republic to the empire, it's not clear Europe + China have enough force to keep MAD in place.
Europe + China have between 500-750 nuclear weapons usable on short notice. Depending on how well classified US missile defense programs work, it's possible for the US to only lose a single digit number of metropolitan areas.
Combine this with the fact that large, dense urban areas primarily contain the current administration's political opponents, and that may become acceptable losses.
A potential alliance between the US and Russia being on the table (or at least a non-aggression pact) further bring a non-MAD world order into the range of possibilities.
As a veteran of a large scala project (which was re-written in go, so I'm not unbiased), no. I was generally not happy.
This was scala 2, so implicit resolution lookup was a big chunk of the problem. There's nothing at the call site that tells you what is happening. But even when it wasn't hidden in a companion object somewhere, it was still difficult because every import change had to be scrutinized as it could cause large changes in behavior (this caused a non-zero number of production issues).
They work well for anything you would use environment variables for, but a chunk of the ecosystem likes to use them for handlers (the signature being a Functor generally), which was painful
> There's nothing at the call site that tells you what is happening.
A decent IDE highlights it at the call site.
It's definitely an abusable feature, but I find it very useful. In most other languages you end up having to have completely invisible parameters (e.g. database session bound to the thread) because it would be too cumbersome to pass them explicitly. In Scala you have a middle ground option between completely explicit and completely invisible.
I'm not sure what you consider a decent scala ide, but it was a problem with IntelliJ in several of our code bases, and I'd have to crawl the implicit resolution path.
I eventually opted to desugaring the scala completely, but we were already on the way out of scala by that point
> it was a problem with IntelliJ in several of our code bases
It shouldn't be, unless you were using macros (always officially experimental) or something - I was always primarily an Eclipse guy but IntelliJ worked well. Did you not get the green underline?
We weren't using macros, but one of our major dependencies was (geotrellis).
Didn't seem to matter how close to geotrellis we were though. That being said, I'm willing to buy that it confused IntelliJ enough that it gave up on entire packages
Either way, we ported a couple of the abstractions from there to go and just used that. The build times plus getting away from sbt have been enough of a win to keep us on go, and that's before we get to the memory reduction on in-memory rasters
Oh SBT is awful and I can see why drags down the reputation of the whole language. I stick to Maven and I don't understand why other people don't do the same.
yeah that's what i thought, but maybe scala implicit param not being perfect will help finding a better linguistic trait (maybe they should enforce purity on these parameters)
IMO it is perfect, or at least better than anything else that's been found so far.
"Purity" means different things in different contexts. Ultimately you can give programmers more tools, but you can't get away from relying on their good judgement.
Which did roughly end in the mid 2000s. That's why we've spent so much time parallelizing in the past 20 years rather than just expecting increases in single threaded perf
reply