johnnycerberus

Interconnectedness of the world today is economically justified, it does not have any morality in it. In the same vein, if we would have to listen to your anti-morality point of view, we should have kept the connections as before even if we contribute to the global warming, to the deaths of many vulnerable people contributed by the rising number of viruses that are spreaded at an accelerated rate, to the number of cyberattacks that have quadrupled. Similarly to economically accessible transit around the world and its complexity, we have the Internet which is clearly becoming more and more prone to breaches exploiting vulnerabilities (log4j literally proved that everything was open for exploitation). Today, while I'm watching a random Romanian TV channel, many psychopaths at a round table are leading you to believe that Covid's risk is self inflicted by people who don't work out & are overweight and that lockdowns are unjust, it is all people's fault, that there's nothing moral in lockdowns and wearing masks, which I strongly disagree with and it is also not supported by data.

Yes, they should check for any possible breaches. As any other responsbile company already does, like AWS for example which not only checks for breaches, but also scans public repositories like GitHub and GitLab for leaked credentials. A company should also warn a user from time to time that the respective needs to update his password, some companies are so careless that they don't even pay attention to this latter small detail. Or at least to warn an account holder that he still has an account with them.

> and that makes your faulty memory their problem

It is not only memory that is flawed in humans. Hence the protective measures I'm proposing.

> against known breaches

What about the unknown ones? How do you protect your user's account when under GDPR Dropbox is the controller of the data? By sending mails ocassionally to update the password, to adopt 2FA, by locking account due to suspicious activity or to purge it in the end if no further action is taken. It ends with the deletion of the user.

To be fair, data retention is a hot topic right now in Europe, the pandemic and the increased screen time that resulted from it, the amount of accounts we had to create left and right require new regulations.

Do you have a paid account or a free account? If I store my documents on a free account for a one time send to the university application and then I forget about it, then Dropbox should purge it after a time to protect my data, as I don't have any "contract" with them like a subscription or something. The same for G2A, I have bought from them some game keys at a cheap price sometime ago and then I totally forgot that I have one, I couldn't even find the activation mail in my inbox, lol. One day in the summer I woke up with a mail that I have to pay an inactivity fee even if I'm just a row in their database and I have no contractual obligation with them.

I totally support this. It still amazes me that companies still do not delete/anonymize user accounts after periods of inactivity. Everything that is linked to your email address should be purged after 3-12 months of inactivity, including ecommerce like Amazon, game platforms like Steam, cloud storages like Dropbox, or even Hackernews. Good luck trying to find old accounts that you have used years ago, what if they were breached and now they are used by people with bad intentions. In my country (Romania), even barber shops that store user accounts for longer periods than necessary are fined the shit out of them for not closing accounts due to inactivity. Some years ago, I woke up with an inactive G2A account telling me that I have to pay a fee for inactivity. NO! I don't have to pay anything, purge it!

In Romania there's an old question to find the character of somebody: are you Roman or Greek? Because if you are Roman, you put practice above theory, you are a pragmatist, skeptic, if you are Greek you will put theory above practice, you are an idealist, optimist, at the expense of hardships in the material world and other potential drawbacks. Rob Pike chose Roman, otherwise it would have cost Google money to train those people and we don't know if those language features could bring any benefits for the kind of software they develop. As he said, they are not researchers working with category theory, instead they program ever-changing software for an imperfect world driven by profits, rather than academic idealism.

I think the JVM would also be a good choice once Loom lands. I've seen that right now the Java architects are trying to unify the ALGOL flavored Java with ML in the sense of algebraic data structures, pattern matching, local type inference. As you said, OCaml does not have a big community, library ecosystem. It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me.

The complexity that comes from the zero-cost abstractions promoted by both C++ and Rust here isn’t in performance (not runtime nor compiletime) but in programmer reasoning and refactoring.

I agree with you, I believe that simulators, games, software that are "walled-gardens" in the sense that they don't have a lot of interactions with the external world aside from IO and netcode for multiplayer games (that's a pita though), will be usually better in a purely functional model. We must either stay single-threaded or adopt purely functional programming or transactions in those kind of systems. Now, this can be achieved in both C++ and Rust as those kind of systems are not "safety critical", C++ has the edge in metaprogramming while Rust is one step forward in moving the lifetime correctness on the programmer's turf. It's hard to make a point which one is better suited right now as both in my opinion are flawed and have their advantages, it gets evangelical pretty fast. One thing I know is that C++ has the upperhand just because of the sheer amount of libraries that exist in the space and its supporters like Autocad, Valve, Epic and other companies that have billion $ infrastructure built on it.

