nsajko

Julia is another contender. Julia code can be as performant as C++ code, but Julia code may be even more elegant than C++. Even without accounting for Julia's metaprogramming features, the compile-time expressiveness is top-notch.

It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptimal code.

Yeah, double-word floating-point loses many of the desirable properties of the usual floating-point.

> Number isn’t an interface—there are no operations common to all numbers.

When creating a new type, it should be more clear cut when is subtyping Number (or Real, etc.) valid. Should unitful quantities be numbers? Should intervals be numbers? Related: I think there are some attempts by Tim Holy and others to create/document "thick numbers".

Furthermore, I believe it might be good to align the Number type hierarchy with math/abstract algebra as much as possible without breaking backwards compatibility, which might making Number, or some subtypes of it, actual interfaces.

> Subtyping Number is a way to opt into numeric promotion and a few other useful generic behaviors. That’s it.

OK, but I think that's not documented either.

I don't think testing against every existing dependent would make sense currently. The issue is the lack of tooling for mechanically checking whether the dependent accesses implementation details of the dependency, in which case it would be valid for the dependency to break the dependent.

There are some proposals to forbid the registration of a package release which trespasses on the internals of another package, though.

I hope someone tackles the above sooner or later, but another issue is the approach of testing every known dependent package might be very costly, both in terms of compute and manual labor, the latter because someone would have to do the work of maintaining a blacklist for packages with flaky unit tests. The good news is that this work might considerably overlap with the already existing PkgEval infrastructure. We'll see.

What I wanted to say is that I'm skeptical regarding "interfaces", either as a language feature or as a package. Although TBH I have not yet given any specific "interfaces" design more than a cursory glance, so my position is not really justified.

> the culture of not prioritizing correctness in computation

On the contrary, it is my impression the experienced Julia programmers, including those involved in JuliaLang/julia, take correctness seriously. More so than in many other PL communities.

> there are people working on traits/interfaces - but these are still peripheral projects and not part of the core mission to my knowledge

What exactly do you mean by "traits" or "interfaces"? Why do you think these "traits" would help with the issues that bug you?

The Julia world is already quite careful with testing and CI. Apart from the usual unit testing, many packages do employ integration testing. The Julia project itself (compiler, etc) is tested against the package ecosystem quite often (regularly and for select pull requests).

Julia is not without warts, but this blog post is kinda rubbish. The post claims vague but scary "correctness issues", trying to support this with a collection of unrelated issue tickets from all across Julia and the Julia package ecosystem. Not all of which were even bugs in the first place, and many of which have long been resolved.

The fact that bugs happen in software should not surprise anyone. Even software of critical importance, such as GCC or LLVM, whose correctness is relied upon by the implementations of many programming languages (including C, C++ and Julia itself), are buggy.

Instead the post could have focused more on actual design issues, such as some of the Base interfaces being underspecified:

> the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is)

The underspecified nature of Number (or Real, or IO) is an issue, albeit not related with the rest of the blog post. It does not excuse the scaremongering in the blog post, however.

> it is plausible that ChatGPT can get to a state where it can act as a good therapist

Be careful with that thought, it's a trap people have been falling into since the sixties:

https://en.wikipedia.org/wiki/ELIZA_effect

Julia does this for parametric types, too.

> whiffed a few major decisions early on

Anything particular in mind?

> Recompiling everything every time.

> recompilation on every run breaks this

Your comment is exceedingly misleading. Whether and when Julia code gets compiled is up to the user.

> Pkg.jl is also not great, version compatibility is kind of tacked on and has odd behavior.

Huh? I think Pkg is very good as far as package managers go, exceptionally so. What specifically is your issue with it?

Pratt's method only targets the operator precedence languages, not the DCFL. So much less powerful than LR parsing.

Is Trump not supposed to be tough-on-crime? How does pardoning a drug dealer factor into that? Is Trump against the war on drugs?

Ireland giving special benefits to a private company like Apple conflicts with the principles of a free and fair market.

Lousy high school.

> [...] there's progress [...]

Don't forget about Julia!

Abstract interpretation is important in the implementation of the Julia language. Some relevant blog posts by Julia compiler developers:

* https://info.juliahub.com/blog/inference-convergence-algorit...

* https://info.juliahub.com/blog/inference-convergence-algorit...

* https://aviatesk.github.io/posts/introduction-to-static-anal...

* https://aviatesk.github.io/posts/data-flow-problem/

Wikipedia page on worker's self-management:

https://en.wikipedia.org/wiki/Workers%27_self-management

The title doesn't conform to the HN guidelines, dang.

The "Unlicense" is not considered as serious.

> There's a bit of a higher abstraction ceiling in Rust

Compared to C, yes, but not compared to C++.

Source?

The TLDR describes your method accurately, though. You do store your OTP secrets in a password store.

That said, the significance of using two separate password stores isn't clear to me. Under what threat model is that supposed to be an improvement over a single password store? Basically, your idea is that passwords are less essential than OTP secrets, so you take less care keeping them safe. However I think it'd make more sense to just apply proper protection for all secrets.

TLDR: use a password manager to store your secrets. An OTP secret key is just a secret.

Why do you need it to be a single app?

Please don't FUD.

It seems that Milton Friedman's work and "libertarianism" itself were both just PR in the beginning: https://www.alternet.org/2013/09/true-history-libertarianism...

So it's not so much a question of ideology, as a question of where the money is coming from ("Cui bono?").

This is part of the international law enforcement project called Endgame.

Official Web site: https://operation-endgame.com

Europol press release: https://www.europol.europa.eu/media-press/newsroom/news/larg...