loglog (u/loglog) - Readit News

loglog commented on Tech employment now significantly worse than the 2008 or 2020 recessions twitter.com/JosephPolitan... · Posted by u/enraged_camel

crystal_revenge · 11 days ago

> You learn the most valuable information from watching how things break and then fixing them.

Trust me, you get plenty of experience in this as a founding engineer in a startup.

Many of these comments make me wonder how many people here have actually worked at an early stage startup in a lead role. You learn a lot about what's maintainable and scalable, what breaks and what doesn't, in the process rapidly iterating on a product to find your market.

loglog · 10 days ago

> 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?

loglog commented on I verified my LinkedIn identity. Here's what I handed over thelocalstack.eu/posts/li... · Posted by u/ColinWright

csmpltn · 24 days ago

Nobody is forcing you to use LinkedIn. LinkedIn is an American product, made by an American company in America, subject to American law. When you create an account - you agree to American terms and conditions, arbitrated by American courts.

LinkedIn doesn't need to obey to EU law. It needs to obey to American law, which allows LinkedIn to do business with anybody (other than people from sanctioned countries) whilst complying with US law. EU's laws don't matter in the US. The EU can sue LinkedIn, but LinkedIn can just safely ignore any lawsuits and ignore sanctions, because they are an American company subject to American laws.

EU citizens are willingly subscribing to an American service, then complain the American service doesn't abide by EU laws. That's laughable at every level, to any individual with a modicum of intelligence. If you don't agree to the terms, don't use LinkedIn. You are not entitled to anything.

loglog · 24 days ago

Operator of the LinkedIn Website:

LinkedIn Ireland Unlimited Company Wilton Place, Dublin 2, Ireland

loglog commented on Farewell, Rust for web yieldcode.blog/post/farew... · Posted by u/skwee357

onyx228 · a month ago

The dependency creep keeps on happening in web frameworks where ever you look.

I was thinking of this quote from the article:

> Take it or leave it, but the web is dynamic by nature. Most of the work is serializing and deserializing data between different systems, be it a database, Redis, external APIs, or template engines. Rust has one of the best (de)serialization libraries in my opinion: serde. And yet, due to the nature of safety in Rust, I’d find myself writing boilerplate code just to avoid calling .unwrap(). I’d get long chain calls of .ok_or followed by .map_err. I defined a dozen of custom error enums, some taking other enums, because you want to be able to handle errors properly, and your functions can’t just return any error.

I was thinking: This is so much easier in Haskell.

Rather than chains of `ok_or()` and `map_err()` you use the functor interface

Rust:

``` call_api("get_people").map_or("John Doe", |v| get_first_name(v)).map_or(0, |v| get_name_frequency(v)) ```

Haskell:

``` get_first_name . get_name_frequency <$> callApi "get_people" ```

It's just infinitely more readable and using the single `<$>` operator spares you an infinite number of `map_or` and `ok_or` and other error handling.

However, having experience in large commercial Haskell projects, I can tell you the web apps also suffer from the dreaded dependency explosion. I know of one person who got fired from a project due to no small fact that building the system he was presented with took > 24 hours when a full build was triggered, and this happened every week. He was on an older system, and the company failed to provide him with something newer, but ultimately it is a failing of the "everything and the kitchen sink" philosophy at play in dependency usage.

I don't have a good answer for this. I think aggressive dependency reduction and tracking transitive dependency lists is one step forward, but it's only a philosophy rather than a system.

Maybe the ridiculous answer is to go back to php.

loglog · a month ago

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).

loglog commented on Mathematicians disagree on the essential structure of the complex numbers (2024) infinitelymore.xyz/p/comp... · Posted by u/FillMaths

loglog · a month ago

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.

loglog commented on TikTok's 'addictive design' found to be illegal in Europe nytimes.com/2026/02/06/bu... · Posted by u/thm

afarah1 · a month ago

>every country that has imposed a considerable sugar tax has seen benefits across the board

Is there strong evidence for that? The first study that pops up if I search this suggests otherwise, that it could increase consumption of sugar-substitutes and overall caloric intake. https://doi.org/10.1016/j.tjnut.2025.05.019

>we need guardrails to defend against

There is no "we". You say that I and others need it, and you want to impose your opinion by taxing us.

loglog · a month ago

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

loglog commented on Ratchets in software development (2021) qntm.org/ratchet... · Posted by u/nvader

loglog · a month ago

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

loglog commented on Antirender: remove the glossy shine on architectural renderings antirender.com/... · Posted by u/iambateman

mlrtime · 2 months ago

Optimizing ad clicking is profitable and the thing that would [partially] pay for UBI. That stops happening and money/value stop being created. The market is not 0 sum.

It's good to talk about UBI, but people taking it seriously have no idea how to fund it.

loglog · 2 months ago

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

loglog commented on Silver plunges 30% in worst day since 1980, gold tumbles cnbc.com/2026/01/30/silve... · Posted by u/pera

SilverElfin · 2 months ago

Taxing bullion is absurd - it’s not a product but more like currency or a placeholder of money you already have. What other taxes are they passing when you say “frenzy”?

loglog · 2 months ago

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.

loglog commented on Kotlin's rich errors: Native, typed errors without exceptions cekrem.github.io/posts/ko... · Posted by u/todsacerdoti

ixtli · 2 months ago

This is nice, and I develop often in Kotlin, but none of this will really achieve what people want so long as any line can possibly throw a runtime exception.

loglog · 2 months ago

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.

loglog commented on Kotlin's rich errors: Native, typed errors without exceptions cekrem.github.io/posts/ko... · Posted by u/todsacerdoti

armchairhacker · 2 months ago

These remind me of checked exceptions in Java. Ironically, Kotlin removed checked exceptions because they tend to be annoying more than useful: there's no clear guideline to whether an exception is checked or unchecked, some functions like IO and reflection have them while others don't, they're verbose especially when closures are involved, and lots of functions simply catch and rethrow checked exceptions in unchecked exceptions.

Which leads me to: why is Kotlin implementing this in a non-JVM compatible way, instead of introducing checked exceptions with better language support? All the problems stated above can be avoided while keeping the core idea of checked exceptions, which seems to be the same as this proposal.

From the GitHub discussion, I see this comment (https://github.com/Kotlin/KEEP/discussions/447#discussioncom...):

> The difference between checked exceptions from java and error unions in this proposal is how they are treated. Checked exceptions are exceptions and always interrupt the flow of execution. On the other hand, errors in this proposal are values and can be passed around as values or intentionally ignored or even aggregated enabling the ability to use them in async and awaitAll etc.

But is this a real difference or something that can be emulated mostly syntactically and no deeper than Kotlin's other features (e.g. nullables, getters and setters)? Checked exceptions are also values, and errors can be caught (then ignored or aggregated) but usually interrupt the flow of execution and get propagated like exceptions.

loglog · 2 months ago

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.