The light rail is especially chilly, but it has to be with how often they open all the doors at every stop and let in a little heat each time.
As a planned city the downtown urban area was ideal for all kinds of transportation, with streets wide enough not to be obstructed by double-parked wagons, and suitable for streetcars to be installed just about anywhere when they arrived. Much more amenable to public transport than SF or New Orleans, even though horses were the primary consideration to begin with.
The problem was always overpriced real estate downtown, and it got to be too late for newcomers to afford, so anyone that could then started or settled in nearby communities at different distances outside city limits.
With unbridled growth, the city gradually annexed or enclosed these "suburbs", some of which are inside the 610 loop. Pretty much part of the urban area now, but not originally connected by more than one trail usually, which must have left some residual bottlenecks to this day. And that's inside the loop, where people once commuted in from the western suburb of Bellaire, or the close-in location of the Heights.
Just outside the loop to the southeast, people used to consciously depart from Houston and drive "all the way out" to Pasadena. When public transport was on the rise in the county (far too late) about 50 years ago, Pasadena voted not to pay the extra 1% sales tax which was earmarked for Metro, simply because they did not want innumerable people in the big city who couldn't afford cars to descend on their much smaller industrial suburb so easily.
I guess without intervention, stupidity trumps planning if growth is excessive or too accelerated.
For me, I'm just fine on a bike in 100 degree heat with (life-giving) humidity to boot, but I'm probably not the average senior citizen. The homes I like best were built specifically for this climate before A/C, and have more than enough windows to open, and I prefer not to use A/C when driving alone either.
I came from Florida so this is Northern Living to me, if I didn't like it hot I wouldn't be here :)
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.
That depends on your definition of "fun to drive". Flooring it loses its charm within a week, and with the additional weight most EVs are awful when it comes to taking corners at speed.
EVs might be fun for drag racing, but if you want to drive on a circuit ICE is still the better option for now.
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 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.
From memory, the language server appeared to be a second-class citizen, debugging was kind of idiosyncratic, static analysis was poor... but I confess it has been a while since I made a serious effort to use it.
I was particularly frustrated by the promises of composability not translating into practice.
I was also stricken by the same npm/Rust-like pathological dependency trees where I had to pull 200-plus packages for some function.
> 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.
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)
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.
That reads to me more like a long-winded example of a Julia user refusing to take correctness issues seriously, and instead using an LLM to self-soothe by deflecting onto other projects:
> I think there’s also a mindset split, some people just like to have things more strict and avoid bugs by having their compiler proof everything, and others like more freedom and are fine with occasional mishaps.
> Just for the fun of it, I put claude on Python, and it also found some eye watering correctness issues (to be fair, I haven’t taken the time to verify and judge them, but it seems like that’s a similar situation for the Julia version)
I say "self-soothe" because if the intention were to better understand the correctness situation, presumably one would at least want to evaluate the output before declaring it "eye watering". And then even if the output was real, it would be better to report it to the affected Python projects instead of using it as an excuse to downplay problems in Julia.
But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me, often for clearly nonsensical inputs. Seriously, `np.array([1, 'two', 3.0])`? That's not a bug, the behavior is clearly documented on numpy.org, but really no matter what Python does with that, it's not comparable to issues like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))` from that post about Julia. Which again the linked Discourse post downplays as "freedom and occasional mishaps".
You can not be serious in suggesting these aren’t straight up Python correctness bugs. Exactly the same kind that Yuri brought up as damning evidence of Julia unseriousness, but for Python with easily 25x the user base.
Most (all?) aren't bugs by any stretch of the imagination, no. Let's go over the first 5.
1. random.choices(['a','b','c'], weights=[-1,5,1], k=10000)
Negative weight on 'a' silently shifts
Python docs say, "Weights are assumed to be non-negative and finite." Garbage in, garbage out.
2. random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000)
Non-monotone cum_weights makes 'b' unselectable.
...Those weights aren't cumulative, which the docs say they should be. Again, garbage in, garbage out.
3. statistics.fmean([1,2,3], weights=[-1,1,1])
“Mean” of three values in [1,3] returns 4 — outside the convex hull.
This is just straight-up mathematically correct behavior. It preserves linearity. It fits the commonly accepted definition of weighted mean as `(w1*x1+w2*x2...)/(w1+w2...)`.
The LLM fabricated a fake/idiosyncratic definition of weighted mean in order to claim it's a bug, because it was instructed to come up with bugs.
4. json.dumps({1: 'a', '1': 'b'})
Produces invalid JSON with duplicate keys; round-trip silently drops one entry.
Again, documented behavior/GIGO. Docs say, "loads(dumps(x)) != x if x has non-string keys."
This is literally just what geturl() is supposed to do. It's the whole point. Docs say "empty parameters, queries, and fragment identifiers will be removed". The LLM is claiming that geturl()'s primary intended purpose is a bug.
So all of these "eye watering correctness issues" so far seem to be either (1) straight-up correct, or (2) doing things Python explicitly tell you not to do. Same deal with the Numpy "bugs", AFAICT, as I touched on in my previous comment.
In fact, I would venture that we all know those Python bugs are fake, but (unfortunately) the Julia ones aren't. Because the Julia bugs mentioned by Yuri were reported to the Julia bug tracker, and eventually fixed. Whereas if you really thought these are real bugs in Python, then (IMO) you should be reporting them to the Python tracker, not getting mad at me for doubting them.
Moreover, even if they were real bugs in Python (which they aren't), bugs existing in Python still wouldn't change the situation for Julia. The Discourse user who posted it still admitted that they didn't even take the time to verify them.
Surely you must realize how bad it makes Julia look, when its users fling LLM slop to attack Python in response to Julia's issues being brought up? A constructive project should instead talk about what's been done and planned to improve Julia's situation, not tell lies to drag Python down. I liked Julia when I tried it! The JIT plus multiple dispatch is so unique. But this so isn't the way.
python has plenty of bugs like these too. is this example also "LLM slop" ? I think it's frankly delusional to somehow believe that these issues are unique to Julia.
> But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me
exactly. and the same is true for many of the bugs that have been presented as indictments of Julia. but when the same is said of those, the community is called "defensive." so it's a lose-lose.
There is no equivalence here. The Julia bugs were real. They were reported, accepted, and fixed. The Python bugs you linked to are fake LLM slop, see my other comment right above/below this one. [0] If anyone really believes the Python bugs are real, they should report it to Python, not use it to deflect from Julia's issues.
What's been presented as an indictment of Julia (in Yuri's own post and after) is the fact that members of the Julia community have vocally downplayed problems and played the victim when quality concerns have been raised, as I think you're doing. Do you want to convince everybody you've "won" "a lose-lose"? Or do you want to write correct programs?
I like Julia, the language and the tech. I really hope this hostile attitude towards criticism and growth fades eventually, because I'd like to be able to use and trust it at some point.
I wouldn't say this is true really. Julia does have some unique properties which cause these issues other languages just sidestep. The dynamic dispatch system is really magical when it works, but it's the source of much of the consternation you see here in this thread, and the reason it persists despite individual bugs being fixed. The problem is the "bugs" in this case aren't really as such; they're not wrong code, they are violations of silent contracts.
The whole magic of dynamic dispatch is you write Library A and Type B, and they "just work" together without having to know about one another. This is of course very powerful and so people have been very enthusiastic when wielding it.
But with great power comes great responsibility; when using libraries and types that weren't meant to work together, one of those types might violate a silent contract in the library. This would be fine if the error could be caught at compile time, but it happens in the form of numerical correctness issues, so they don't even present as actual errors.
The most obvious example of this is where Julia allows for arbitrary arrays and two things expecting different bases come into contact. This is something that's just not possible in other languages, so they're not exposed to this class of bugs.
So maybe you can harden and make explicit some of these contracts, or put up warning signs, or add some lints, and thus "fix bugs"; but they keep coming back because the dynamic dispatch system assures it due to the combinatorial explosion of interactions it incurs. I'm very interested in how Julia will solve this issue going forward.
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)
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.
> but why are you trying to think about a list of elements in terms of offsets from the origin
I don't try to think about them in this way - I do and have always thought about them in this way - in software terms for 50 years, in real world cut, saw, and hammer ways for over 60.
> I find it much easier to think in terms of ...
Which is the crux of the issue really, that's how you think.
> v[i] is the i-th element of my vector.
I think of V as the start of a row of elements.
V+0 is equivalent to V and naturally the start of the first element.
V+1 is the start of the row, plus one - the literal start of the second element.
I've always thought of V[i] as offsets, "jump overs" if you will.
It comes naturally for many that have worked with their hands on physical objects and worked with tape measures.
> but it is not something that necessarily needs to be polluting the semantics of a high level language.
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.
There are even some funky (or eyeball gouging) tricks done to preamble a data run with meta data, leading to V[-1] indexing being commonplace (in some domains)
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.
reply