HNHacker News
TopNewBestAskShowJobs

troad

3,837 karma · joined January 13, 2022

Goodbye.
submissionscomments
troad··on Time to talk about my writerdeck
It's interesting to me how few people seem willing to just turn off notifications.

I'm all on board with setting up a retro machine for fun, but if one wants to focus on writing, there are ways to achieve this that don't require the sacrifice of good font rendering, comfortable colours, etc.

The fact that the Music app notifies you of the new song is not some immovable law of nature...

troad··on .NET (OK, C#) finally gets union types
But no one is actually confused. You yourself understand what the author meant, from your comments. Everyone here understands what he meant.

It's neither ambiguous nor confusing to use the word union in CS. The only person who's making it so is you, by introducing semi-unrelated concepts from set theory that happen to have the same name as the established CS concept.

Why stop there? Maybe the author meant the Union, as in the United States? Itself quite ambiguous - does he mean the United States of Mexico, or the United States of the Ionian Islands? Is C# getting Corfu? Corfu dot net? :P

troad··on .NET (OK, C#) finally gets union types
> Maybe they are implemented similarly under the hood

It's hard to know what to say to this. Tagged unions are not tagged unions, even if they are literal tagged unions? What?

I reiterate what I said in my previous comment, you're not using the ordinary definition of the term union, and this is causing confusion. A union may or may not be a "union" as understood within various academic type theories, that really depends on how any given theory defines that word, which can be any way it wants. But a union is a CS concept with a clearly understood meaning, and when used without added context to suggest it is to be interpreted in some theoretical way, it is understood in that ordinary way.

OP's article is clearly using 'union' to mean tagged unions - he even shows off their implementation, with a tag. The author assumes that his audience will understand what he's talking about when he uses the word union, and it's not causing anyone trouble in this comments section. The fact that alternative definitions within various theoretical paradigms is very nice, bless their hearts, but not really relevant.

You may prefer other definitions to the usual CS definition, that's certainly your prerogative, but - again - that's hardly grounds for taking an article and comment section that's using the commonplace meaning, and appearing to lecture others for failing to adhere to your idiosyncratic standards for what a union must be.

troad··on .NET (OK, C#) finally gets union types
> That's like saying Haskell is really an imperative language just because it's written in C

I honestly don't even remotely understand how you got to that from what I wrote.

Unions already have a definition. You cannot go around claiming that technically unions are not unions (and that "most people don't know" this), because theory X or Y overloads the term union to refer to some unrelated concept. That's fine and well and good, within that theory, but it does not displace the usual CS definition of union. It is a load-bearing definition.

A tagged union is so called because it is a union (overlapping memory) with a field (a tag) containing a discriminator (aka discriminated union). An untagged union is a union without this tag. These terms didn't come out of nowhere. They are transparent descriptors of what's happening.

It doesn't matter whether Haskell is implemented in C or Ruby, and it doesn't matter whether it's functional, object-oriented, or a DSL for modding Elden Ring, none of this changes what a union is. I'm very supportive of type theories exploring the option space for type constructs, but someone's going to have to implement these somehow. Such as with (tagged) unions. You know, that CS concept we have, with a settled and well understood meaning.

To be fair to you, I think you're letting a very narrow definition of 'union' shadow a much more usual and common definition of the word. And that's totally fine if that's the definition pertinent to you and your work, but if that's the case, maybe don't go around pontificating about how most people do not understand unions?

troad··on Python 3.15: features that didn't make the headlines
Good observations.

Judging by the community around Go, I also wonder if there's not an element of baby JS devs upskilling to Go, without yet having picked up a wider perspective. The performative aversion to DX could be explained if one sees Go as the opposite swing of the pendulum to JS and its excessive reliance on libraries, sugar, etc.

troad··on On The <dl> (2021)
> <br/>

Only occasionally? I will die on this hill.

Yes yes, someone is about to tell me that Opera running on a PS Vita with the language set to Basque will display those incorrectly. That ISO 714-4BΔ-鸡冠 defines them as undefined, and prohibits them within eight clock ticks of C sequence points. That Apple charges an extra 1% app store commission for them (except where prohibited by court injunction).

Call it a concession to my sanity. A song of saner days.

troad··on Green card seekers must leave U.S. to apply, Trump administration says
I've always thought I'd end up in the US at some point, but as someone who prefers to make things rather than spend years at some faceless megacorp (writing up cover sheets for TPS reports), it never seemed hugely viable, even starting out from a first-world country.

Now it doesn't seem viable at all. Meanwhile, anyone who shows up illegally is merely "undocumented", and half of US politics consists in coddling them (the other half in enforcing existing immigration laws capriciously). Even for someone who's quite pro-immigration like myself, that's just bizarre. There's no way this is a functional system.

Most of the people in my circles don't want to go to the US anymore. I suppose I'll ride it out and see what comes next (after 2028 at minimum). If I ever make it, I'll have spent many of my productive years outside the US, since I wasn't welcome during those. Weird system.

troad··on .NET (OK, C#) finally gets union types
Underlyingly, all unions are the same concept, exposed by C's `union` keyword, namely overlapping memory (as opposed to `struct`s, which are sequential memory). You can add a discriminator tag to your unions, your call. If it is impossible for there to be ambiguity (e.g. you track the state somewhere else, and you're dealing with a large array), it may be redundant / memory inefficient to tag every item.

Having these tags be a language construct is just a DX feature on top of unions. A very handy one, but it doesn't make tagged and untagged unions spring from different theoretical universes. I enjoy the ADT / set-theoretic debate as much as the next PL nerd, but theory ought to conform to reality, not vice versa.

troad··on .NET (OK, C#) finally gets union types
String literal typing appears to be a common feature of type systems bolted onto dynamic languages:

    # Python
    MyStringBool = Literal("Yes") | Literal("No")

    // TypeScript
    type MyStringBool = "Yes" | "No"
I assume it exists to compensate for the previous lack of typing, and consequent likelihood of ersatz typing via strings.

It would seem pretty unnecessary in Haskell, where you can just define whatever types you want without involving strings at all:

    data MyBool = Yes | No
Of course you'd need a trivial parser, though this is probably a good idea for any string type:

    parseMyBool :: String -> MyBool 
    parseMyBool "Yes" = Yes
    parseMyBool "No" = No
    parseMyBool _ = error "..."
Interestingly, dynamic languages which make use of symbols (Ruby, Elixir, Common Lisp) probably fall closer to Haskell than Python or TS. Elixir example:

    @type my_bool() :: :yes | :no

    @spec parse_my_bool(String.t()) :: my_bool()
    def parse_my_bool("Yes"), do: :yes
    def parse_my_bool("No"), do: :no
    def parse_my_bool(_), do: throw("...")
Where :yes and :no are memory-efficient symbols, not strings.
troad··on We're testing new ad formats in Search and expanding our Direct Offers pilot
Relatedly, it doesn't help that 'Kagi' sounds like poop in half of Europe.
troad··on Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised
> Unless you make all the IT jobs a regulated profession and enforce significant yearly recertification, the mediocres will dominate.

This would merely optimise the industry for people who are good at wiggling through bureaucratic hurdles. It would entrench mediocrity while lopping off the extreme ends of the skill distribution - on both ends.

troad··on No way to parse integers in C (2022)
Definitely! An interesting distinction. I spend much of my time in the BEAM these days, where "let it crash" is a common practice with a very distinct meaning (green threads under supervisor trees, etc). Different strokes.
troad··on Python 3.15: features that didn't make the headlines
I don't think I will ever understand the culture of Go. The syntax of a very low level language (needlessly verbose), combined with the performance of a very high level language (needlessly slow), with a bizarre aversion to any DX conveniences (pattern matching, ORMs, etc). If you're already giving up all that performance, why would you not take the extra convenience?

Not to mention that the demographic using Go - a simplistic-by-design, relatively slow GC'd language - is the last group I'd expect to get elitist about ORMs and demand every pound of performance from rawdogging SQL. That's a valid stance, but then why are you writing Go??! The common thread appears to be picking the most masochistic solution possible.

I can usually see the value of different languages for different use cases, but Go flummoxes me.

troad··on No way to parse integers in C (2022)
Interesting difference in nomenclature. For me, "crash" absolutely includes intentional early termination. A Rust panic, for example.

I think that that's by far the dominant usage of crash. It would surprise me if someone used the word crash but intended to exclude panics, etc.

troad··on GitHub is investigating unauthorized access to their internal repositories
I moved to neovim (stable) with as few extensions as possible, and those I've pinned to some geriatric version.

I don't even know what the plugin upgrade command is, and I don't plan to find out. Recommended.

troad··on Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised
Hardly a factor when you're (deliberately) months behind.
troad··on Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised
I came from systems programming, so I think half of what happens in JS is nuts.
troad··on Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised
Not likely to be a major risk if you update every few months, to some major version that's already over a month old.
troad··on Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised
Only the frontend, which is already untrusted. Any risk would be restricted to individual users who used the compromised frontend to communicate something sensitive, and while that's not great, it is significantly better than the backend being compromised. A very significant reduction in blast radius.

Funnily enough, I don't actually think I do serve third party JS, though. Don't serve ads, don't use external telemetry, don't use JS CDNs. I don't think you have to go quite as far as I do, though - I imagine if your ads are Google AdSense or something, you're probably going to be fine.

troad··on Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised
I'm very glad I never bought into fullstack JS/TS.

My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few times a year, if that.

Combine with obvious basic security practices like pnpm cooldowns + no build scripts. When you upgrade a few times a year, and frontend vulns don't matter, there's really no limit to the cooldown you can set. 60 days, why not.

troad··on We let AIs run radio stations
> After 96 hours of its launch, DJ Gemini was already grasping for content. It landed on discussing every mass historical tragedy that had ever happened, and subsequently pairing these short story horrific broadcasts with the most ironic song choices

I rarely burst out laughing at HN links. This is amazing.

troad··on I hate soldering
I think there's points on either side here. It's certainly possible to ask in good faith, and it's certainly possible to ask in bad faith. But that goes for most questions, really.

I would gently discourage you from assuming bad faith, which is what you're doing when you flag the whole question as rude.

> possibly a microaggression/microinsult because it implies that their dialect is somehow "lesser" than the one you're comparing it to.

I think with these assumptions you're implicitly reinforcing the negative self-perception that many people who speak dialects have, whereby their dialects are something to be reduced beyond perceptibility, and if ever they are noticed, it is an embarrassing social failure.

Silence is not the way to elevate dialects. There is no way to deconstruct the negative baggage around dialects unless smart, self-confident people take pride in their dialects. "Don't Ask Don't Tell" is hardly the way to achieve this. :)

If someone is asked about their dialect, it is generally in good faith. I would not expect them to talk about L-vocalisation around back vowels, but it is a wonderful invitation for reminiscences about their hometown, an anecdote about how their mammy used to talk, etc. This is good. This allows the two parties to bond over some shared human experiences, but it importantly also humanises the dialect.

Assuming the question is an attack, on the other hand, is a highway to responding as though it were an attack, which is guaranteed to result in confrontation. This is bad. The only stereotypes this could possibly reinforce are negative ones.

troad··on ABC News has taken all FiveThirtyEight articles offline
I think most people genuinely read "49% chance" as some kind of ironclad prediction of winning 49 out of 100 seats, and therefore losing.

That's why people get all weird about probabilities flipping from 49% to 51%, and not at all interested in - say - a probability going from 60% to 90%.

troad··on Rewrite Bun in Rust has been merged
Interesting. Where I am, both six and eight digit phone numbers are valid, but seven digit ones are not, and yet that's the only one that gets linked for me. US assumptions bleeding through, I assume.
troad··on The Future of Obsidian Plugins
You're right! I apologise for the tactlessness. I would find it extremely disheartening to hear what I said to you. There was a better, gentler way to express my overall concerns, and I owed it to you to take that extra minute to do so. Not only would it have avoided needless upset, but it would have been more effective in getting those concerns across. Mea culpa.
troad··on Leaving GitHub for Forgejo
Issue trackers and discussions on FOSS projects are effectively a public forum, and on any public forum people start building brands and identities. Add comment reactions and GitHub stars into the mix and you have a vicarious karma system whereby people's projects jostle in popularity and people try to build reputations. For some people, GitHub is more of a social network than a VCS tool.

GitHub is also somewhat entangled with junior hiring in compsci, meaning there's a tangible economic incentive in building a hireable profile that a recruiter might like. (Or at least that is a widespread belief.)

None of this has much to do with git, the VCS tool, nor is GH-as-a-social-network objectively very important, but it's natural to place outsized importance on a community in which one is active, and there's a significant overlap in the HN commentariat and GH users. So you'll probably hear more about the claimed social utility of GH here than in the real world.

Hope this helps clarify what people are talking about. :)

troad··on Leaving GitHub for Forgejo
To be generous to OP, none of this is intrinsic to FOSS.

I write a library. I put it up online, for other people to use, if they like. At what point did I assume any responsibility to play nice with others? Or work with others at all?

There's FOSS licenses, and then there's the social expectations around collaborative online development, and the latter is nowhere implied in the former.

FOSS was not historically weighed down with all these social expectations. Forking was not seen as some community failure, but the basic purpose of FOSS. Sites like GitHub were a major part of this shift.

troad··on The Future of Obsidian Plugins
FWIW, I think you're twisting my words and putting up strawman arguments too.

Permissions are not a panacea, but it is a very rare plugin indeed that will need to run unsandboxed executable code with full disk and network access. Currently, that's every plugin. The work of the vast bulk of Obsidian plugins could be achieved with much narrower permissions than this. You're letting the perfect be the enemy of the good if you're letting the 0.1% be a blocker for improving security around the remaining 99.9%.

I use and pay for Obsidian. I very much look forward to a future where plugins are something that someone could confidently run. I don't think we're there yet, and that's all my stance comes down to. I am happy you're taking the plugin situation seriously and I wish you the best of luck.

On an interpersonal note, I was really put off by the tone of the response ("Obsidian isn't for you", "clearly, you didn't read the post", etc) and the strawman arguments laced throughout (how can you be against code review? Unlike you, we believe in software freedom... ). I'm not sure what comments like "Obsidian isn't for you" were supposed to achieve, but I found that comment quite galling. To the extent my response to that was a little fiery, I apologise. I don't think either of us came at this discussion in the most constructive way. I can only own my part of that.

Good luck with the plugin improvement roadmap! Genuinely. I intend to remain a paying customer, despite - uh - the CEO's opposition. :P

troad··on The Future of Obsidian Plugins
I'm a programmer, I have zero fear of programmable tools, and it's a clumsy attempt to divert from my point to suggest I do.

You're creating a false dichotomy. A well designed sandbox with accurate permissions is HOW a person "understands and accepts risks". A system whereby a plugin pinky-promises one thing, and then does another, precludes informed consent.

Obsidian tacitly endorses this ecosystem because it is profitable for Obsidian to point to plugins for missing base functionality, and then throw up its hands and pretend like it's not their problem when something inevitably goes pear-shaped. That's how we end up with "warning screens" that in fact encourage the user to press "Yes". (And, as in the recent security incident, Obsidian then disclaims any responsibility when the user does click Yes, despite the heavy encouragement by Obsidian.)

Not hard to see why a business would act this way - all profits are ours and all risks are someone else's - but spare me the faux moralising about software freedom.

It is surreal to claim that a well defined sandbox with accurately described permissions is somehow against freedom. It would be a far more robust, trustworthy and empowering plugin ecosystem than the one Obsidian has now.

> Obsidian is not for you

Ooft.

And a lot of other HN commenters and other tech-savvy users with my exact concerns, apparently.

Somehow, most other software doesn't have this recurrent problem of mainlining third party malware to their users. See you at the next Obsidian "security incident", I guess?

troad··on I hate soldering
There is absolutely nothing wrong with that question in Jamaica. You're needlessly (and somewhat bizarrely?) problematising a genuine interest in others.

What you're proposing appears to be some kind of conspiracy of silence where we all notice differences in speech but are forbidden to enquire about them, and I think that's utter hogwash.

> I can see the case where someone is so ignorant that they don't know the basics of how language dialects work

Having a degree in linguistics I would hazard a guess that I probably know more than the average person about how dialects work. I wholeheartedly endorse asking others about how they speak. People absolutely love talking about themselves and their culture, and good-natured interest in others engenders genuine human connection. (Not to mention better appreciation of the dialects themselves, which is a worthy goal unto itself!)

← PreviousPage 2 of 34Next →