merlinsbrain

There are guidelines for what Show HN is supposed to be. This site pretty much fits the bill.

https://news.ycombinator.com/showhn.html

> Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.

> On topic: things people can run on their computers or hold in their hands. For hardware, you can post a video or detailed article. For books, a sample chapter is ok.

I am glad to see work from other hacker news members. When it isn't interesting to me, I find something else on the internet or IRL that is.

Another interesting quote:

“ Following this approach, in our model we consider the message encryption scheme used in MTProto 2.0 as a robust authenticated-encryption scheme, abstracting from its actual implementation.”

So yeah, they’re abstracting away the AE part of it, which may not be an accurate reflection of what telegram uses.

That being said, they’re aware this is a strong assumption:

“ Namely, the only assumption we make is that the latter is an authenticated encryption scheme, guaranteeing both integrity of ciphertext (INT-CTXT) and indistinguishability of chosen plaintext (IND-CPA). These properties are difficult to prove in a symbolic model like ProVerif’s, but can be proved in a computational model, e.g. using tools like CryptoVerif or EasyCrypt [5, 2]. This assumption may appear strong, especially considering that Telegram has been widely criticized for its design choices (such as ad hoc cryptographic primitives and an unusual encryption mode), and vulnerabilities have been found in MTProto v1.0 (but actually, none of these attacks have been replicated on the new MTProto 2.0). Still, proving the logical correctness of the protocol under a fairly general threat model is very important because, if a weakness in the protocol exists, it must be looked for in the “lower-level” part of the protocol, among the chosen cryptographic functions and other implementation choices.”

I’m not very vested in a solution at the moment, but if I had a set of users < 500, the flat pricing of Magic Link kind of makes more sense to me, I don’t want to be worrying about how many times they sign in.

That being said, I can imagine there are people who would prefer a per sign in model, it’s just a level of granularity I don’t care for.

Good luck!

What would your pricing be? Starter pack at $35/month for 500 users sounds like $35/month and I outsource auth to a company that is also on the hook for “enterprise” security :)

I think it’s awesome you’re building an alternative with a different feature set, I’m really curious to hear your take on pricing.

Theoretically, ReScript will support ReasonML syntax, and theoretically ReasonML can still be used for native development.

The messaging isn't clear on ReasonML's future at ALL though. Is it essentially deprecated until the full switch to ReScript happens? The Rescript FAQ mentions changes will be additive in supporting ReasonML, and they will track new features to OCaml, but will they track new features to Reason? Will anyone actively develop Reason anymore?

At that point it’s just a license to use.

MIT isn’t going to fly anymore if the intention is to make money off of that.

Hard disagree. I’d encourage you to reflect on your startup’s culture and figure out what distinguishes a good engineer from a good engineer who can convince you about their passion.

Usually, it’s when startups want employees to work longer hours than the value the they’re calculating on receiving from the equity+pay that’s being offered.

Whiteboarding algorithm puzzles with code really does not define the greatness of an engineer. If people are practicing questions to be able to think along those lines and that is proven to work, maybe it really isn’t a test of greatness anyway.

This is the exact attitude that makes people have terrible interview experience.

If Wapnick’s work resonates with you, you might enjoy Barbara Sher’s Refuse to Choose. [0]

Sher is the author who “coined“ the “scanner” term.

[0] https://www.goodreads.com/book/show/287818.Refuse_to_Choose_

Also, I can really see the appeal of electron now (from a development standpoint).

It really is Qt vs Electron if you want to ship a product that makes money - something I am paying for is expected to have a lot of these "features".

Yeah, I guess the key is the last part of your last sentence, heh

> the most well financed..

I have been playing with Dear Imgui lately, and while its super easy to get up and running, I realized it doesn't have support for zoom (cmd +) and accessibility (unless I missed something).

It seems like those features are out of scope for the library - which is fair, one has to draw the line somewhere, and there are enough success stories with the project that it may not matter to a lot of the people. The author has mentioned in various places it's mostly for internal tools or game dev, which makes sense.

