Hacker Newsnew | past | comments | ask | show | jobs | submit | teitoklien's favoriteslogin

WebP is a terrible practice and and it has no real value vs jpg https://pagepipe.com/dont-use-webp-image-format/ - just because endorsed by google doesn't mean it's good (i would even argue, the contrary is true)

There is a point still, because a star is massively more efficient at fusion by way of "production at scale" effects.

The additional benefit is the amount of power. With the power of a star at your disposal, beaming your energy using lasers and microwaves, even if only 1% efficient, would instantly solve the energy needs of any planet in a solar system. If we did it, we could instantly colonize all planets in our solar system because things like "running an AC on Mercury" or "Hovercraft in Jupiter Atmosphere" becomes trivial when you have limitless power.

Heck, you could start projects like moving planets in orbits or collecting astroids to built a planet if you wanted.

Black holes are the stage after that since you can use a spinning black hole to convert a given mass into energy at >10% efficiency (given E=MC^2). That would allow a civilization to power multiple solar systems at the cost of a few planets per year.

Granted, the sphere is difficult to build, but that is what you have dyson swarms for.


> You'd then have two environments where life could evolve completely independently.

Earth definitely has places where evolution happened in a more-or-less isolated environment for a long time, though probably not from "zero".

For example Movile Cave: Life in the cave has been separated from the outside for the past 5.5 million years and it is based completely on chemosynthesis rather than photosynthesis. https://en.wikipedia.org/wiki/Movile_Cave

Look up pictures from that cave at your own risk. Personally I think those critters are the stuff of nightmares.

I don't doubt there's an uncountable amount of ecosystems on Earth we haven't even found, much less understood. We (literally) have hardly scratched the surface of this planet.


I'll be reading Domain Modeling Made Functional [1], which seems fun as it applies F#/ML/FP concepts to "enterprisey" DDD.

[1] https://isthisit.nz/posts/2019/domain-modeling-made-function...


Spam seems pretty "solved" (if one can call it that) problem nowadays though. Most people who run their own servers simply put SpamAssassin and a couple of other tweaks; not much fuss is needed anymore.

A lot of this work has been research of Dina Katabi at MIT, via a function called the Sparse Fourier ("4-E-A") Transform.

I am not excusing the privacy implications, which will be abused to the extreme. However, it will be used also for health reasons, like monitoring respiration, and activity.


This is real, and it's also a type of sexism. Not all forms of sexism or discrimination are acts of malice. The sexual harassment training required for my job speaks explicitly about disparate treatment.

I do question one of the examples a bit. The idea of giving advice to female founder to step down as CEO in favor of a male cofounder sounds like bad advice. It's pointing out one rather drastic solution, rather than the actual problem. Better advice would be to lay out the observed issues and help think through a range of possible solutions, if everyone can get on the same page about the problems. Maybe the solution would still be a change in roles, but there's a lot less chance it would seem sexist the advice were predicated on a lot more information.


Neat concept. Exploring the difference between what successfully compiles vs. what won't seems like a great way of getting more familiar with the language.

I've written a little over 1,000 lines of Zig at this point and I really like it. I think its key feature is a rich compile-time imperative programming environment ("comptime"). If you can have full compile-time imperative code execution, you can get a lot of the benefits of more complicated language features (like C++ templates) "for free."

In C++ templates are "a language within a language", but even templates with all their complexity cannot solve all of the problems you might want to solve at compile-time, so C++ has been gradually expanding its compile-time code execution features so that more and more of the language is available at compile-time (constexpr, consteval, etc). Zig jumps straight to the finish line by making most of the language available at compile-time from the outset, and in doing so avoids the need to add the complexity of templates in the first place.

Having "slices" as a first class type feels like a general and powerful solution to the problems that std::string_view and std::span are trying to solve.

I am comparing Zig to C++ a lot, which many Zig fans would probably take exception to as Zig does not aspire to be a better C++, but rather a better C. Indeed many key C++ patterns like RAII are explicitly out of scope. But to me Zig bridges the gap between C and C++ by solving many of the problems that make C feel too spartan without jumping to the incredible complexity of C++.

There are a few things about Zig that give me pause. I've noticed that compile-time feels like a very lazy environment, meaning that functions do not seem to undergo full semantic analysis unless they are called from somewhere. You can write a function that compiles successfully, leading you to believe the function is syntactically and semantically coherent, only to find that when you add an actual call to that function, the compiler now flags errors inside that function. This adds some friction to development, because the act of writing a function is no longer a self-contained activity. Writing the function feels more like sketching it; later when you actually call it you have a new set of compile errors to contend with.

I also miss tools like ASAN to catch memory errors. I'm guessing things like that will come with time.

Overall I feel very positive on Zig.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: