lllr_finger

Rust's use of Result is very different from try/catch and exceptions in Java, even if you opt-in to checked exceptions. The big difference is ergonomics and what patterns are used in underlying libraries - opting out of the idiomatic way in Rust feels wrong if you try doing it.

Rust handles your out of range scenario the same way Go does.

If any of this matters to you, the good news is that Kotlin's sealed classes (and soon, Java's sealed classes) allow you to easily implement your own Result-like sum type.

I'd propose Rust - it's also a static, stack-favoring, non-class-based language with OO features that compiles down to native binaries. Where it differs is a wonderful type system and top tier package management. If you can work through lifetimes and the borrow checker, you might enjoy it.

There are some who would argue it's a "soft B" - his recent conf outburst isn't the only example of him failing to listen and adapt.

I look at it as a collection of any guarantees that you can leverage to ensure a (relatively) high degree of correctness, performance, and maintainability. I can't fault Google for valuing these things over agency to play with languages that feel more fun/interesting.

Event streams between decoupled systems is kind of the sweet spot for Kafka. It's extremely easy to scale horizontally, and handles distributed work and network partitions in an easy to reason about way. I've also seen Rabbit be the bottleneck before where I've never really seen Kafka be the bottleneck in an architecture - it's very analogous to a firehose. For organizations shuttling messages and events between teams, it makes a very convenient lingua franca.

Developers can do both pretty easily today without too much effort. The TCO of Kafka clusters is considerably higher than the costs in developing an API that marries a POST to a Producer. It feels like you're saving time on one of the easier parts of the solution.

Totally open to hearing more out of the box ideas. I don't think Hermes is bad for existing, I'm just not envisioning why I'd recommend it to someone.

Sure, I'm aware of how Kafka works - this is an abstraction over all that, so I'm curious if and how Hermes can provide the same behaviors. I didn't see any relevant documentation at a quick glance.

Can someone help me understand the value proposition for Hermes? The only thing I can see is that it abstracts away producing to and consuming from Kafka. The use cases provided answer why you'd use a message broker system, but not why you'd want to do it over HTTP.

Edit: I understand HTTP is easier than Kafka, but is this something developers really struggle with when adopting Kafka? My experience is that they struggle with the nuances, behavior, and maintenance of Kafka/ZooKeeper more than anything.

I also didn't see how it dealt with concepts like exactly once delivery - any experiences in that area?

People that appreciate Rust's features can and do also appreciate a nice site - they're not mutually exclusive.

There is no such thing as "standard" async syntax unfortunately. The Rust language team is trying to find the optimal blend of ergonomics and consistency when there isn't a clear winner. It feels like pointless bike shedding to many, but a decision like how to handle strings has bifurcated the Python community for years.

Sure, a graph wouldn't help fix that but it would at least illustrate the cyclic relationships and someone is hopefully recognizing the drawbacks inherent.

A tool to "fix" your example probably doesn't exist, but a graph is an excellent way to represent dependencies, reason about progress in the flow, and enforce constraints in a generic way.

There are few options, but what do you need beside a graph data structure?

We had a pipeline consisting of microservices and Kafka topics. Simple if/then logic quickly became problematic so I implemented our flow control as a directed acyclic graph, and it helped tremendously.

It's also easy to render your graph out with any number of visualization tools to quickly understand/validate work flows.

It might not have helped here, but updating certs every several years always leads to problems from my experience - people move on, processes get lost or outdated, etc. I'll accept the yearly annoyance to avoid those issues every time.

"All" might not be possible, but every Rust release tends to see improvements in lifetime elision. I just went through a few Rust apps I wrote 6 months ago and was able to get rid of nearly every explicit lifetime annotation thanks to improvements.

So there's definitely room for improvement, but also good progress being made.

It's definitely control, but it's almost a lesser of three evils - it's no coincidence that as a large web publisher at the time, we were approached by Google, Facebook, and Apple at almost the same time and asked to deliver content for their respective walled gardens.

I'd happily choose the web over the other two alternatives. Sure it'd be great to have an open standard achieving the same thing as AMP, but it's 2019 and we haven't seen it yet.

Unless things have changed, you can't think of it as a real CDN. The Google engineer assigned to our AMP launch told us to think of it as a proxy without actually calling it that. Our testing showed that to be an accurate description of how it worked in practice.

I've seen Rust mentioned, but not for the reasons I'm thinking of. My biggest complaint and simultaneously source of praise for the language is that it changes how you view other languages.

Implicit copying, unsafe access in multithreaded scenarios, deficiencies in type systems, and more - all become obvious and inescapable observations when using many other languages.

I'd imagine this effect is lessened if you came from C/C++ and watched the birth of Java, JavaScript, C#, etc., however as someone who started programming more recently, Rust has been the lightbulb moment for me for how languages work under the hood.

It wasn't intended as a drive-by pedantic swipe - I was genuinely curious whether OP meant strong or static. Conversations about type systems and application correctness are exactly the place where precise definitions are welcomed, but I understand that the distinction between strong and static is often conflated. It can be relevant if we're discussing static typing for example, as then something like TypeScript becomes useful.

There's a great writeup by one of the C# people (I want to say it was Erik Meijer, but I'm having a hard time finding it atm) about the distinctions we're discussing here, their relevance to correctness, and the impact on ergonomics. My takeaway from it was that occasionally you will encounter problems that are easier to solve with some freedom and that's why strong/static languages like C#/Rust include pragmatic escape hatches like the dynamic object and the Any trait (respectively).

I completely agree. The JVM is fine until it isn't, and at that point it becomes very frustrating to deal with - even when using less than 16GB RAM.

Do you mean static typing?

This implies that a) you can't rely on "gut feeling" without TDD and b) that you don't write tests without TDD. Both of which are incorrect.

Because the focus should be on correct software and there's a sunk cost fallacy in arguing that you're almost there anyways so why not just buy in to TDD for some purported value.

It might help some developers, but it is not a panacea and should not be promoted as such.

It was one complaint out of several, and the default behavior of a UI shouldn't be an annoyance.

I railed aganinst Red Hat and Fedora for years, then gave in to peer pressure eventually - it's been an extremely pleasant and productive experience.

After 10 years of work you still can't do much useful unless you run X and shim it with XWayland. "Stable" is a strange descriptor given this context.

Yep, look on eBay for sellers that specialize in refurbishing them. It's a great way to get something like an older Thinkpad for really cheap. Perfect for a Linux laptop that doesn't need the latest and greatest.

Your triple word score is already handled by a dozen different companies doing endpoint security from advanced heuristics at the kernel level like Crowdstrike, or just filenames and hashes like Code42.

My guess is that both are "enterprise" languages with a large ecosystem and pool of users, and both have a fairly pragmatic blend of performance/productivity. It's fairly uncommon to see both used together as they tick many of the same boxes.

It took 10 years to move the needle on generics and better error handling, and the draft solutions for both still smell of minimum usefulness/minimum complexity in the language. Whether that's a good approach is up to the individual, but I don't see Go 2 ending up as some unwieldy monstrosity.

I'm curious how the proposal for generics is "bloated" - especially as compared to something like C# or Rust.

My experience is that scaling up can lead to owning pets instead of cattle. It's never fun having a 1TB ATS instance that's acting funky but you're terrified of bouncing it. That's more a devil's advocate anecdote than an argument against scaling up.

I think the intention was that if you're gently coerced into working with a single thread, like with node, then you're also coerced into writing your code in a way that's independent from other threads. In theory, it's easier reasoning about doing parallel work when you start from this point - I've certainly noticed this effect before.

I don't think any reasonable developer would dismiss concurrency/parallelism as easy problems.