I am glad more toolkits are coming up (both for C/++ and Go, the languages I am interested in writing desktop apps with), but I am a bit surprised Qt seems by _far_ most mature compared to a lot of newer tools, not counting wxWidgets or glade/gtk3.

Looks cool! I wonder how this compares to Dear Imgui in terms of features. (I understand this may not be an immediate mode toolkit, so not really discussing that side of things)

Would the usual competitor to this be JUCE?

This isn’t too compelling a story on its own, I’m assuming this is someone who wrote a collection for themselves and made it public on their blog.

Glad they wrote their collection, but not something I’m excited about.

In general I’d love to hear “this was better in Rust because of X, Y and Z and the tradeoffs I had to make were A, B and C”.

But again, this isn’t on the author to do, I’m pretty sure I can find other articles on the internet that talk to that.

Edit: most of the READMEs of the projects look pretty good about that on a quick skim.

Thank you dang, you've been an amazing steward for this community and the technology that powers it.

Keeping something the way it is, is super hard in tons of ways a lot of us probably don't understand. We appreciate you.

Not sure why you’re being downvoted. Scaling systems at companies with a lot of money is very different from designing system to be reliable and performant and with reducing spend being a real goal.

Some companies need to take a much harder look at their spend than others regardless of where you deploy.

Written in X can definitely be a value proposition.

If you are evaluating a tool/lib/etc that moves at a fast pace and your whole shop is extremely fluent in language X there's huge value add to being able to dive in without a context switch to understand how it works, especially when debugging harder problems.

I don't think it applies to _this_ case where we're getting a VM that is _extremely_ battle-tested. Am I going to use a new OS instead of linux in production because someone tried to write an OS in zig? No. Will I congratulate the author for writing an OS in zig? Yes.

If I am looking for a key-value store and two are equivalent in their purported features and stability, I will choose the one that is written in X that my shop is most fluent in.

> Why start if you have no intention to see it through

The author had a threshold of good feedback they needed from the community in a certain amount of time. They got the feedback they needed - people aren't interested in it, probably because of the latter part of your comment.

I don't think that's a valid reason to ask why someone started a thing, people start things for a variety of reasons. As far as I am concerned, they saw the development of a reimplementation of solid tech through and learned a lot from it.

> they already have a VM for BEAM and it works well. Without an additional selling point 'now in Rust' doesn't cut it.

This is spot on though.

Are you looking for the log module, but with a UI on top of it (something like splunk, but for local development)?

The comparison of pay between what PhD students get in the US vs other countries is plain silly. It’s apples to oranges, the cost of living can be an order of magnitude different, which is not mentioned even once, favoring the absolute number comparison as a good thing.

Beyond this the article talks about low stipends, while an important topic of conversation - nothing new.

That is a potential reason.

What is certain is your passive-aggressive shot at another users reading choices that doesn’t contribute much value.

If you’re willing to pay, why not rent from the iTunes Store / Amazon Prime?

Pick one, they’ve had all the movies / TV shows I wanted to watch, which are not all mainstream.

If there’s an exception and there’s something you don’t find it there - well, do you, but I really don’t understand how piracy is the default answer to convenience with people claiming they have the willingness to pay.

Someone else commented about the local video store - also an option, if not something I’d do myself (does redbox count?)

Are you in school or publishing while in the industry? Always wondered how to do the latter without a PhD and working with a Big N in their research org.

I’ll concur with this thought.

It’s inspiring but there’s nothing really to take forward from there.

It’s like a talk from a motivational speaker - it’ll get you into that desirable state of mind for a little bit, but won’t help you change anything fundamentally.

The link doesn’t work, I’m interested to read it though.

There’s a pretty clear distinction between slack and telegram - telegram offers a secure messenger channel with private messages. Slack does not do this, and publicly does not plan on doing this.

The parent comment is requesting that an existing feature be switched on as default and not introduce a whole change in the communication layer of the app.

Unfortunately you then lose syncing across devices, so I understand where telegram wants to make less secure the default.

Seems like a bold move to me regardless if the engineers are 20 or 50 or 90.