mubou

Not a good look for Figma.

Q# docs: https://learn.microsoft.com/en-us/azure/quantum/qsharp-overv...

Playground/simulator: https://quantum.microsoft.com/en-us/tools/quantum-coding

Making people pay to download their own images they uploaded is pretty scummy. Were people actually using Flickr as cloud storage? They could have just put a captcha on downloads to solve that if so. It's not like the bandwidth cost of a full-size jpeg is that significant; this is 100% a cashgrab.

(Edit: I thought they meant like automated cloud storage, something that would obviously be a ToS violation, because as benoau pointed out, hosting your photos is literally the whole point of Flickr. Having the full-size original photo there was its selling point.)

I thought the whole point of the domain verification system was to not rely on checkmarks -- a system which has already been proven to be easily abused and not scale

Flagged, repost: https://news.ycombinator.com/item?id=43723661

I was making a comment about the current state of news sites, which it's clear from "the fucking article" that you agree with, so I don't understand why you're being rude.

No, I wish I could read it without two unrelated autoplaying videos covering my phone screen, leaving only two or three lines of visible text, followed by a popup to get me to subscribe suddenly appearing while I'm halfway through the article and then another one trying to stop me from closing the tab.

> Anyone sensible switched over to macOS already, especially software developers

Well if sgt says so, then it must be true!

Except it isn't, sorry. Both Windows and Linux (if you total the distros) are more popular among developers according to last year's SO survey:

https://survey.stackoverflow.co/2024/technology#1-operating-...

I'm glad that you've found an OS that suits you, but please don't speak for the rest of us, or call everyone who has different opinions from you "unsensible". (Personally, I find Mac really frickin annoying, but that's just, like, my opinion, man.)

File explorer. I put them in separate folders so their files aren't all jumbled together /s

Can you clarify what you mean by "manage projects"? If you mean issue tracking / notes, I sometimes use github issues, but most often I simply use a markdown file in the gitignored directory where I keep assets that shouldn't be checked in (psds, db backups, and so on). The mermaid extension for vscode makes it easy to throw together flowcharts in that same file. Sometimes I use google tasks for checklists, since my other todo's are in there too.

There's a whole series of these, including cryptography![0] Probably shouldn't be linking to a pirated book though. There are previews on Amazon[1], and on the US publisher's site you can read the entire chapter on digital logic from the Microprocessors book[2]. It's quite good.

[0]: https://nostarch.com/catalog/manga [1]: https://www.amazon.com/Manga-Guide-Databases-Mana-Takahashi/... [2]: https://nostarch.com/download/MangaGuidetoMicroprocessors_sa...

