loglog

I recommend to block the Linkedin feed with uBlock.

Traveling? Lake home? I am glad to go to work just to not listen to my wife how we are so poor and cannot have nice things.

> how many people here have actually worked at an early stage startup in a lead role

Obviously very few, because these roles are impossible to get into. What else did you expect?

Operator of the LinkedIn Website:

LinkedIn Ireland Unlimited Company Wilton Place, Dublin 2, Ireland

php is the only popular language that regularly removes insane legacy cruft (to be fair, they have more insane cruft than almost any other language to begin with).

Real men know that infinite sets are just a tool for proving statements in Peano arithmetic, and complex numbers must be endowed with the standard metric structure, as God intended, since otherwise we cannot use them to approximate IEEE 754 floats.

Your link is _not_ about a country that _actually_ imposed a sugar tax.

Counting warnings is a poor practice, because you don't see where warnings exist or are added or removed while reading or writing code. Suppression annotations in code next to where the problem occurs are more explicit, and the progress is easy to measure with e.g. git log -S. The main difficulty is automating adding these annotations. For at least one static analysis systems, there is an off the shelf solution: https://github.com/palantir/suppressible-error-prone

That's right, much of the market is negative sum.

Wealth tax is the best type of tax, because it incentivizes productive activities against speculation. It should be levied on a continuous basis rather than on transaction basis though, which is just basic numerical analysis.

I think that the problems with unchecked exceptions are due to the simultaneous presence of both checked and unchecked exceptions. The designers must have thought that checked exceptions would be the rule, but left an escape hatch.

If there were no checked exceptions to begin with, people might have thought about making the Java compiler (and later language server) infer all possible exception types in a method for us (as effect systems do). One could then have static analysis tools checking that only certain exception types escape a method, giving back checked exceptions without the type and syntax level bifurcation.

On the other hand, if all exceptions were checked, they would inevitably have had to implement generic checked exception types, ironically leading to the same outcome.

The plain Java equivalent of the proposed semantics would be a type system extension similar to JSpecify: @Result(ok=Ok.class, error={Checked1.class, Error2.class}) Object function() combined with enough restrictions on the usages of results of such methods (e.g., only allow consuming the results in an instanceof pattern matcher; not even switch would work due to impossibility of exhaustiveness checking).

The one feature that the proposed Kotlin error types share with Java checked exceptions is that they can be collected in unions. However, the union feature for checked exceptions is pretty much useless without the ability to define higher order functions that are generic over such unions, which is why checked exceptions fell out of favor with the spread of functional APIs in Java 8.

Math does that. Peer review cycles are measured in years there. This does not stop fashionable subfields from publishing sloppy papers, and occasionally even irrecoverably false ones.

Have some pity for those Senior Expert Architect Full-Stack Developers (fresh out of boot camp) in urgent need of job security.

There is no "Navier-Stokes theorem". There is a famous class of open problems whether Navier-Stokes equations are well-posed (have solutions that don't explode in finite time) for various initial data, but that type of question is completely irrelevant for any practical purposes. I do share the feeling though. As a non-expert, I have no idea what the existing, allegedly practically relevant, formalizations of distributed algorithms actually guarantee.

1. There are tons of static analyzers for C++. Does none of them support type system augmentation? 2. Is the proposed solution really more practicable than "typescript for c++" [0]?

[0] https://github.com/hsutter/cppfront

It was a terrible idea to market it as Python-compatible, and they are now slowly walking away from it.

It was extremely easy for that train to stop in Bonn-Beuel, which is anyway far superior to Troisdorf for a train that was originally scheduled to stop at Bonn Central Station. Failing to stop there shows perfectly how little DB cares about its passengers.

Removing parts of the city to add more lanes will also help decreasing demand - it's a win-win!

Would American companies treat an average motorist better than foreign companies? Are you insinuating that these good, law-abiding, American companies are COMMUNIST?

I don't want to see any irrelevant history several years later, so I enforce linear history on the main branch in all projects that I work on. So far, nobody complained, and I've never seen a legitimate reason to deviate from this principle if you follow a trunk based release model.

All problems that you've listed seem pretty minor compared to what was happening in the rest of the world at that time, reinforcing my point.

The author is in the comfortable position of working on a system that does have a formal specification and a formally verified reference implementation. The post is not about how they wish things would work, but how their existing system (Cedar) works.

Regarding your point on Rust, the vast majority of software has nowhere near the amount of static guarantees provided by Rust. If you need more, use static memory allocation, that's what people do for safety critical systems. By the way, it seems that Rust aborts on OOM errors, not panics: https://github.com/rust-lang/rust/issues/43596

Are we talking about the middle of World War II in the US? A war that resulted in exactly 6 civilian deaths in the continental US and destroyed all serious competition for US industry for decades to come? That was one of the economically most advantageous positions in history.

Java has a solution for the thread problem: Scoped Values [0]. If only the logging+tracing libraries would start using it...

[0] https://openjdk.org/jeps/506

"Private equity generating rental income" is a lie fed you by the rich lobby. The real reason (everywhere in US and Europe) is zoning, which is a subsidy to the owners of existing buildings at the cost of everyone else.

I estimate the fraction of carbon removal cost wasted to regulation at 100% rather than 50%. Regulation must be truly insane if producing synthetic oil and pumping it underground is somehow more appealing than not extracting the equivalent amount of fossil oil in the first place.

While the `Optional` API is generally pretty inconvenient (compared e.g. to Kotlin), it does offer the more precise `ifPresent`.

Java checked exceptions suffer from a lack of generic exception types ("throws T", where T can be e.g. "Exception", "Exception1|Exception2", or "never") This would also require union types and a bottom type. Without generics, higher order functions are very hard to use.

> Breaking off pieces of the code into microservices ... I was with you until "into". Then continue with "Maven modules" (or Gradle modules, or some other kind of modules) and solve some real issues instead of imaginary deployment structure issues.