SuspiciousSwan

No, other people also need consistent performance and a simpler system that works in practice.

Start https://perldoc.perl.org/perlre.html#Extended-Patterns . I was trying to find an article from many years ago, but either my google skills fail me, or it is dead. Perl's regular expressions haven't been regular expressions for a long time. Beyond that, the ergonomics of perl make them much more useful for things like flow control than in other languages. It's similar to how you can do type matching in Java, but it's ugly, versus a language like Haskell where using type matching simplifies the code.

Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.

I think you should revisit perl.

My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.

I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.

Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.

It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.

Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.

I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.

Even a subset of that would be amazing to me -- "removed all of the undefined behaviors, added 128 bit signed and unsigned integers, features for explicit cache management (!!!), and container classes as part of a standard library"

Right now, we have a consumer, provider model of the internet. The internet in the 90s was very different, and looked much more peer-to-peer.

The higher level sharing and storage that we have now through services such as Facebook, Instagram, Dropbox, etc, could have been built in a peer-to-peer way, on top of things like Peergos.

I do not think that Peergos will necessarily be the exact technology that a new, decentralized version of internet technologies will be built on, but we are building the infrastructure and knowledge needed to be ready for power and economics shifts online.

The advantage over C++ isn't about the language itself. If your datastores all have functioning java connections, and your data modeling is already all done in java, it can be worth the pain to do performance critical code in java. I would rather do it in C++, but sometimes the most rational path forward is ugly.

Rust's future is far from certain. I would feel irresponsible using it on a project that wasn't self contained.

I was trying to get to this with good versus rewarding, but it's one of those things that is so obvious when you feel it, but hard to communicate with people who haven't.

As far as drugs go though, there is a lot of personal preference involved too. For me, MDMA in unhealthy quantities is still the best that I've ever felt, and I know some other people prefer the meth high, but I don't think that's exactly what you are arguing against :)

I'm writing from personal experience. Well, I've never done heavy opiates in a basement, so maybe going subterranean makes all the difference.

I guess looking at movies and books, I could see where you'd get this idea, but it really isn't accurate.

There are different types of feeling good, and the purely chemical good isn't particularly rewarding. There are the moments in life where you are happy because you are living the life you want to live, and those are way better than just feeling good from drugs. Sometimes life goals and drugs come together, and that gets really interesting. It's reasonably common for people to do MDMA and have a glimpse of their life without anxiety and trauma, or LSD and looking at their own existence objectively.

For me, the best moments in my life are around building connections with people.

It really depends who your clients are. If they are servers, 30s can work okay. If they are end users, caching happens all over. It's a huge PITA, especially since you'll run into podunk ISPs that have their own custom caching setup, but you have a customer with a shop there. Not that I'm still bitter.

Systems in general tend to have a way that they like to be used. Erlang has all of the tools to support that model, and from my limited experience with it, works great when you respect it. I wouldn't reach for it due to my inexperience, but if I had someone like you on my team, I'd love to learn.

Java also has really great tooling.. when it is used like it wants to be. I don't have enough erlang experience to know if it is true there or not, but with Java, I've found that smart but green devs (like it sounds like Heap has) tend to reach for systems that solve a lot of their initial problems and cover up their initial ignorance, but then trade it for operational problems down the road. More experienced developers tend to build systems that are boring, explicit, take longer to get to Beta, but don't require a pager.

drob mentioned that they aren't writing flink jobs very often, which makes me think that they are probably using it for some sort of rollups / stream processing of their analytics data. If the business logic of those is complex, they'll probably have a bad time with outliers that fuck up their cardinality assumptions. If it isn't super complex, they probably didn't take the time to model their data correctly with boring java classes, and keep pushing complexity into the interactions between their actors.

Either way, they would have a lot faster and easier to maintain system if they forced themselves to pretend to be stuck with java 1.6 except where 1.8 stuff improved performance and readability (basically avoid abusing streams and reflection)

It sounds like you have a lot of operation issues due to the technologies that you used. I mean, at least you aren't doing your backend in node, but running an actor system on top of an actor system is going to be brutal to properly analyze once you actually have scale.

What sort of process do you have for picking trendy technologies vs tested ones, and how much do you talk to people who have built large scale systems before implementing things like scala?

I don't have a lot of faith in BYD busses actually working correctly. Proterra seems like the most solid design around, and looking on LinkedIn, it seems like they picked up a lot of people who worked at Tesla when things were going better over there.

It's even more accurate than I thought when I saw it. I assumed the the visualization of the virus was stupid movie crap, then I worked in bioinformatics and realized it was https://pymol.org/2 . One of my friends worked for the state health department, and she said that the level that R0 was explained was spot on as well.