What are the legal consequences of this, if code containing IP/secrets was exfiltrated without consent? (Assuming the ToS doesn't simply allow them to do anything they want with your code.)

> Beta Testers Say It's One of the Best

These sorts of titles are generally unwelcome here.

NaN behavior in JS is defined in the IEEE standard for floating-point numbers and should be the same in any language.

Any two values can be less than, equal, greater than, or unordered. The > operation, for example, evaluates to true if its operands are greater than. Per IEEE 754, "every NaN shall compare unordered with everything, including itself." By making NaN comparisons unordered, positive comparisons always evaluate as false. "Is 5 > NaN? No. Is NaN > 5? No." Same for ==. But negated comparisons are always true by consequence; since A != B is the same as !(A == B), anything != NaN is true.

One could argue that the spec should have special-cased NaN for the == operator (which as defined is only true if the comparison is equal, and not unordered), but they did not.

Could this have been installed by a Docker Desktop update, perhaps?

Accept: and rel="alternate" were literally made for this

I know, but it's that last bit: it shouldn't be possible to bypass it. C# actually got itself into a similar issue despite being a proper static language, because when it added "nullable reference types" (where you can't assign null to a variable of type `Foo` unless it's explicitly typed as `Foo?`) they did it like TypeScript using purely static analysis to avoid having to change the language at a lower level (for compatibility).

Even though it works 99% of the time, just like in TS you can occasionally run into a bug because some misbehaving library handed you a null that it said can't be a null...

I was thinking more along the lines of a TypeScript-like compiled language. For example, AssemblyScript[0] but with the web APIs added back in. (Personally I'd prefer C# or Rust, but you know most devs will want to keep using JS/TS.) WASM isn't natively supported in the way that I'm wishing it were, though; you still have to use JS to bootstrap it, and JS to call back into web apis. In my ideal world, I'd want to be able to compile

    public static void Main() { Document.Body.Append(new Div("hello world")); }

and be able to use it in a page like

    <script src="hello.wasm"></script>

and have that just work without any JS "glue code". Maybe someday. I know they're working on the DOM APIs, but as you said, it's been slow going. Feels like priorities are elsewhere. Even CSS is moving forward with new features faster than WASM is (nesting and view transitions are awesome though).

(Btw when I said "separate runtime type checking" I didn't mean language-level; I was referring to the validation libraries and `typeof`'s that are required today since TS types obviously no longer exist after build. If it were a real static language, then of course you can't store a bool in a string in the first place.)

[0]: https://www.assemblyscript.org/ (Porffor looks neat too. Wonder if it could be useful in plugin architectures? E.g. plugins can written in JS, and the program only needs a WASM interpreter. I'll bookmark it. Thanks.)

I don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly.

Imagine if WASM were supported natively instead, with browsers exposing the same DOM interfaces that they do to JS. You could link a wasm binary in a <script> and do everything you can with JS/TS, but with any language of your choosing. No doubt a compiled form of TS would appear immediately. We'd no longer need separate runtime type checking.

Just feels like priorities are in the wrong place.

Prepare to have your mind blown:

https://www.youtube.com/watch?v=0mCsluv5FXA

The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types.

On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely using types.

This is really cool.

If you speak another language and can write it more intelligibly than google translate can, then yes. But just google translating your readme is not helpful. Anyone can do that themselves.

> Is it really helpful?

Have you ever seen a library/program that was written by a Chinese developer, but which had an English readme in addition to the Chinese one? Well, imagine if it only had Chinese.

I disagree with the other comment saying there needs to be an established community in the other language first. There are projects I would never have used or even discovered if they had been written solely in the dev's native tongue. But again, this is assuming you actually speak another language and can write it properly; a shitty AI translation will do more harm than good.

> How do you maintain single-source-of-truth?

The English readme is the source of truth. When you change that, change the TL too. If that's too much work, then just don't bother. An out of date translation is often worse than no translation.

My browser tabs right now are using that much ram ;_;

I love not needing tsnode anymore. Just wish it'd do type-checking, since without that we still need to install typescript separately. Add onto that a linter/formatter... meanwhile Deno does all of that natively. Node needs to step up its game.

"Simpler" doesn't necessarily mean better. Next is convenient as long as you stay inside the box, but it's very limiting otherwise (that is, it doesn't adapt to a wide variety of usecases, but rather forces you to adapt to it -- that's my main gripe).

Blaming all of frontend for Next.js' issues is a bit much, but I agree; people have been complaining about Next.js for a long time. It's slow, complicated, and a PITA if you need to do anything outside the box.

Unfortunately, options for SSR in React are all pretty limiting compared to other languages' frameworks, unless you go the full DIY route which isn't usually feasible.

Of course, if you don't need SSR there's no reason to chain yourself to Next and Vercel's whims. Starting a React project from scratch is a lot less painful now with Vite (there was a time when just setting up Webpack & stuff took half a work day).

This is just my personal experience, however. I know a lot of people live and die by Next.js.

Technical description: https://github.com/simplex-chat/simplexmq/blob/master/protoc...

I was going to pass this off as another trash OpenAI frontend, but it's actually a legitimate machine learning project! They even trained a custom model for it. Well done. I wish we got more interesting ML work like this on HN, instead of, you know, the usual AI slop.

There's some more detail at https://omnisvg.github.io/

I wonder why they're delaying the release of the code to actually run the thing, though.

I've always considered it more a "willingness to learn / problem solve" rather than intelligence, although I suppose the two may be correlated.

Most people I've seen who can't handle technology give up at the first sign of unfamiliarity.

I wish it were more common for open source licenses to have an attribution clause, like Apache does with its (optional) NOTICE files. When you put years of effort into a work, you deserve credit for it.

Edit: Actually, using a library via a package manager would likely be considered "linking" and not a Derivative Work, so I don't think even Apache's clause would apply in many cases.