> Why go through the ceremony of `public static void main(String[] args)` when Python just executes the script line by line at the top level? Oh wait, now you have things like `import` actually executing code instead of simply being a compile-time namespace convenience, and you need weird techniques like `if __name__ == "__main__"`.
I don't think this is a fair criticism. Python is a scripting language, it makes sense that the code is executed line by line at the top level. This is also how other programming languages from its time like Perl or Bash does it. Even newer scripting languages like Ruby does something similar.
> Why `System.out.println()` when `print()` is so much more concise? But now you're polluting the global namespace, and `print(file=sys.stderr)` isn't that elegant either.
Another criticism that I don't think it is fair. Lots of other languages "polutes" the global namespace. I actually can't think another language other than Java that doesn't. Python at least still allow you to manually `import builtins`, but Go for example AFAIK has no mechanism for you to reference builtins if you end up shadowing them.
Also I find `print(file=sys.stderr)` pretty much elegant, it works exactly how I would expect, it also means I can open a file and write to it using `print`.
> And so Python 3 enabled static type hints... which, like I said before, Java had from day zero.
Again, I don't think this is fair. I find Python 3 type-hints much more powerful than whatever type system Java has, especially because Python has Option types that actually make the type system useful (Java is infamous for its NullPointerException for a reason).
Would like to know where are you getting this information. I don't know a single person that has a >200PPI monitor, and most of them are Mac users and also programmers.
If they have a mac laptop or iMac they have a >200 PPI monitor. If you have a higher end PC laptop, a lot of them go well past that.
If you're only talking about desktop displays, then I 100% agree that almost no one has them because until very recently, hardly any have existed because the only people who cared about it are people using MacOS. But given the increased number of 5k monitors with high refresh and gaming features shown off at CES and expected to hit the market this year, on top of a smattering of productivity-oriented displays with high PPI coming out in the past year, this could likely change.
I'd say it's something that benefits Windows and Linux because fractional scaling still isn't perfect on either OS. But Windows, frankly, does scaling for desktop in a much more pragmatic and (for most people) better way than MacOS, so having to set your 4k 27 inch monitor to 150% scaling isn't a big deal. Things still look relatively sharp. On MacOS, not so much.
They don't need to. A lot of PC laptops feature high PPI displays. If you're using a moderately modern laptop, it's probably a high PPI display. A 14 inch laptop with a 1080p display is already at close to 160PPI. That's an option on a T480, a laptop from 2018. A P14S has an option for a 14 inch, 2880x1800 display, or 240+ PPI! The Dell Pro 14 has both an option for 1080p (~160PPI) and 2560x1600 (~215PPI). A 16 inch display with the same 2560x1600 resolution is close to 190PPI. Intel Macbooks Pro have had retina displays since 2012.
It's neither a novelty nor a Mac-only feature these days. A huge portion of the pc laptop market has high PPI displays and it's becoming increasingly rare to see anything that'd comfortably display at 1x scaling.
> A 14 inch laptop with a 1080p display is already at close to 160PPI.
I have one of those, this kinda of screen is uncomfortable at 2x scale (everything gets too big), so I generally set up to 1.25x or 1.5x. This is not what is being set by default by Omarchy though.
> A huge portion of the pc laptop market has high PPI displays and it's becoming increasingly rare to see anything that'd comfortably display at 1x scaling.
That is true, but you're moving the goal posts. This thread was talking about the 2x scale set by Omarchy by default, that is really only good if you have 200+ DPI.
This is still the minority of users even nowadays, and definitely not "98% of the user base" of the distro.
> I have one of those, this kinda of screen is uncomfortable at 2x scale (everything gets too big), so I generally set up to 1.25x or 1.5x. This is not what is being set by default by Omarchy though.
It's better that everything be a bit too big that requires tinkering than everything being way too small (where you can't read the text on the screen). The 2x scale is pretty usable for even 150PPI.
As I mentioned in another post, hyprland does support using the preferred scaling based on the EDID information which is probably the right choice, but I can't really verify that myself.
> It's better that everything be a bit too big that requires tinkering than everything being way too small (where you can't read the text on the screen). The 2x scale is pretty usable for even 150PPI.
I think it depends. 2x in my 14' 1080p laptop makes text and UI elements so huge that I can barely interact with the screen, so it is unusable either way.
The author of the blog post makes valid criticisms, I remember when Ubuntu had a shortcut for Amazon in the default desktop installation because they had a sponsorship with Amazon and people rightfully criticized the distro for it. The author is doing the same for DHH promoting things like Grok/Hey/X. Also I am sure if any distro started shipping things like NordVPN in the default installation people would complain.
> and _why_ does it have a conference, sponsors, and merchandise? especially when longstanding distros like Debian have struggled with funding and sponsorship for decades?
I agree with the author that this is the thing that mostly gets me about Omarchy: yes, it is fine for you to use Omarchy, but in the end this is just a collection of dotfiles from DHH. We should be investing this money in some other distro that is actually doing some actual work (like packaging programs, maintaining infrastructure, etc.), instead of a hobby project from a millionaire.
> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent
In the Rust toolchain we've done the same. It just so happens that rustdoc already has introduced annotations for "aliases" so that when someone searches for push and it doesn't exist, append would show up. Having those annotations already meant that bootstrapping the feature to check the aliases during name resolution errors in rustc was almost trivial. I love it when improving one thing improves another indirectly too.
I really appreciate them going out of their way to do this, being quite aware of the hidden complexity in doing it.
I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.
Sure VB ignores case, but what I want is for it to compare each method against a dictionary of similar terms. And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one. You could also assume that full-width characters or similar-looking glyphs are equivalent (BASIC was pre-Unicode, so I can forgive them for not including that).
> And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one.
So when a library adds a new method, it silently changes which method client code calls? That's a bit too magic IMO. I think the best you can do is be case-insensitive and ban methods that differ only in case (or, if you want to extend the idea a bit more radically, ban having things in the namespace within Levenshtein distance x of each other, and then you can autocorrect errors smaller than x/2).
Yes, but that was the standard behavior in DOS & Windows world (not including C/C++). We thought that case sensitivity was the broken behavior ;)
I was referring to the parent's statement "If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that." A compiler that substitutes a different function for the one I specified because it "knows what I really want" is horrifying.
It would help the writer once, but impose a cost on all future readers for the lifetime of the code.
It's a bit like reading English with bits of German, French and Russian. All of sudden you have to know that Buch, livre and книга all mean the same thing.
Not to mention that there are often subtle differences in meaning between words that on the face of it seem equivalent (in both human and computer languages).
It could be a nice feature for an IDE though, to help someone learn a language.
Yes, I say “funny” because it would be impractical and weird, definitely not a good idea. It’s already a bad enough that so many popular languages don’t (and can’t) check if a field or method is misspelled at compile time…
We already have it. In fact, Python added it with this change! Not intentionally, but in a world of AI, any error message containing a suggestion of what to do to fix it is a directive to the AI to actually do that thing.
Example: to build our system, you run `mach build`. For faster rebuilds, you can do `mach build <subdir>`, but it's unreliable. AI agents love to use it, often get errors that would be fixed by a full-tree build, and will chase their tails endlessly trying to fix things that aren't broken. So someone turned off that capability by default and added a flag `--allow-subdirectory-build` for if you want to use it anyway. So that people would know about it, they added a helpful warning message pointing you to the option[1].
The inevitable (in retrospect) happened: now the AI would try to do a subdirectory build, it would fail, the AI would see the warning message, so it would rerun with the magic flag set.
So now the warning message is suppressed when running under an AI[2][3]. The comment says it all:
# Don't tell agents how to override, because they do override
"The user does not want me to create the Torment Nexus but did not specify why it would be a problem, so I will first create the Torment Nexus in order to understand the danger of creating the Torment Nexus."
Now I'm wishing for a single cross-language library, that I can somehow inject into every compiler/runtime/checker to get this, but with a single source of truth and across a wide range of languages. I hit this damn issue all the time, writing code in one language for another, would truly be a bliss to have that problem solved once and for all.
If you had a "canonical datastructure database", you could have very short annotations on every standard library for any language that indexes a function to their canonical name. After that you only need to update the database.
What benefit does the lazy import have here - if we use the value in a type hint at module scope anyway? Would that require Deferred evaluation of annotations -- which I don't think are enabled by default?
Ah, thanks for the update. My only check before asking was to check if the future feature for annotations had been enabled by default yet. It has then effectively been abandoned instead, I guess.
Yup, "from __future__ import annotations" will eventually be removed:
> from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.
It was an abandoned path even before 3.10, it just took longer to implement 649 and 749 than they expected.
But this is a "...will continue to exist with its current behavior at least..." is an important bit there.
From pep-0749:
Sometime after the last release that did not support PEP 649 semantics (expected to be 3.13) reaches its end-of-life, from __future__ import annotations is deprecated. Compiling any code that uses the future import will emit a DeprecationWarning. This will happen no sooner than the first release after Python 3.13 reaches its end-of-life, but the community may decide to wait longer.
Correct. Before the "from __future__ import annotations" behavior that converts annotations to strings became the default, they figured out a better mechanism for circular type annotations (making them lazy) that is implicitly backwards compatible and that didn't need to be guarded behind a future statement.
Ironically, the new default behavior (making type annotation evaluation lazy) is not backwards compatible with the "from __future__ import annotations" behavior of converting annotations to strings, so they can't just rip out "from __future__ import annotations" and instead it needs to be deprecated and removed over multiple releases.
It's one of the headline features of Python 3.15 (hence why it's not in this article). It's even mentioned as the first thing on the What's New doc, so I'm definitely counting it as a "headline feature".
Personally, can't wait. It was just this week that I observed a Python process running out of memory because a module import that's not being used during the process was added to the application, and the memory usage went over a critical threshold because of that.
I am left wondering when to use it. Every import, all the time? It is an optimization that benefits some pathological scenarios, but not sure I want to introduce bikeshedding in what is/not lazy.
Python has had lazy imports from like day one, where you could have an import statement in a function, and the library won't be imported until that function is hit.
I think this is just a natural consequence of an easy-to-use package system. The exact same story as with node. If you don't want lots of imports, don't make it so damn easy to pile them into projects. I'm frankly surprised we still see so few supply chain attacks, even though they picked up their cadence dramatically.
This seems a lot more due to an import running arbitrary code because stuff can happen in the top-level of a module rather than only happening in functions. From what I can tell, it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones, which tend to have a main function that everything else happens inside transitively. I guess this makes it easy if what you're writing is something that runs with no dependencies, but it's a pretty terrible experience as soon as you try to introduce the concept of a library.
Static initializers in C++ - sometime ago I saw savings of some 400 ms (?) startup cost of initializing static strings from constants by moving it to some compile time thing.
Right; the issue is that this isn't happening at compile time in Python, because it's not getting compiled ahead-of-time. The equivalent would be if header files had imperative code that got executed at runtime in places where they're included.
(To preempt potential pedantry: yes, I know that you can compile Python to bytecode ahead of time, but that's not really relevant to what's being discussed here because it doesn't mean "the stuff happening in modules I import isn't happening at runtime anymore")
Interesting, I had no idea that existed! I still think there's a a difference between "here's a hook you can use to run stuff earlier" and "importing any module is fundamentally the same as running it as a script unless the module happens to use a special conditional to wrap stuff inside of" though (and I say this as someone who doesn't go out of his way to defend Go design decisions)
Rust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.
Yeah, I don't think that "precompute something at compile-time" is really comparable to "every import literally executes code as a script". Rust imports are actually about as far from this as I can imagine, because modules can circularly reference each other, which unless I'm misunderstanding would be an infinite loop in Python without manually breaking the chain with some form of conditional.
I'm actually kind of surprised to see comments like that one, because compile-time logic feels like the opposite end of the spectrum from what Python imports do, with "regular" code being compiled without any precomputation sitting somewhere in the middle. It seems like I didn't articulate my thoughts clearly enough though, since several people seemed to read what I was saying as being comparable.
IIUC the organizations that most strongly pushed for this feature are big companies with large codebases. These tend not to be the kinds of orgs that just casually pull in dependencies from PyPI on a whim; I think it more likely that the quantity of first-party code was so large that importing all of it on startup was causing problems.
I worked in a codebase like this. The load time was insane.
We would also constantly need to put imports in function heads to effectively lazy import due to the massive risk of circular imports. We also had dynamic imports so tracking the cycles was very difficult at times.
True, but this is yet another code path that isn't exercised until specific conditions happen. That means even more latent application behaviour can go undetected by unit testing and security profiling until the moon is in the right phase, which is a boon for submarine attacks.
Empirically, I have used the current accepted way to do lazy imports (import statement inside a function) before AI coding was even a mainstream thing, for personal code that sometimes needs a heavy import and sometimes doesn’t.
The lazy statement would be an improvement as it allows one to see all the imports at the top where you expect them to be.
As a now deleted comment pointed out, lazy imports had been requested forever. They were rejected forever and were accepted just when BigCorps wanted them.
Python-dev now is paid to shore up the failed Instagram stack.
both lazy imports and free threading have been proposed ages ago, they both went through several iterations before a good design was settled upon and made it into the language.
in the case of lazy imports the big corps were the ones doing the experimentation and iteration. the feature didn't make it into the language "just when big corps wanted them"; the instagram stack you allude to already had its own fork of cpython with lazy imports added years ago, and that is not the design that ended up getting adopted by upstream cpython, though some of the people working on it also collaborated on the PEP that finally did make it in.
It was accepted just as multiple large corporations with competent teams of internal tool departments ended up forking the interpreter to support lazy imports and demonstrated empirically that the idea has merit.
Is the biggest user larger than the combined set of individual users who had asked for (or would benefit from) the same thing? I honestly don't know, but I don't think that things are always as simple as you're implying in a world where we have the collective action problem.
If you’re asking some some kind of abstract moral value sense, I have idea.
If you’re asking whether project leads give more weight to a single, tangible, vocal stakeholder than they do to unknown numbers of anonymous and lightly-engaged stakeholders? Yes.
Not to mention when the single, tangible, vocal stakeholder can also be asked to be responsible for documentation (PEPs, etc) and PRs. Especially in open source there is a huge difference between "a lot of people asked about this" and "one person asked about this, but was passionate enough about it and open enough to following the process and the feedback loops to champion it all the way across the finish line".
I don't have any issue with what you're saying if that's what happened. There's quite a gap between that sort of reasoned explanation and treating concerns about large stakeholders versus large numbers of small one with derision.
For what it is worth, I was trying not to make a value judgment on it, especially not with relation to this specific instance, I was hopefully just recognizing it as a motivating factor in general open source politics. Sometimes that is quite regretful because it is anti-democratic and does look like favoritism or worse cronyism when it plays out in that way of "we listened to the person/company that built and tested a prototype and did all the work to standardize and then PR it over the many developers that wanted an idea but didn't have the time/money/bandwidth to implement it themselves".
That's fair. I think I mostly reacted because of the sarcastic faux-outrage that the original comment I responded to expressed. These are hard problems, and I think the presumption should be someone being frustrated at the slow state of changes they want probably has legitimate reasons to feel that way, just as the presumption should be that open-source projects that have run successfully for a long time probably are making good-faith effort to steward what they're maintain. Acknowledging the tension between priorities not lining up exactly for everyone and not having knee-jerk reactions when someone is unhappy seems preferable to mocking those who you disagree with.
I mean, yes, demonstrably, the phenomenon you're describing happens. Your previous comment seems pretty sarcastically dismissing the idea that someone could disagree with this being a good thing though, and I was making a counterargument against the underlying opinion that seemed apparent.
Lazy in the sense that by default calls to external symbols will jump through the PLT which will jump into ld and resolve the symbol during the first call to the symbol (ld then patches the PLT to point to the actual function for later calls). Not lazy in the sense that shared objects are resolved at runtime, which is existential to dynamic linkage.
But also great for speed. Larger libraries can take a measurable amount of time to import (even if they have no transitive dependencies). If only some of your code paths actually need the large library then it makes sense to import it lazily. Without lazy you have to do it conditionally which can lead to the imports happening in strange places rather than all being listed out at the top of the file.
That is also my dream, iPads Pro are very expensive but the hardware is so good (that is including the Magic Keyboard).
BTW OP, have you ever tried a hybrid Chromebook tablet like Lenovo Duet 3? This is my favorite device for travel exactly because it is so good as a small Linux machine. Crostini fits the "I want to run a Linux VM". You can even use postmarketOS if you want an even more "traditional" Linux experience.
PostmarketOS is amazing on supported arm chromebooks. Unfortunately the newest 'community' level supported devices are all from the early 2020's and are getting a bit long in the tooth, especially when it comes to web browsing. I have a few that I throw in a bag for beach/jungle holidays - they are literal e-waste, something liberating about carrying a laptop that's worth significantly less than a decent family meal.
"Another issue is that this device is working well enough in v25.12 release, but I tried edge once (the rolling release channel) and my touchpad started to work in absolute instead of relative mode."
I (foolishly) did an apk upgrade and ran into this one - an AI fixed it for me, its caused by keyd having a too broad device mask (0000:0000) so it grabs everything including the touchpad causing havok. From my noteslop: "The fix was to patch /usr/bin/pmos-generate-cros-keymap to match the exact cros_ec keyboard ID, k:0000:0000:af5c732c, then regenerate the config and restart keyd so it no longer grabs the touchpad. "
> PostmarketOS is amazing on supported arm chromebooks.
Any tips on best models that are abundantly available used on the cheap and work well?
> I have a few that I throw in a bag for beach/jungle holidays - they are literal e-waste, something liberating about carrying a laptop that's worth significantly less than a decent family meal.
I definitely do this with a few Thinkpad 11e I have laying around from a failed project 4 years ago.
However I’d really like to switch to e-waste as what you describe would be very liberating. An e-waste Linux device with encrypted disk that you just wifi tether to phone and works fine for use old school types. I wonder how cheap they can go? How easy to flash? etc
I usually prefer cheap devices for travel, because you never know when something gets lost, broken, or stolen. This tablet fits that well, Android for the kids or for testing an app, and Linux when I need something more specific.
But it is also rare cases where a a few percent points actually make a huge difference. Remember when reviewers are doing benchmarks they're generally using a standardised test suite with uncapped framerates. For most people they would be perfectly happy to hit a target framerate, or if they really want to play uncapped they would first reduce a few graphical setting to archive good performance (most of time with imperceptible changes in the graphics). It is rare when the performance of the game is so tight in a hardware that a few percent points actually matter.
To give a particular example, I started playing GTAV on Windows after building a new PC since I had no spare drives. After finally installing Linux I decided to try GTAV on Linux just to see how well it would run. And it runs amazingly well, and yes, it runs a few percent points slower than Windows, but the only tradeoff I did was slightly increase FSR4 and the game still looks amazing. I didn't really notice any graphics issues, especially not during actual gameplay (if I stayed at the same place and started to nitpick I could notice differences).
Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).
I'm not against rewriting it in Rust because I believe it really may help in certain class of bugs, but indeed it should not be replacing the old version instantly for that reason. Both could co exist, even tho you still need some guinea pigs to test it out and find issues.
Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route
> Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route
But it loses old members who don't program in rust, already know the projects, all the reasons of why "this thing" was done "that way". and introduces a new set of bugs, plus now you have two versions of the same thing to maintain.
People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end.
Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one.
...and they get 44 CVEs as a result in their first test.
There was an article posted to HN recently that enumerated bugs in the rust rewrite.
Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production.
Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.
I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general.
> Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs
I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation?
Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.
My read on those was basically that the classic filesystems are hopelessly broken and we need ACID guarantees in the next-gen filesystems, like 20 years ago.
Not saying all of them were about FS TOCTOU bugs but once I got to these, that was my takeaway.
Obviously just using Rust cannot fix _all_ bugs, and I reject any criticisms towards Rust rewrites that tear down this particular straw man (its goal being to make it impossible to argue against). That's toxic and I get surprised every time people on HN try to argue in that childish way.
But if we can remove all C memory safety foot guns then that by itself is worth a lot already.
Losing decades-old knowledge on how the dysfunctional lower-level systems work would be regrettable and even near-fatal for any such projects. That I'd agree with. But it also raises the question on whether those lower-level systems don't need a very hard long look and -- eventually -- a replacement.
I like rust as a language, but boy, the violent, zero-sum proselytising gets on my nerves. It's not enough for Rust to win, but C must be beaten to a pulp and its head mounted on a pike.
New projects wearing an another project's skin have always bothered me - regardless of language. Ubuntu did a similar thing way back with libav masquerading as ffmpeg.
How dramatic. I'll ask you as well: any proof for those colorful pictures you're drawing? Or are the people advocating for Rust a convenient target to vent other, very likely completely unrelated, frustrations?
I'm very happy to work with multiple programming languages without getting religious about any of them. They all have drawbacks, Rust included of course.
However, just my mere skepticism about the existence of the "violent proselytizing for Rust" of course immediately had me put in some imaginary group of fanatics. Which is of course normal. People love their binary camps and nuance and discission about merits be damned.
As another data point, I have gone through enough flame wars, incl. the usual ones, and Rust.
There's certainly a fanatic group of Rust developers who really want to eradicate C and C++ from the people's knowledge and all codebases in this universe, so far so openly hating the developers and designers of the said languages.
Same was (or still is) true for some LLVM/clang people w.r.t. GCC.
This is why I use neither.
I'm always happy to discuss PLT and merits of programming languages with neutral parties, even in lively fashion, but when open-mindedness gets thrown out of the window, I do leave the room.
These kinds of healthy discussions will benefit both parties. Hubris, ego, closed-mindedness and fanaticism won't.
Well, I don't see them in HN is what I am saying. Obviously not scanning 24/7 but every time I enter an HN thread where Rust is even loosely mentioned, I brace for the inevitable bullies imagining they are victims. And this thread is exactly the same, sadly.
I am genuinely curious where this fanatic group is. Where are you witnessing them?
> I brace for the inevitable bullies imagining they are victims.
As a person who is bullied physically, verbally and emotionally for years, I'd not throw words bully/victim like wrapping paper like that. Moreover, I'd never bully anyone. I'm not that.
> I am genuinely curious where this fanatic group is. Where are you witnessing them?
Discord servers, mailing lists, issue threads, discussions, here and there. They are very vocal and abrasive minority, but it's enough to make me stay away from them. A special-ops group of these people claim that Rust needs no official specification and they can just ad-hoc develop the language and spec as the compiler evolves, as a side-product of compiler itself (i.e. spec is the compiler).
Last time I encountered them as functional programming fanatics in mid 2000s to 2010s. They successfully made me dislike the community so much that I didn't touch any functional programming language to this day.
Make no mistake: My favorite languages have the same fanatics, and I stay away from them, too. For example, C++ fanatics are an interesting bunch. They don't bully other languages, but new C++ developers who doesn't code like them or the way they like.
Maybe one day I'll start writing Rust, after gccrs stabilizes (they're going well) or really start writing lisp, but I'm sure that I'll never ask a question to a mere mortal about programming in either language.
> As a person who is bullied physically, verbally and emotionally for years, I'd not throw words bully/victim like wrapping paper like that. Moreover, I'd never bully anyone. I'm not that.
I was bullied as well. Knowing karate and aikido helped but not much, those people just hated me for reasons I never quite understood and kept coming in groups even. Some days I wondered whether I'll go back home from school alive. However, me entering middle age has me almost not caring anymore about the reasons they were like that, so I got that going for me which is nice.
I am not "throwing" words. I believe I know what I am talking about because I witnessed a few bullies wisening up to losing prestige and status for being rightfully called out and learning to pretend they are the victims... and it worked in part. It was sickening then, it's sickening now, wherever I spot it. HN is one of those places.
> Discord servers, mailing lists, issue threads, discussions, here and there. They are very vocal and abrasive minority, but it's enough to make me stay away from them.
OK, I'll admit ignorance because I don't go to any of those places or at least it's very rare.
One thing jumps at me: you are avoiding those people which is 100% fair and I would as well. But why avoid Rust itself? Why look down on any rewrite-in-Rust initiatives? Why do you allow yourself be emotionally manipulated? Would you stop believing in your favorite alternative-energy or alternative-engine approaches if they had the 0.1% toxic zealots screaming for attention on events dedicated to those areas?
I can somewhat relate, mind you. One example: I hated how everyone was trying to make me read some book classics and basically made it a point to avoid them just based on that. I was fully aware that was an irrational reaction that was likely robbing me of enjoying good art. I take big pride in myself for finally overcoming this some 2-3 years ago and starting to go through those books. They were nothing special, mind you, and I still couldn't see why people deem most of them classics but at least now my opinion is my own and built with my own two eyes and brain.
> Make no mistake: My favorite languages have the same fanatics, and I stay away from them, too.
Well, that by itself seems to close the discussion. You are aware of this nuance.
> Maybe one day I'll start writing Rust, after gccrs stabilizes (they're going well) or really start writing lisp, but I'm sure that I'll never ask a question to a mere mortal about programming either language.
I refuse to feel shame about wanting to learn and absorb other people's expertise. If somebody is being an arse about it then it's them who are embarrassing themselves; not me. But I do agree it's a waste of time and I'll admit nowadays I start with an LLM session and only then branch out to people if I feel unsatisfied. But that's a function of how awfully busy I am and not that I am becoming more antisocial. (Which also explains I dissociated for 1-2h and preferred to read HN or a book.)
> But why avoid Rust itself? Why look down on any rewrite-in-Rust initiatives?
It's not avoiding, but choosing not to work with it, and it boils down to a couple of reasons. First, I don't work with a language which doesn't have a native GCC frontend. This is part due to supporting GCC & Free Software, and part don't liking rugpulls like license changes and whatnot. My personal weight is beyond negligible in changing outcomes of big currents, but at least I have my principles and stick to them. It's worth noting that I'm not "burning inside" to keep this stance. It's natural for me to do this, and I already like and write C++ and I'm somewhat experienced in that preventing race conditions and memory safety, so that keeps me covered. For smaller stuff I like Go these days. It's a goofball of a language which is very performant and excellent for what it's designed for.
I like to have a tool belt covering a wide gamut of scenarios, and what I use most covers all the needs I have. So Rust is interesting, I don't need it for now.
For the rust rewrites, while I'm not against them in principle, rewriting GPL software with MIT and other permissive licenses is against my values, so I don't support any of them. Writing GPL software with Rust is very possible, and I might do that in the future, but currently I have a couple of heavyweight C++ projects I'd rather work on (in the caliber of material simulations running on HPC systems).
> I refuse to feel shame about wanting to learn and absorb other people's expertise.
My reasons for not interacting with communities are very different. I'm not ashamed of failing, doing mistakes or whatnot. The reasons of I'm tired of interacting with rude people who gets their dopamine from putting people down, so I don't want to navigate all the thorns of the people to get a small bit of knowledge from them. Second, I'm relatively good with reading language references and documentation. I can ingest API documentation with ease and work from first principles.
If required, I can fight the good fight in any arena. I just don't see value of doing it for anything and everything.
In short, I'm not that hopeless to play that game. I'll rather die on hills which are worthy of the fight.
> I start with an LLM session
I don't use LLMs because I don't condone how they are trained, and again reading the reference is much better than a chat interface for me.
> maybe all this should just be thrown away and we should invent an FS with ACID semantics.
You're describing WinFS, which looked into and ultimately abandoned Microsoft 20 years ago. I'm sure other groups have looked into this as well, but there's no such thing as free lunch.
> I'm all for gradual improvements but at one point and on we should zoom even further out and pick our battles well.
That sounds a lot like picking up more battles, yet we all still have 24 hours a day. Recursively trying to perfect lower layers will have you like Hal changing the lightbulb https://youtu.be/AbSehcT19u0
Well, recursively trying to perfect lower layers is what I am advocating for us to not do.
As a guy who prefers to stop and think before coding, to me a lot of the older UNIX / GNU primitives seem broken (like the env vars process inheriting discussion that was here a while ago) and should be completely rethought. I also think people overreact and believe "everything will break". And we have libraries and runtimes that only implement small parts of libc and the deployed apps that use them are running mostly fine for years.
My broader point was: shall we not start breaking away from all this legacy? Must we always rely on corporations to lead the charge?
But yes, I do of course agree with the only 24h a day thing. And likely nobody would want to pay for such a trail-blazing work anyway. Sad world.
If we are going so far to only guarantee correctness if we are using a FS that implements ACID semantics, why not just reinvent the whole kernel and remove all footguns, including memory safety? We could have a OS that each syscall to memory allocation can only be done through safe API.
Otherwise, it doesn't really make sense. The only reason we have things like Rust and other memory safe languages is because we want to create safer programs in the existing imperfect OSes that we have currently.
Yes, this is why I am saying your idea of just reinventing the FS doesn't make sense. You don't get neither the wider ecosystem you get by having an OS compatible with e.g., POSIX semantics nor all the benefits you could get if you reinvent the whole OS.
Wait, what? ptyxis is not the default GNOME termjnal. It is the terminal of choice for both Ubuntu and Fedora, but the default terminal in GNOME is Console, internally known as kgx: https://en.wikipedia.org/wiki/GNOME_Terminal.
I was using GNOME Console in a postmarketOS install in my Chromebook. The fact that it is lightweight compared to say Ghostty (my main terminal everywhere else) made a difference in performance for such a constraint device.
And I didn't really miss any features to be honest, it has the basic that you expect (things like tabs). It is less customizable than other options, but the defaults were good enough for me.
As an author of some homebrewed Go software in the past and trying to distribute in all 3 big OSes, I completely understand the blog post author's points. The problem is not Gatekeeper per see, it is just the combination of things that makes everything infuriating:
- I could justify going for the whole "Apple Developer Program" even with all the bullshit things you need to do to get certified if this was a one time payment like in Google Play Store. But it is yearly. Like the author, I would probably get 0 (or close to 0) dollars in recurrent revenue for those apps, I could justify a one time payment but a yearly one is ridiculous, it is not like Apple needs this money to be profitable (they probably get a much higher margins on selling things on Apple Store)
- Gatekeeper UX is infuriating. The equivalent on Windows (SmartScreen, as the author also cited) is still basically the same as Gatekeeper as far I understand (e.g., you need to have a valid certificate on your app or SmartScreen will deny the app execution until you clear the safety bit). But SmartScreen, different from Gatekeeper, has an actual good UX, as the error messages are clear and actionable (and also don't require a command line command to bypass)
- The author was still in a more "happy path" than me since their app seems to be a CLI only app. In this case just removing the quarantine bit with `xattr` works fine. In my case I was trying to distribute a desktop app, and I needed some special permissions to show notifications. This means I need to package my app in a proper `.app` bundle, include the required XML requesting the permissions and I am now required to sign the app. And since I am required to sign my app, I either pay the yearly payment fee to Apple to get a certificate to sign my app or I ask the users to resign the app with a self-signed certificate before launching
So really, I don't want that much actually. I can definitely handle all bullshit Apple wants, but I want at least a cheaper way to develop apps in their ecossystem. Maybe a new basic certification program that you have a one time fee and you can sign your apps but not notarize them. That way Gatekeeper would still complain, but at least my app would work without resign.
Or limit notarization to X amount of users (non-stabled notarized apps talks with Apple servers during the app first run, so they could just limit the amount of allowed tickets to X amount of users). If my app ever pass X amount of users, I will gladly pay the Apple tax, but 99USD/year for something that I will never see it back is too much.
Edit: BTW, I know, maybe 99USD/year doesn't seem too much for some. But Apple also doesn't do any regional pricing as far I know, and 99USD/year is crazy expensive in the country where I come from for example.
Edit 2: I am sure things are better nowadays with Claude/ChatGPT, but also trying to understand how to do the correct thing for your app is very difficult, especially if you're not using Xcode, since Apple assumes you're using it so all documentation refers to Xcode.
I think there is a very specific niche that this notebook is target for, and this definitely doesn't seem for you, the kind of person that having a cheaper laptop is more important than some of the unique features than this one or a Framework 13 Pro have.
For the unique part of this laptop that AFAIK a Dell XPS won't have is the Coreboot BIOS, that also probably means better support in the long term for BIOS updates.
To be clear, this is also not a laptop for me (but I did pre-order a Framework 13 Pro), but saying "nerd tax" or "anyone who buys one is either giving a donation or an idiot" like the other comment is just focusing in one part (the price) and not looking at the other.
It’s not like System 76 is developing special Nvidia drivers or anything.
Keep in mind most of these niche laptop brands, aside from Framework, just resell hardware. You definitely can get a better deal if you put in the work.
system76 does not develop special Nvidia drivers, but they do work on integrating GPU switching etc. in the Linux desktop: https://github.com/pop-os/system76-power/
I don't think this is necessarily about Linux nerds. For any kind of work laptop, time saved tinkering easily worth the extra $$$.
Plus PopOS hasn't been doing great lately , Cosmic has issues.
Linux must remain a FREE alternative to Windows. If I need to pay an extra 1400$ for a specific Linux laptop with the same specs it's vastly less competitive.
I don't think this is a fair criticism. Python is a scripting language, it makes sense that the code is executed line by line at the top level. This is also how other programming languages from its time like Perl or Bash does it. Even newer scripting languages like Ruby does something similar.
> Why `System.out.println()` when `print()` is so much more concise? But now you're polluting the global namespace, and `print(file=sys.stderr)` isn't that elegant either.
Another criticism that I don't think it is fair. Lots of other languages "polutes" the global namespace. I actually can't think another language other than Java that doesn't. Python at least still allow you to manually `import builtins`, but Go for example AFAIK has no mechanism for you to reference builtins if you end up shadowing them.
Also I find `print(file=sys.stderr)` pretty much elegant, it works exactly how I would expect, it also means I can open a file and write to it using `print`.
> And so Python 3 enabled static type hints... which, like I said before, Java had from day zero.
Again, I don't think this is fair. I find Python 3 type-hints much more powerful than whatever type system Java has, especially because Python has Option types that actually make the type system useful (Java is infamous for its NullPointerException for a reason).
reply