eigenspace

Not super familiar with this part of Sweden, but at least for similarly remote parts of northern Canada, if you're buying crown land with no road access, no facilities, etc it can be similarly cheap when buying large parcels.

Not a particularly surprising number.

This sort of reasoning was always stupid, but it was more excusable before LLMs. Now that there's LLMs everywhere inflating word-counts with slop, you'd think that people would have learned by now to appreciate when an author doesn't over inflate an article which doesn't need to be very long.

One of the best channels on YouTube.

3D topographic surface area has the "coastline problem" where the more precisely you measure it, the more it grows.

2D area is stable under increasing measurement precision.

Here's a nice little dashboard I saw recently on how progress towards net zero is going in various countries: https://lucabron.github.io/netzero/index.html

Germany is more or less on track for the 2050 net zero target assuming linear progress. Realistically, that means with how adoption curves go, it might be possible to hit it well before 2050, but even then actual zero (not just net zero) fossil fuel usage sounds very very difficult.

That said though, currently around 3.9 GW of Germany's electricity generation at any given time comes from biogas, so I guess if all that usage (and all other fossil fuel usage) is displaced by renewables, it'd be possible to store all that biogas, and potentially even convert it to other fuel forms for certain hard-to-decarbonize sectors.

Here's how I like to think about it:

Forwards mode AD (and finite differences) tell you how much wibble of the inputs corresponds to a given wobble in the outputs.

Reverse mode AD tells you how much wobble of the outputs corresponds to a given wibble in the inputs.

If you have more inputs than outputs (such as in optimization), it's cheaper to calculate the wibbles given a wobble, than the other way around.

What you said about spam is exactly what I'm trying to point out.

There are forms of moderation that we often dont even think of as moderation or 'censorship' because its removing content that "nobody" wants to see. One may argue that the spammers are users of the site who are being censored.

Also, this is a side note, but I'd assume that the overwhelming majority of even 4chan users are in favour of CSAM being banned from the site, even if there are some users who want to see it (i could be wrong about that, it's not like i even have anecdotes to back that up)

Deciding what is spam and blocking it is moderation or "censorship".

If 4chan didnt have spam filters, the users would be begging for it almost immediately because the website would become unusable.

If you count platform moderation as 'censorship' then there's practically no uncensored public spaces on the internet.

Literally even 4chan has moderation.

Nobody, not even 4chan users, want an actually unmoderated space.

It's not a live service: https://wccftech.com/blizzard-starcraft-shooter-rejects-live...

What is your point?

Mostly due to the poor design of the city, yes.

Do we really need to turn this into a discussion of lost causes? Yes, you monumentally fucked up urban design in many parts of your country.

Yes, fixing it is theoretically possible. No, it can't be done in any reasonably small time scale.

Yeah I can't speak much to circuit racing (nor drag racing for that matter). I just know that the EV's I've driven have been fun to drive. I don't believe that most people talking about "fun to drive" are taking their cars to a racetrack either though.

I guess I haven't taken any corners agressively enough to really notice the problems you describe with weight.

I will say though that at least for non-racetrack scenarios, the extra weight isn't always as noticable as you'd think because the centre of mass tends to be extremely low relative to an ICE vehicle.

What does that have to do with being soaked in sweat? I could understand if they suggested everyone get around by bike, but this is just silly.

Electric busses and trains can have quite powerful and good air conditioning systems.

The problem with this in Houston is the disgracefully stupid urban layout that makes it very hard to effectively serve the city with public transit.

Is this implication here that you think this car is an electrified golf cart? What makes you think that it wouldn't be fast or fun to drive? Most electric cars are extremely fun to drive due to their extremely high acceleration.

The development and building of newer, more efficient electric vehicles does not preclude the investment in more high speed electrified rail and busses. That complaint is a non-sequitor.

> From memory, the language server appeared to be a second-class citizen, debugging was kind of idiosyncratic, static analysis was poor.

I see. Well, for what it's worth, I think the language server and static analysis have made tremendous progress since the 1.6 days.

The regular language server has improved a lot, but there's also the very exciting https://github.com/aviatesk/JETLS.jl which uses the JET.jl static analysis machinery directly in a language server. JET.jl is super useful, JETLS.jl is maybe not quite ready for prime-time yet, but it's under active development, and is getting pretty close to being ready to be the default choice IMO.

There's also the JuliaSyntax and JuliaLowering work that's been happening in the core language itself which have have been improving code providence a lot, which improves static analysis.

Regarding debuggers, I can't really comment on that since it's not something I use much, but I do know that JuliaInterpreter.jl has had a lot of improvements, and I assume that those improvements have knocked on to Debugger.jl.

> but I confess it has been a while since I made a serious effort to use it.

Totally fair!

I don't think you are under any obligation to follow this stuff in order to share your experience, but I would at least push back against claiming that this hasn't been a priority.

> I was particularly frustrated by the promises of composability not translating into practice.

Mhm, this is a hard topic to have an overview of. I think composability has improved since the 1.6 days because we now have package extensions and weak dependencies which allow us to better glue together packages. I think the community has also been doing a better job of trying to identity and fix edge-cases in package composability, but it's hard to say how much this has improved or not (very vibes-based, hard to have data).

> I was also stricken by the same npm/Rust-like pathological dependency trees where I had to pull 200-plus packages for some function.

Mhm. Not sure I can comment much on this. Personally, I find our package manager quite good, and maybe it's a sign that our package manager is good that there's such a large proliferation of packages that you can pull in, rather than massive monoliths, but I also understand the concern and downsides.

