One of the worst things a developer accustomed to Bazel (and its relatives) can do with a modern language (say Go or Rust) is to model code and organize it through the Bazel concept of a build target (https://bazel.build/concepts/build-ref) first and then second represent it with the language's local organization concepts versus the other way around. One should preferentially model the code with the language-local organizing concept in an idiomatic way (e.g., a Go package — https://go.dev/ref/spec#Package_clause) and THEN map that instance of organization to a build target (e.g., go_library).
When you do this in the wrong order, you end up with very poorly laid out concepts from a code organization standpoint, which is why vagaries like this needed to be written:
In languages that operate on a flat namespace of compilable units (e.g., C++ or Java), build target sizing and grouping in Bazel (and its relatives) largely doesn't matter (from a naming the namespace and namespace findability+ergonomics perspective). But the moment Bazel starts interfacing with a language that has strict organization and namespacing concepts, this can get rather hairy. The flat namespace practice with Bazel has (IMO) led to code organization brain-rot:
> Oh, I created another small feature; here, let me place it in another (microscopic) build target (without thinking about how my users will access the symbols, locate the namespace, or have an easy way of finding it).
— — —
Note: The above is not a critique of Bazel and such. More of a meta-comment on common mispractices I have seen in the wild. The build system can be very powerful for certain types of things (e.g., FFI dependency preparation and using Aspects as a form of meta-building and -programming).
Within the Google codebase and in projects using Bazel, directory layout for Go code is different than it is in open source Go projects: you can have multiple go_library targets in a single directory. A good reason to give each package its own directory is if you expect to open source your project in the future.
:o :o :o
are there really people saying that "giving each package its own directory" is in any way optional?? it is literally part of the language spec, what on earth would make anyone think otherwise??
edit: ok so bazel folks are just on a completely alternative timeline it seems
Bazel ignores go.mod files, and all package dependencies must be expressed through deps attributes in targets described with go_library and other rules.
Maybe better put: Bazel (and its predecessor) do support Go, but they don't support the traditional directory structure-to-import path semantic that we've come to expect in the outside world. And even then, the terminal directory needn't match the package name, but accomplished Go developers seldom violate that convention these days — thankfully.
All of this makes it paramount for developers of Go tools to use a first-party package loading library like package packages (https://pkg.go.dev/golang.org/x/tools/go/packages), which can ameliorate over this problem through the specification of a GOPACKAGESDRIVER environment variable to support alternative build systems and import path layouts (the worst thing someone can do is attempt to reverse engineer how package loading works itself versus delegating it to a library like this).
> One of the worst things a developer accustomed to Bazel (and its relatives) can do with a modern language (say Go or Rust) is to model code and organize it through the Bazel concept of a build target (https://bazel.build/concepts/build-ref) first
And that's exactly what I was arguing against in the article! I've seen this happen a few times already (in Java and TypeScript specifically) where Bazel's fine-grained target definitions are pushed as "best practice" and everybody ends up hating the results, for good reasons.
There are _different_ ways in which one can organize the Bazel build rules that go against those best practices (like the 1:1:1 rule for Java), and I think you can end up with something that better maps to first principles / or what native built tooling does.
You tend to end up with way too many targets that don't actually "mean anything" to a human. In one codebase I have to deal with, the Bazel build has ~10k targets whereas the previous non-Bazel build had ~400. Too many targets have an impact in various dimensions. Some examples:
* The build files are unreadable. If targets don't mean anything to a human, updates to build files become pure toil (and is when devs ask for build files to be auto-generated from source).
* IDE integrations (particularly via the IntelliJ Bazel plugin) become slower because generating metadata for those targets takes time.
* Binary debugging is slower because the C/C++ rules generate one intermediate .so file per target and GDB/LLDB take a long time to load those dependencies vs. a smaller set of deps.
* Certain Java operations can be slower. In the case of Java, the rules generate one intermediate JAR file per target, which has a direct impact on CLASSPATH length and that may matter when you do introspection. This tends to matter for tests (not so much for prod where you use a deploy JAR which collapses all intermediate JARs into just one).
My intuition was wrong, my naive understanding was that:
* Non-human intermediate targets would either be namespaced and available only in that namespace, or could be marked as hidden, and not clutter auto-completion
* IDE integrations would benefit, since they only have to deal with Bazel and not Bazel + cargo/go/Makefile/CMake/etc
* I thought C/C++ rules would generate .o files, and only the final cc_shared_library would produce an .so file
* Similar for .jar files
I guess my ideal build system has yet to be built. :(
> * Non-human intermediate targets would either be namespaced and available only in that namespace, or could be marked as hidden, and not clutter auto-completion
This is actually possible but you need the new JetBrains-owned Bazel plugin _and_ you need to leverage visibility rules. The latter are something that's unique to Bazel (none of the other language-specific package managers I've touched upon in these replies offers it) and are even harder to explain to people somehow... because these only start making sense when you pass a certain codebase size / complexity.
> * I thought C/C++ rules would generate .o files, and only the final cc_shared_library would produce an .so file
> * Similar for .jar files
These are possible too! Modern Bazel has finally pushed out all language-specific logic out of the core and into Starlark rules (and Buck2 has been doing this from the ground up). There is nothing preventing you from crafting your own build rules that behave in these specific ways.
In any case... as for dynamic libraries per target, I do not think what I described earlier is the default behavior in Bazel (we explicitly enable dynamic libraries to make remote caching more efficient), so maybe you can get what you want already by being careful with cc_shared_library and/or being careful about tagging individual cc_libraries as static/dynamic.
For Java, I've been tempted to write custom rules that do _not_ generate intermediate JARs at all. It's quite a bit of work though, so I haven't, but it could be done. BTW I'll actually be describing this problem in a BazelCon 2025 lighting talk :)
indeed, no idea why so many folks seem to think `bazel` is like some co-equal alternative to language-native build tooling/processes, it's a fine tool for certain (niche) use cases but in no way is it ubiquitous or anything approaching a common standard
Seriously. I don't know if folks remember this Java desktop research project from 25-some years ago: https://en.wikipedia.org/wiki/Project_Looking_Glass. To say that it was slow was an understatement (it was a real PITA to get this installed and built at the time; I spent an afternoon in college doing that out of boredom).
I imagine FyneDesk is plenty fine for what it is doing in comparison.
Also this was mostly interpreted back then, without JIT compiler support.
Also to note,
> Regardless of the threat, Sun determined that the project was not a priority and decided not to put more resource to develop it to product quality. The project continued in an experimental mode, but with Sun's finances deteriorating, it became inactive in late 2006
Written from a Java userspace powered mobile phone, with 75% worldwide market share.
That was a really cool project but yeah the Java couldn’t hack it.
FyneDesk aims to compete on performance with the light weight window managers whilst offering the rich experience of complete desktops.
We are close on performance in most areas, once Fyne v2.7.0 is out we will do a new release which is going to blow our previous out of the water. Just a few thread handling bugs to iron out for optimal results first…
Java is fast enough for having legions of kids playing games written in it, and a full OS userspace, it is a matter of implementation, and how much use gets done in JNI, no different than reaching out to CGO or Plan 9 Assembler, while keeping most of the code in Go.
Oh yes, I didn’t mean to knock the language - I also worked on amazing things in Java before I moved to go.
But the runtime of a Go app is, by default, faster than Java and my experiences have shown much, much better performance with the sort of multi-window full screen throughput we need for building a desktop.
youre implying that Stage Manager is Java. I dont think thats true though?
Isnt it only the _design_ of stage manager somewhat resembles some design choices by project looking glass?
this design has also been adopted by the other OS's like windows+tab has previously (in win7 days) created a similar looking view - though it no longer looks like it nowadays.
> this design has also been adopted by the other OS's like windows+tab has previously (in win7 days) created a similar looking view - though it no longer looks like it nowadays.
Looking Glass-like switchers are still available in Plasma
The Project Looking Glass UI != The Project Looking Glass
They are talking about the UI which could have inspired Stage Manager. Apple also had the purple window button before Project Looking Glass so there is that.
Gentoo and Linux from Scratch (LFS) were a great way to learn back in the day (yes, 20-some years ago) — and support relatively custom operating environments through USE flags (e.g., which flavor of Motif did I want to use). I found Gentoo to be a rather practical low-level tradeoff in that era compared to Debian (super old package set and release cadence). You have to bear in mind: there were plenty of Gentoo users out there who weren't into abusing CFLAGS and such. And Portage had such a low bar to climb to create a package (cf. Debian Policy Manual as a description of the arcane nature of Debian package management with dh). Moreover, Ubuntu, which was a good pressure on Debian to modernize, wasn't yet on the mainstream for a good window of time when Gentoo really took off.
He's spent too much time huffing Alexander Dugin's flatulence. It's no different to how revanchist parties in the United States these days characterize their battle against their (domestic) enemies. Just a rhetorical foil.
Note: That link's (actual) photographs seem to suggest that the topic was not adequately researched or generatively produced.
Namely the photo with the caption "The Origin of Swiss Traditional Dress Photo by Cabinet Card Gallery" contains a sign within some words that indicate that even though these are Swiss people in the photo they are actually wearing costume to celebrate Austrian traditional costume of the region of Styria. The hints are "Steirisch" (Styrian) and "Buachstoana" (looks like a phonetic spelling of a Bavarian/Austrian dialect word as opposed to Swiss German and "Verein" (club/association). If someone could expand the "erh." abbreviation in a period-correct way, that would probably be definitively telling. This also doesn't resemble much of the Tracht I have seen worn at festivals in Switzerland either (regionalisms aside).
I don't have anything against ZSH or similar shells. I think they are great, but they are not my thing.
Latency is a deal-breaker for me, and this is where autocompletion engines generally introduce surprising user-interactive pauses. I've generally settled with using mksh (or OpenBSD's KSH depending on the environment) with little configuration outside of aliases, variables, and few local functions. I'm not left with this inkling feeling like accidentally running find(1) over an AutoFS file system backed by NFS that needs to authenticate, mount, and then run the operation.
When I need something more sophisticated, I lean on using Go or Elvish and potentially delegate some UI elements out to https://github.com/charmbracelet/gum.
I'd rather keep my shell simpler and delegate out any other complexity to these other programs. Autocompletion and these other features simply aren’t free.
It's an interesting tug of war, Florida and Texas vs other states. Businesses move there because it's the wild west and low regulation, but their climate costs are accelerating rapidly which is going to lead to what I can only describe as this image from São Paulo: https://www.theguardian.com/cities/2017/nov/29/sao-paulo-inj...
What happens as these states continue to get squeezed by unfavorable long term economics while these businesses and the wealthy continue their performance art? What happens when it becomes constantly more difficult to attract labor to states where the quality of education is low (assuming workers who have or plan to have kids) and the cost of living continues to go up (insurance, etc). An interesting natural experiment and observations ahead.
(Florida resident for the last ~decade, but no longer as of late; US climate costs are approaching ~$1T/year, make good choices)
I've mentioned this before, but once the climate problems in Florida can no longer be handwaved away and Miami is perpetually in a shin-deep layer of water (this already happens after every major rain event, and it will gradually take longer and longer to return to normal, and eventually it will not), Floria will demand and probably get a hundred-billion-dollar engineering megaproject to try and fix the issue on the taxpayer's dime. This will happen because there is too much invested-- both financially in the real estate market, and emotionally in the climate change don't real market-- to walk away.
The NYC seawall depicted in The Expanse seems pretty plausible, it's such a dense area with so many people and so much income. And the seawall isn't really any different from the existing waterfront, so NYC remains recognizably NYC.
Florida though, everything is sprawling, there's no small area you could actually wall off. And the whole point of Florida is living near the beach, not concrete canyons.
You can't fix flooding in south Florida with seawalls or levees, because the bedrock is porous limestone: if there's too much water, it literally comes up through the ground. You can't pump floodwater away either, for the same reason.
Construction (both infrastructure and housing) faces a shortage of low single digit million workers nationally. Now, account for deportations of workers in those industries. Account for 4M Boomers retiring per year. Account for an annual year over year decline in prime working age participation due to declining total fertility rates. Who is going to do this actual megaproject engineering and construction work? Print or borrow all the fiat you want, there aren't enough people for the body of work to be done.
Residents of Florida are already waiting months or over a year sometimes to get a roof replaced, because there are not enough workers.
‘The industry is in a crisis:’ Construction worker shortage delaying projects, driving up costs, experts say - https://www.clickorlando.com/news/local/2025/02/24/the-indus... - February 24th, 2025 ("Immigrants account for 31% of all workers in construction trades across the country. In Florida, an estimated 38% of construction workers are foreign-born.")
Miami is 'ground zero' for climate risk. People are moving to the area and building there anyway - https://www.cnbc.com/2024/04/26/miami-is-ground-zero-for-cli... - April 26th, 2024 ("By 2060, about 60% of Miami-Dade County will be submerged, estimates Harold Wanless, a professor of geography and sustainable development at the University of Miami." ... "The trend shows how many Americans are ultimately willing to overlook environmental risks, even though most acknowledge its presence — a choice that could later devastate them financially.")
Climate Costs in 2040: Florida - https://www.climatecosts2040.org/files/state/FL.pdf (9,243 miles of seawall are needed. Florida has the highest cost of building seawalls. 23 Florida counties
face at least $1 Billion expenditures. 24 municipalities are up against bills of over $100,000 per person)
Well-off, retired Boomers still have enormous political power in the USA, and have a history of voting to point the money funnel at themselves. If it's a choice between a stable, sustainable economy for everyone vs. a few years of nice retirement in Florida for them, they will vote to throw the next 5 generations under the bus to give them a few more years of living in comfort and leisure.
~2M voters 55+ die every year, ~5k per day. Millenials overtook Boomers as the largest generation circa 2019. How you push the olds in power out faster I leave to be solved for by others.
