eigenspace

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)

Programming languages have bugs. These things happen, and this tired article blows them totally out of proportion.

Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python.

Julia is an extremely flexible and permissive language, which means that generic code needs to be written carefully and contracts between interfaces need to be thought through.

When you combine funky package types like OffsetArrays with functions from a package where the authors didn't think about OffsetArrays, bad things can happen. Those things were then reported and the community has learned a lot about how to deal with those sorts of things.

I'm sure an AI agent can crawl through and find a new big list of weird bugs in julia, but that's true even of a language like Rust.

Julia is such a great language, it's what really made me care about end enjoy programming. I think it's the modern language which has taken the most lessons from lisps, and has come up with some great ideas of its own too.

There's lots to like, but I think the thing I love most about it and find it so interesting is that it's almost uniquely good at taking a piece of code and transforming it's meaning in various ways, and has so many tools for doing so. There's

  * Multiple dispatch allowing very flexible writing of generic code, and multiple dispatch isn't some tacked on, opt-in extra. Every function in the language is overloadable, and there's no performance penalty for using multiple dispatch

  * Parametric typing allows for a huge amount of abstraction over common 'base' types

  * Lispy macros let you do metaprogramming that changes the meaning of a piece of syntax

  * Generated functions let you intervene at compile time and lets you essentially take over the compilation pipeline and customize the code generation for any given input type signature

  * The abstract interpreter interface which lets one essentially take over the compiler and customize your code generation and analysis passes to your heart's content. This is used for instance to support GPUs and automatic differentiation as package offerings.

So far :')

The process you're describing is underway. Schleswig-Holstein, Munich, Leon, and the Austrian military all come to mind as recent examples of that sort of migration, and then pivoting savings into support contracts for open source.

That process is super important yes, but what about cases where the relevant government bodies don't think the open source offering is ready yet for them?

That is where the STF steps in, and gives funding to open source projects so that they can develop to a point where their software is ready for stable adoption by governments.

Flatpak is proving to be a very important piece of underlying infrastructure if government agencies want to switch to Linux computers running distributed graphical applications for their workers.

Yes, it has major problems, and you might be right it won't exist in 10 years, but the point of this grant is to fund their attempt at fixing their problems and getting it to a point where it's better infrastructure that can survive into the future.

I don't really agree here. I think what they are doing is pretty strategic, especially given the relatively limited money they have.

There's basically two sides to funding software that are actually rather different

   1. Accelerator phase: getting the software to a point where it can reasonably replace some foreign closed source enterprise option (i.e. feature devlopment). This sort of thing is often highly speculative. It should be project based, with concrete deliverables, and done with a non-permanent grant. If things go reasonably well, then there can be followup grants. This is what the STA focuses on, and is a major gap in the FOSS world.

   2. Established phase: Once the software is actually ready for adoption (thanks to help from the STA!), and gets integrated into government functions, then the agencies that *use* the software should be setting up enterprise support contracts that give long-term support and stability to the projects they've adopted. A good example of this would be Nextcloud who has multiple such contracts with different parts of Germany (also other European organizations). This part is better off being done by the agency that *uses* the software, rather than having the STA do it. Some of these agencies do in fact also have internal software developers that work on Nextcloud.

I don't think it's a shortcoming of the STA that they're focused on point 1 rather than point 2, I think if they were forced to do both, they'd actually be less effective at what they're doing.

The STA is basically trying to fill the role that venture capital plays in getting a startup ready to take on customers, except the STA doesn't take an ownership stake, and they focus on FOSS.

I don't think the comic is claiming that all tariffs in any context are bad, that would indeed be a reductive, bad take.

Given the timing and the metaphor of blood being sent to and from a limb, this is almost surely a reference to the tariff threats against Canada.

So, here is one of the major problems with having a US administration run by liars, crooks, and bullies: your arguments lose all credibility.

I'm a Canadian who is pretty unhappy with our protectionist dairy lobby, and thinks there probably is a bunch of unfair trade barriers erected on our side by the dairy lobby.

I'm probably more open to this line of argument than the majority of Canadians. However, when I see an American who has literally anything to do with their federal government start making these arguments, I more or less have to assume it's either a lie, or at best a truth that's going to be twisted, blown out of proportion, and used to undermine the sovereignty of my country.

The furthest I would go right now would be to support a relaxation of our dairy protections in dialogue with the EU, and then whatever scheme we arrive at can then be applied to trade with the USA at a later date (including requiring dairy imported from the USA to meet EU-level food safety standards).

The USA simply cannot be trusted to be anything like good-faith negotiators.