james-mcelwain

So freedom of association doesn't matter?

I'm totally unsure how that's relevant -- we're discussing employee handbooks for private institutions. I'm very in favor of freedom of speech at the governmental level.

It definitely makes sense to have some kind of official policy about what kind of speech is acceptable, but I don't think it's possible to enumerate all opinions that are unacceptable in a reasonable way.

I'm almost certain MIT has an employee handbook that reasonably covers situations like this. If anything, it's a demonstration of favoritism that he wasn't fired in the past.

> Because if you really think that somebody needs to be fired, for stating a point completely unrelated to their job, then that is a problem that we, as a society, need to address urgently.

The issue is not voicing an opinion in private -- it's voicing it on an institutional mailing list in his capacity as a member of that institution.

There is absolutely no obligation to presume innocence in our personal opinions. We are all freely permitted to form our own opinions based on the facts of the situation.

There are good reasons that our legal systems favor the accused -- ones that I _fully_ support -- but it is an unreasonably high epistemic standard for us to operate under in our daily lives.

If I don't want to associate with someone because they're an asshole, I'm under no obligation to prove so beyond a reasonable doubt. My freedom of association is more fundamental.

> I just don't want to live in a place where expressing my opinion on some controversial issue, entirely lawfully, might have me excluded from society.

I don't either, but that doesn't mean we need to have an absolutist position on speech. I don't view defending pedophilia or making apologies for the rape of a sex trafficking victim to be merely "controversial."

Not all tech companies rely on exploitative labor practices.

I feel like LedgerX bragging that they are both an exchange and a clearing house does not inspire confidence in their risk management department, although I'm sure the bright minds at the SEC have done their due diligence as they always do.

Kafka is moving towards eliminating the ZK dependency, while will make it easier to run as a single node if you don't care about HA.

My favorite WeWork anecdote is the company paying the CEO 6 million dollars for the trademark "We" (which he later returned under pressure).

Say what you will, but you have to respect the grift.

If you don't want to feel sad, maybe you shouldn't get emotionally invested in a company with a near trillion dollar market cap that exists solely to sell targeted ads.

Are the sort of places willing to sell options on BTC the sort of places that would honor such a contract if the price went to 0?

Is C# more performant than Java? It was my understanding that HotSpot's JIT performs significantly more optimizations, almost bordering on esoteric magic, compared to the CLR.

I can understand how value types would help a lot, but it is possible to optimize Java to avoid object headers on the heap at great pain, i.e. avoiding classes and doing index arithmetic on flat arrays of values. Value types coming to the JVM will obviously help here.

Curious to hear about other advantages the CLR has.

I don't want to sound like a Spring booster, since there are plenty of criticisms of enterprise Java development that I agree with, but there's nothing intrinsic to Spring that dictates whether your business logic is spread amongst 100 files or 20.

Dependency bloat can be a concern, but part of the reason for those dependencies is to reduce bloat in source code via auto-configuration.

I'd strongly reject the argument that "society considers all women valuable", but even so, it's irrelevant to the discussion. Whether it's sexism against men or sexism against women, the disparity is a problem for women who want to enter these professions or for men who want to enter "more personally fulfilling" professions. Regardless of the framing, it's certainly true that inequality can lead to bad outcomes for both men and women.

This assumes that there is some essential demographic difference that causes fewer women to end up in these professions. While this may be somewhat supportable in the few fields where muscle mass is relevant, the contention here is that disparity in fields like higher education or software engineering is in itself due to sexism. It's nice that the pay gap isn't that large for women who do manage to enter these fields, but that doesn't address any of the underlying structural causes that prevent women from entering these fields in the first place.

I’d argue that the multiplicity of different programming languages and programming language paradigms suggests there likely isn't a teleological trajectory towards some single standard for programming.

Part of this is because many systems are evolving, because business needs have human inputs and are not always "logical." At the edges where this human interaction happens, we expand the domain of programming to that of human psychology. There definitely are empirical claims we can make human-computer interfaces, but it begins to get a bit messy.

To be clear, I am personally interested in becoming more rigorous about empirically justifying claims I make about the code I write. But I’m also interested in code because many of the problems it attempts to solve map the very complexity of the real world. In many ways, abstraction is a properly philosophical exercise, and I think it’s impossible to separate a pure engineering discipline from this broader context.

Programming is multi-disciplinary, and I think that’s a strength.

There's a toy Kafka implementation written in Go that attempts to do this: https://github.com/travisjeffery/jocko

Previous HN discussion: https://news.ycombinator.com/item?id=13449728

There are a number of Java libraries that implement Raft already -- it's a fairly well understood algorithm.

Type inference isn't "going backwards."

Imagine we have a list of some values and map a function that returns a list of some other type. In other words, for every value in the list, we replace it with the results of calling our function, which returns a list. We have introduced nesting and now are operating on a "list of lists of values" rather than a list of values.

However, generally you don't want to operate on a list of lists and are trying to process each value one by one -- the nesting doesn't add anything. In this case, we use flatMap, which "flattens" or concatenates the interior lists so we can operate on them like it's just a big stream of values.

This is also the case for another type like `Optional`, which represents either a value `T` or the absence of a value. An optional can be "mapped" so that a function is applied only if there is a value `T` present. flatMap works the same way here, where if you want to call another method that also produces an `Optional`, flatMap will "unwrap" the optional since you never really want to work with the type `Optional<Optional<T>>`.

> Gamergate as a grassroots, distributed movement was very interesting and it's sadly not surprising that "the powers that be" want to reign back in control of the narrative.

Ah yes, distributed grassroots misogyny. If only the """powers that be""" hadn't reigned back control of this vital, important movement to harass women online.

We should be more precise: the JVM may or may not have an interpreter. This is implementation dependent. There are JVMs that are interpreted fully and AOT compilers as well.

Hotspot includes an interpreter -- your code may be interpreted until it gets hot and gets compiled.

Still, I don't think it's fair to call Java an interpreted language since the parts that are interpreted are only during warm up or slow enough not to matter.

I'm not sure I fully understand. Interoperability is as simple as wrapping the non-standard API, no? This way you have a standard calling style in your code. It's not a weakness of async/await that some libraries don't have promise friendly APIs.

The way I would phrase it is that the Java ecosystem is simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms.

The ability to swap out basically any component of a framework like Spring simply by including a different dependency or replacing a bean at runtime allows for fine grained tuning that isn't possible in many other frameworks.

But this flexibility and/or modularity is enabled by a heap of pretty magical abstractions that glues everything together.

I'm so happy that Bitwig is supporting Linux as a first class platform, but it's still unstable enough on Linux that I would never consider using Bitwig on Linux for, e.g., a live performance.

I'm sure they consider crashes on Linux real bugs, so hopefully it's just a few more years of work to have a rock solid DAW on Linux. Super excited about the future of Bitwig.

This could be accomplished using Optional#orElseGet without any additional library dependencies, though.

There are other solutions (like Rc<RefCell<T>>) that allow you to avoid cloning as well if you still don't want to deal with lifetimes.

Actix completely changed my relationship to writing Async code in Rust, which I had really struggled with for a long time. I'm a huge fan and it definitely feels like a first step in more mature tooling for web services in Rust.

It's certainly a less mature ecosystem, but once you get over the hump of understanding lifetimes, there's nothing preventing you from using lots of owned values and clone in a way that makes it really easy to ignore annoying lifetime problems. And, the benefit being if you ever need to get more performance out of a hot part of your code, you can always optimize to get that zero copy goodness.