What makes you say that ergonomics have taken a lower priority? A lot of the things mentioned in this blogpost are ergonomic things that don't matter for agentic workflows.

Maybe it'd help me understand if you said what sort of ergonomic things you find are missing.

The only thing that really favours github is the package registrator bot, but that's pretty easy to port to another platform if desired (one can also just make manual registration PRs)

That's way too broad of a statement.

Static typing makes it easier to do RL targeting the sorts of things that static types encode, but it doesn't help at all with things that aren't really type constrained, like for instance writing accurate numerical programs.

Due to how the release cycle turned out, most new major features got pushed to v1.14, and this one is a rather iterative release focused on making various things faster, quashing bugs, and general polish.

Still though, faster GC, lower startup latency, better interrupt handling, new REPL features, and faster package mangement are all great things. I'm especially happy that the `[sources]` section of a package is now applied recursively when you `add` a non-registered package.

Julia does have an interpreter, but due to the multiple disptach semantics and the type system, it's a rather slow interpreter.

There's some exciting work that was presented in Juliacon 2026 though on an upcoming tiered JIT and this should reduce latency a lot, as you suggest.

It's kinda one of those mid-hanging fruits that has been known about for a long time, but not seriously tackled till now.

Here's a somewhat recent discussion sparked by someone who was concerned having read the blogpost: https://discourse.julialang.org/t/julia-stability-vs-rust-fo...

It got a little long and meandered a bit, but I think there's some good, nuanced discussion there.

It's a really nice feature. That said, I do think in the earlier days, the community did get a bit too enthusiastic about it, and used it in a lot of places in the ecosystem that didn't make so much sense.

I think things have come down to a much more reasonable place though now.

I did not say "How do I get *to* ..".

> Of course you do - you very likely didn't start programming in assembler.

I did not, and I do not think that conventions from assembler should influence basic ergnonomic design decisions of modern high-level langauges.

Not trying to gaslight you. Especially if you were hitting that issue with the stdlibs, as I said, I don't think we should have allowed a release to go out with that problem. It was treated as bug though and fixed (though it also took longer than hoped).

The manifest thing is a good example of a hard situation. You have a file format that's not designed to be portable across versions, but the usage pattern around it heavily encourages that, so of course it gets used across versions and bad stuff happens. I'm sure theres also some other examples like this one can pull up.

Of course there's cases where we should be doing better. I'm just also saying that this isn't the only experience out there, and the negative experience you're reporting isn't my experience.

> It's really not early days. The language is about 15 years old. That excuse gets really tired.

Please don't twist my words. I was responding to what you said about webdev, and I said there was some interesting things happening in that space, but still early days. I was explicitly referring to the webdev ecosystem being immature, not the language.

> More like breaking changes

That certainly has not been my experience with the language since 1.0

> weird issues with basic transitive dependencies breaking after a minor version bump to the language.

Not sure what exactly this is referring to, but I suspect it was some bugs that happened when some stdlib packages were taken out of the sysimage and started being treated more like regular packages which are pre-installed.

For a couple minor versions, if you instantiated an manifest from a previous version that used some stdlibs, it could error out. That was indeed unfortunate and IMO should not have been released as such, but it's since been fixed.

I will point out though that officially, you are not supposed to use the same manifest across versions.

> didn't even know you could do web dev in Julia. I don't want to know what that looks like.

There's actually some rather cool stuff happening in that space, but yeah it's early days.

> You asked for a good argument - I provided one.

I don't see a good argument though, I just see adaption to a quirky convention.

> Either way of thinking works - I spent decades going back and forth from Fortran to C, and people are free to make their high level languages however they wish - it's trivial to move from one to the other.

Here I agree. I have no real problem using a 0-based indexed language, I adapt to it quickly (or as you mention a -1 indexed language. Julia itself actually stores type-level metadata at the -1 index of a pointer to a mutable struct)

I just dislike when people try and turn every conversation about julia into "oh it's 1-based indexed so that disqualifies it", and act like 0-based indexing is some god-given most natural way to do all indexing.

Okay, but why are you trying to think about *elements* of a list in terms of offsets from the origin?

I mean, that's an important low-level detail to know when you're working with assembly or doing pointer math, but it is not something that necessarily needs to be polluting the semantics of a high level language.

I find it much easier to think in terms of v[i] is the i-th element of my vector.

These sorts of things just feel like mental gymnastics people perform to post-hoc justify language quirks.

This depends a lot on what you're trying to do with it. There have been companies which did what you described, but there's also companies happily using it.

If you reach into unstable language internals, yes there is a lot of churn. If you use public language interfaces, the language has been extremely stable for a long time.

The ecosystem quality and quantity depends a lot on what you're trying to do. If you're far away from numerics, then yeah, you will struggle a lot more. E.g. I wouldn't want to do web-dev in julia, but if your software product involves needing to solve an ODE, or a lot of linear algebra, I wouldn't want to be anywhere else.

This argument over indexing conventions is so tired.

I have yet to hear a good argument for why the answer to "How do I get the third element of this array?" should be `arr[2]`

> Both R and Julia have their core functions written in C++. Absolutely nothing new.

What on earth are you talking about? This is at least a novel claim. Some deep parts of julia's compiler are written in C++ but that's about it. Nearly everything in the language is written in julia itself.

The only significant foreign codebases in the language are

  * LLVM

  * OpenBLAS

  * LibUV

all of which are extremely reasonable foreign things for a language to use (though we are gradually moving more and more of these things to the julia side)