MonstraG's comments

On: Major European payment processor can't send email to Google Workspace users

[MonstraG]

What comes to mind

- You are sending a receipt and want table alignment for items

- You want to put a logo of your company so that readers can recognize who's the email from

- You want to make unsubscribe link smaller and the "open the thing I'm notifying you about" link bigger, so that people would know which one is which without reading the url

- You want to add a header

[mrweasel → MonstraG]

Mostly those seems to be more about you as a sender wanting to do some branding or manipulation of the reader. I don't really see how it benefit the receiver, which should be the main concern of all communications.

[knollimar → mrweasel]

You don't see how a table can communicate things more clearly and benefit both the reader and sender?

On: A complete guide to the new 2025 NIST password guidelines – Proton

[MonstraG]

Yea, I think they (proton) just didn't properly read (misunderstood) the guidelines.

> 3.1.1.2 Password Verifiers

> ...

> 2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.

In other words, if you want to put a max length, don't put 20, put at least 64.

On: Million Times Million

[MonstraG]

Don't know anything about misunderstandings, but the symbol in question is https://en.m.wikipedia.org/wiki/Looped_square

On: Zed: High-performance AI Code Editor

[MonstraG]

Native 1440p, never used retina nor 4k.

(not parent commenter, but hold same opinion)

[silon42 → MonstraG]

Same here... 1440p 32" is optimal for me, the only improvement I'd consider right now is 1600p equivalent.

[AndroidKitKat → silon42]

Biggest draw for me with 1440p 32" is being the same DPI as a 1080p 24". I like to have one big monitor and then 2 small flank vertical monitors and having them all be the same DPI just makes headaches go away on every operating system I use them with.

[johnisgood → silon42]

Damn. I am so happy with my old 17" monitor and 1280x1024 resolution here. :D

On: The new 4o personality is unusable for therapy

[MonstraG]

I would go for "writing style" or "behavior", but would almost be okay with "personality"

[deeThrow94 → MonstraG]

Inanimate objects are said to have personality, too. This is certainly true for clothing and decor.

[koakuma-chan → deeThrow94]

Rust has error handling personality.

On: It is hard to recommend Python in production

[MonstraG]

Oh no it's the bouncy ball chart.

Please, if you have enough time, watch this https://youtu.be/EH12jHkQFQk

and avoid making any decisions using this chart.

[ashishb → MonstraG]

> and avoid making any decisions using this chart.

I did not mention that chart at all in the blog post. I just used this as a nice illustration.

[raverbashing → MonstraG]

Honestly yeah

It's an artificial benchmark that means nothing in production

Also the article does not bring much to the table except of python whining

"Oh the Go dockerfile is smaller" Yes you compiled it and is running a binary. Big woop. Funny how the author not doing the same comparison with node

[ashishb → raverbashing]

> "Oh the Go dockerfile is smaller" Yes you compiled it and is running a binary. Big woop. Funny how the author not doing the same comparison with node

If I did that with Node, you would say what about Ruby. If I did that with Ruby, you would say what about Zig. There is no end to the list of languages.

> It's an artificial benchmark that means nothing in production

It was a cover illustration, I did not mention that at all. In fact, I demonstrated the resource consumption of Python's docker image. If you have suggestions to make the Python one, I am all ears.

[raverbashing → ashishb]

> If I did that with Node, you would say what about Ruby.

No, because the comparison here is runtimes of interpreted languages

Comparing a compiled binary to the python/node/ruby runtime is comparing Apples to Oranges

[ashishb → raverbashing]

Why do I have to restrict myself to interpreted languages only?

On: An approach to optimizing TypeScript type checking performance

[MonstraG]

Can you share what was the problem, just in case we have it too?

[kg → MonstraG]

We had little strings that encoded call signatures, like "iiff" for int int float float. Someone cooked up a way to have typescript validate the strings at build time, but the way it does typechecks against string literals like that seems to cause every string literal in your entire compilation to get validated in advance to figure out whether it could possibly be that specific type. Each possible value - let's say we had 'f', 'i', and 'l' originally and then we added a fourth option for 'd' - caused the typecheck time to magnify by increasing the possible options. IIRC.

[eddd-ddde → MonstraG]

I'd bet it had to do with complex templates.

I've had typescript break on me when using libraries like elysia that go full send on their templates.