> 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.
Great point. While not everything is appropriate to share in response to someone else's "Show HN" post, I've definitely seen (and appreciated) others linking similar projects. It usually is in the context of saying something like:
- I tried this too, and can appreciate that you solved way harder things than we expected to have to deal with
- I had this idea too but like your execution
I think it's very fitting, especially since we are celebrating not just the idea, but the execution that someone did to be able to show it off here.
“ 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.”
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.
The pricing is listed on the website, but it's about 10-20% of that. You would pay around 0.50 per 1000 emails. Depending on how often your users sign in and how long you keep them logged in for the the percentage may be lower or higher.
Not offering SAML/SSO/OIDC etc simplifies the problem a lot allowing me to offer it cheaply. The largest cost is sending the e-mails reliably, for which I am wrapping Amazon SES.
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.
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?
ReasonML is, as it has always been, a 100% syntax map to OCaml. It will always be that, but moving forward it will be nothing more than that. Compiling future ReasonML versions to JS will require js_of_ocaml.
The success of BuckleScript meant that a _lot_ of people used what they thought was ReasonML but it was really ReasonML+BuckleScript. This lead to a ton of confusion the moment newcomers realised they needed a second website to look up APIs.
ReScript includes a snapshot version of ReasonML for backwards compatibility, but it will never be upgraded.
The future of ReasonML is likely slow and steady progress, potentially fading into obscurity as the target audience is now very small (OCaml developers who don't like OCaml syntax).
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.
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)
The DSP module in JUCE isn't production quality, and the audio I/O integration in RtAudio is good enough for even professional use cases.
JUCE is really painful to use if you want to integrate it into anything modern. It's old, it's slow, and you really can't make it better. I really can't express how much distaste I have for JUCE after shipping multiple products built on it - it solves _one_ hard problem (wrapping AU, AAX, and VST3), other than that it is dog slow and can't be improved because the core devs don't accept outside contribution for no reason except their own hubris.
Any cross platform UI in C++ that isn't JUCE or Qt is highly welcome. Especially one that allows me to pull in external dependencies and use modern build systems, test frameworks, CI/CD, and other tooling.
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.
Very few C++ UI frameworks deal with accessibility or platform UX standards like zoom (ctrl +). You have to use platform/native APIs directly, or frameworks that seek to model them (which usually are not native).
It's not unsurprising to me that Qt is the most mature. It's the oldest, most widely used, and probably the most well financed...
I suggest looking at wxWidgets. Fully cross platform, no commercial/paid version, all open source, without any of the org issues facing QT, and it's... a classic GUI.
I'm interested in seeing if Elements can integrate. WxWidgets has the typical amount of code (more than a little, but not much more) to create one's GUI. There's significantly more than just a GUI, BTW.
I also tried Dear Imgui, but had to back out due to the constant rendering requirement of Imgui, because my applications are already hi-compute and a persistent GUI is required when you're already pushing the CPU without any GUI.
Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under. There's also the issue where if you get a commercial Qt license it's much more difficult to contribute to Qt under GPL or LGPL. And of course the license is tremendously expensive unless you're making serious money with the application, so prohibitive to smaller companies. I love Qt but I would never feel comfortable using it in a commercial project. There was also this bullshit earlier this year where they tried to pressure KDE into worse terms https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...
> Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under.
this part has always been clear:
"Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreements stay valid in case of a buy-out, a merger or bankruptcy."
Yep, but a hostile entity that owns Qt can do a lot of damage to Qt by publishing on the last permitted day, and denying community contributions and destroying community governance. I can definitely imagine a hostile corporation like Oracle doing so (and they have form).
Qt is still available as GPL. Even if the Qt company goes under today and nobody picks up development, it's stil a great package for many years to come.
I agree behavior lately is not great, and a Qt company in trouble won't be good, but I think the community will pick up quite a bit if it comes to that.
I also think many misunderstand or misrepresent the implications of a GPL only Qt (for closed source applications). It's a matter of linking correctly: https://news.ycombinator.com/item?id=23321448
Right, of course it is, but if the Qt company goes under the highest risk is that its assets get purchased by a hostile entity, which releases everything with a year's delay and doesn't allow community governance/contributions. Imagine Qt owned by Oracle and you'll understand my concern. Of course if that happens KDE and the other current Qt users will likely fork it, but someone like Oracle can do a shitton of damage to the community in the process by threatening litigation.
The issue with the commercial licensing is that if you are a commercial licensee you are contractually prevented from contributing to Qt in some ways. See https://www.qt.io/terms-conditions/ and search for "Prohibited combination". If you are able to comply with the GPL or LGPL components without becoming a licensee, this is better in every way (you get to contribute, you have much more legal safety if the company gets acquired by a hostile entity, you don't have to worry about what happens when your license expires, and of course you save money). So those license terms are actively preventing the Qt company from getting revenue, because you get a worse deal in most ways if you pay them than if you don't. This is why I'm uncomfortable with Qt in non-GPL/LGPL commercial projects. You get trapped and you can't relicense your project to GPL afterwards even if you want to.
I really dont get why people still throw FUD with this argument. It's been what, 25 years already since this argument lead to the KDE Free Qt agreement?
At this point the biggest concern for the Trolls (or whoever owns Qt nowadays now) should be that the FUD against GPL is starting to slowly evaporate, so even big companies are starting to use GPLd Qt rather than pay licenses. By the time they go Oracle there will not be much they can do.
I did briefly. The CMake integration is... quite strange. It kind of has to be because of how strange the compilation model is for a JUCE project, where all your includes depend on having the same set of preprocessor definitions.
I switched to Juce 6 preview branch last week. It's not without problems but getting rid of the Projucer is amazing. Now you can have a clean CMake setup and you are not stuck with Xcode on the mac.
JUCE is a reasonable comparison, as Elements specifies it wants to be a UI for plug-ins like VST & AU, and JUCE is dominant in the audio plug-in space.
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.