Right now I'm working with fax machines and I have to provide a C library which is consumed by Scala services. Neither C++ nor Rust would have been an advantage as we are familiar with other methods of verification which are more battletested.

This is why I prefer to write core components in C and then call them through the FFI available in the Java, Python or Node runtimes. Or you can go the "zero-cost abstraction" path which is the middle ground, like C++ or Rust, only that abstractions are not alaways zero cost and low level details will creep into the high level APIs. Different people, different preferences. Like seriously, the only reason I still use C++ is because of its HPC ecosystem coupled with its metaprogramming capabilities which are light years ahead from anything that is offered on the market in that department. This is also the reason why game development can't get out of the C++ trap.

The future of critical low-level programming is a better C or just plain simple C used in tandem with code generators like F*, deductive program verification like Why3 or just good old mathematics that many are irrationaly afraid of like TLA+.

I think PHP gets all the clapping when in fact the statistic that the majority of the Internet uses it to power its services is misleading. Let's face it, Wordpress is a great project, it could have been written in Perl and it would still have had the perks of being Wordpress. When people use it, they don't know what happens behind, I think WP is the perfect example of what a good extensible product is and how it can build an insane ecosystem around it. The plugin architecture is there since 2004, it was and still is very ergonomic. Though Wordpress was not unique in that time, phpBB, vBulletin should be mentioned.

There's no point in creating a new VM, given that you can target almost everything by supporting JVM, CLR, BEAM, V8(JS transpiler) or LLVM/WASM for C-like languages. All you need is an optimized, general purpose IR that will be able to spit bytecode for each one of those and JS in the case of V8. To be fair, I don't think that a language like Kotlin will be able to accomplish this, it is just too complex. I believe that languages with small cores like Clojure with its monumental extension power through macros or Eff or Koka which "let you define advanced control abstractions, like exceptions, async/await, iterators, parsers, ambient state, or probabilistic programs, as a user library in a typed and composable way" such that it will fit runtimes. Like, provide the IR, the building blocks and let ecosystems develop. Some will argue that now you are moving the meaning of polyglot from the programming language to the libary-level, which is true, as seen in the Scala community, the divide between better-Java (Play), a different kind of OOP (Akka) a Haskell-like ecosystem (Typelevel) and an idiomatic Haskell-like ecosystem (ZIO). So you get Java, Erlang and different flavors of Haskell in one language which is Scala :). Many say that Scala is big and messy but in fact the ecosystems spawned by the core of the language made it like that. Scala's spec is smaller than Java's. I would argue that Scala is less complex than Kotlin, but this is highly opinionated.

And even on Android, many open-source projects decide to use Java as they can have access to a wider pool of programmers (Signal, etc). C# is only decreasing in usage, the runtime is just not there, C# has always been known in the enteprise as the language that skipped leg day. It's impressive how many features they've added in a short amount of time that make sense (though some will say, even a few of the Microsoft devs, that async/await was kind of rushed), but the runtime has only received some attention in the most recent times, lagging behind Java with approximately 10 years of research. JS is just JS, hate it or love it, it is here to stay, no point in arguing about this. Put some makeup on it to make things bearable with TypeScript and that's it.

Aside from nullable types, I don't see any other feature that Java could borrow from Kotlin today to improve. Java looks up to Scala and Clojure to get ideas, there are some strong functional programming ecosystems that were bred by these languages, like Typelevel, ZIO, actor-systems like Akka, Datalog queries, contract-based systems like spec2, Stateflow testing, matcher-combinators, generally things that Clojure does differently than the evangelical notion that type-systems are the end all be all. The rest of improvements are on the JVM, like primitive objects (value types) and generic specialization.

What are the innovations brought by Allegro and Lisp Works, relative to Clojure? Just asking as I haven't heard about those, I only have experience with Clj.

Same experience, I've started working with React when Hooks were introduced in a greenfield project. My last experience with JavaScript was jQuery and Angular 1. I was blown away by the functional-declarative approach of React Hooks, I can't believe that people haven't used it before.

Isn't this what the GraalVM [1] guys are also trying to do? Seems like today the competition is between who is more polyglot than the other, JVM, CLR or WASM.

[1] https://github.com/oracle/graalpython

Sad to hear that, F# is an excellent programming language. Scala has matured a lot, there is no "better-Java" anymore, that's the reality, there are three ecosystems today, Akka, Typelevel and ZIO. The competition between these is also seen in the social media and other mediums. There's also Clojure, which in my opinion is still an uncharted territory.

The runtime is highly dynamic. You can do trickery with class loading or wizardry with bytecode manipulation.

We are getting into nerdy arguments. React is by far a framework, as every library that you use will be highly influenced by its constructs and rendering engine, be it React Router, Redux, or others from the Hooks ecosystem. Many say it is just a library, but in practice, when trying to bring JS vanilla libraries, there's always that edge case where it conflicts with the virtual DOM.

> React was popular

By any metric, React is by far the most popular framework in 2021. It has even surpassed jQuery. [1][2]

[1] https://insights.stackoverflow.com/survey/2021#section-most-...

[2] https://trends.google.com/trends/explore?date=all&q=react,an...

The choice between OOP React and Angular boils down to this, as you said, people prefer the OOP nature as they come from Java, C#, some prefer even more the templating system of Angular as that reminds them of JSP, Thymeleaf and other systems that were used in enterprise systems in the past.

Though, the concept of React Hooks changes everything. Functional components coupled with JSX and styledcomponents give you superior composability and encapsulation, imho. When I'm programming in Angular, I notice the familiary, it's like I'm using Spring but on the frontend, while in principle I like the rule of least power, I can say that the declarative nature of React is game changing. Look at the ecosystems that are being developed now with Hooks, like Tanstack, react-hook-form, etc. People are literally creating their own SwiftUIs and Jetcomposers in JavaScript (TypeScript).

Erlang nailed the actor model.

Though it's nice to have so many choices, devs that really want actors will pick a battle-tested platform like Erlang+OTP in the 99% of cases. Because of the natue of BeamVM, which also got a JIT upgrade recently.

Why do you think it is dead? I have always thought that it is incomplete as a language, just give it time. Swift seems to be my cup of tea after years of Java and Typescript. I would really like to learn about these new features and apply them in a backend scenario. Julia is another language that did not catch up as people expected (especially the data science community) but I enjoy using it for my personal projects, that does not mean it is dead.

Indeed, last time I've checked calling into wasm libs had a pretty high overhead. If your app is standalone or if your libary does long running processing in the library, then it is suitable. So far, I haven't seen wasm used in an interactive JS<multiple calls>WASM scenario.

The most depressive thing in managed langauges is that nobody figured out how to use low-level APIs or at least how to bring some abstractions for graphics (2d,3d) that would fit in 99% of the scenarios. Something like three.js in the JS world. Hack, Microsoft didn't even catch with the React/SwiftUI/Compose trend to offer a better model of declarative UI programming.

If you know how to optimize, you can go far with JavaScript, especially with the React model. The problem is that many libraries have been infested with the immutability virus (lodash, immutable.js, fp-ts) and it is used in places where it shouldn't be. Some time ago, I have modified a table library that was offering some filtering capabilities, managed to optimize it by boosting the performance 26x according to my benchmarks. When I created a PR, the authors of the library were literally disgusted by the C-like ordinary loops and mutations in order to achieve the same thing that they did by mixing lodash with streams, hundreds of deep copies, clones etc. even if it provided the same guarantees.

You can hold millions of them with react-virtualize. I'm working with React in an environment where select boxes and tables keep hundreds of thousands, even millions of records in memory. I haven't used Swing, but I am accustomed to JavaFX, which in my opinion it is underrated. There are people who create now Java bindings for Skia, this will give us the ability to create our own crossplatform UI frameworks in Java which in my opinion will revive the community of GUI programming in Java. I also wish to implement a React-like framework in Java, but bundled togheter with a couple of extra things that will give the user a more complete development experience.

Reminds me of Nassim Taleb's works. Reading and rereading the standard library is a good way to learn a language or get depth. I don't see how reading an actual implementation can be considered academic, as it is real-life engineering. It is not pseudocode or theory, some algorithms in Java and C++ are using some ugly shortcuts that only an engineer would find interesting while an academic would think it's heresy.