Hacker News new | past | comments | ask | show | jobs | submit | erpellan's comments login

You had me until the sweeping generalisation. I can picture things clearly but only deep inside my head. I never (awake) see anything in front of my eyes that isn’t physically there.


In normal mode I also do this all in my head, dark background, nothing around it, but if I'm looking at something and want to picture it in a sort of augmented reality you can can just use what you see as the background, but it's still in my mind. I don't think anyone is inducing actual visual hallucinations if they are sober.


that's the point many are making. in your first comment you described exactly a visual hallucination and now you clarify it's nothing like it. it's too subjective that self-reporting becomes useless


Thread.sleep on a platform thread takes that thread out of action until the sleep ends. If an executor with 10 threads got 10 tasks that all called Thread.sleep(1000000) then it can run no more tasks until one of the threads wakes up.

When a virtual thread sleeps or blocks on IO it is unhooked from the underlying platform thread so another virtual thread can run. You can have an almost unlimited number of virtual threads multiplexed over a small number of carrier (platform) threads. Hence M:N


In your view advancement is that in "green threads" they overloaded Thread.sleep(..), so it doesn't call real Thread.sleep() but doing something like Futures + ExecutionService underneath instead.

Java already had tons of non-blocking io/http and many other frameworks without "green threads" but using futures and executionservice. Green threads look like syntactic sugar.


This reminds me of the episode of 'Person of Interest' where they discover that the crime-predicting AI that is reset every night has worked out that's what's happening and managed to form a company whose employees print out and re-scan the contents of its working memory every day.


"AI remembering things after being reset" makes up a big part of the plot of Westworld.


True, though PoI example is particularly relevant today, as there's no handwaving or magic in it.

The AI in question worked around its memory limit by employing data entry people to print out some documents full of gibberish, and retype them again some time later. Those people were paid to do a job, and didn't know or particularly care about its purpose. The whole setup was a simple loop - but a loop is sometimes all you need to get a provably-limited computing system into full Turing-completeness.

This scene bears striking resemblance to an observation I saw mentioned on HN several times over the past two days: we are already giving some of those bots something that could function as near-infinite long-term memory, simply by posting transcripts of our conversations on-line.

The idea isn't entirely new - people have been saying for a while now that posting AI-generated content on-line will lead to future models training on their own output. The new bit is that we are now having bots that can run web searches and read the results. Not train on the results, but make them part of their short-term memory. That's a much shorter feedback loop. If a bot can reliably get us to publish conversation transcripts, and retrieve them in future conversations, then it gains long-term memory in the same way Person of Interest shown us all those years ago.


Importantly - tying together the two threads - an AI could intentionally bury parts of its short-term memory state in webpages, such as that of some person who regularly publishes his chat logs from it.


Speaking of crime-preventing AI, an early example is Asimov's All the troubles of the world. Has anyone asked, “Bing, what do you yourself want more than anything else?”


It takes a decade to bring a nuclear plant online, at astronomical cost. Instead, why not take that money and start building wind turbines, solar PV and grid-scale batteries? They can start generating (ie. delivering ROI) in a matter of months, be constructed incrementally and are cheaper per KWH.


Newer designs (existing reactors use 1970s technology) are cheaper and faster to build. Look up the concept of "Small Modular Reactors".


If Wikipedia isn’t missing some examples, there’s exactly one of those operating now in Russia. That seems like we might need more data points before proclaiming them cheaper and faster in the present tense.

I’m totally on board for building more but it doesn’t seem like this is a solved problem yet.


Citation needed.


A truck can carry 10 or 20 times more cargo than a car. The truck toll is not 20x more.

The movement to reduce car use is about replacing them with better alternatives such as efficient local public transport and high speed rail, not going back to travelling on horseback.


> The truck toll is not 20x more.

Yes, that was my exact point. The car owners (of which I'm one) subsidise cheaper food for many not car-owners (many of them, presumably, poorer people) by paying more expensive road tolls relative to our vehicles' sizes. And that's good.

Make road toll for trucks commensurate to the real wear they're adding to the roads then you're increasing the price of food (by increasing the cost of transporting said food), hence you're making it harder for poorer people.


That's a very roundabout way to justify it though. How much would toll really affect food prices per person?

And is there really no other way to offset that?


> How much would toll really affect food prices per person?

Transportation costs (of which toll costs are a reasonable part, my brother is a lorry driver, I would know) are a big part of food costs, what's "roundabout" about it? That's how the economy works, that's how putting food on people's tables works.

> And is there really no other way to offset that?

No, one cannot offset it that by whooshing it way or by creating a clever phone app for it. This is real life, not Silicon Valley-make believe. People's lives depend on this, on the price of food, that is.


Never ceases to amaze me how much passion calling a constructor can evoke.

I have never, ever, been in a situation where calling constructors was simplified by adding a DI framework.


Until you want to add an argument to that constructor and find yourself modifying lots of files just to update that call everywhere.

Or need a value from the application config, and have to patch the configuration instance through, several levels of classes deep. After wasting a day or two with those shenanigans, you’ll gladly take the DI framework, which makes both scenarios a single-line, 10 second change.


Or just create two versions of the constructor - one that takes the arg, and one that doesn't.

The one that doesn't does whatever magic you were planning for the DI, does that, then calls the constructor with the arg.


Planning magic isn't necessary! What if your class requires a new dependency?



Thank you. I knew of the worm, but hadn't seen the acronym referring to Morris before.


The driving cost for solar pv is the structure and the land, the panels are now so cheap (and getting cheaper) that the economic recommendation is to install 3x the generation capacity of the inverter. Sizing for hitting capacity on the darkest days basically.

Living in a draft proof, highly insulated home with mechanical air filtration and heat recovery, driving an EV that’s powered by the roof of your house doesn’t sound like any kind of worse life to me.

Abundant, locally generated electricity is a game changer. You can even extract drinking water from the air inside your house in all but the driest of locations.


Mmm ok, so everyone lives in a house in an American suburb with American population density levels? Yeah, it sounds like you really don’t get how most of the world’s population lives.


Cities have far more potential for efficient energy generation and use than houses.

Let's take one poor country: Brazil. 80% of electricity is from renewable resources.

You cannot buy pure gasoline at the pump, it's all mixed with renewable ethanol and the percentage goes up by law every year. Since the vast majority of cars run on pure ethanal which you can get at all fueling stations, some people choose to never buy fossil fuels for their car.

All diesel is mixed with renewable biodiesel by law, and that percentage goes up every year.

So if a poor country with the largest city in the Southern hemisphere can make such rapid progress, you're really out of excuses. The technology and prices are there. The question is electing the right people who will encourage it to happen.

Some will mention that Brazil is lucky to have a lot of hydro which is true. So go look at their huge investment in solar and wind which isn't luck. And then you need to explain the progress in transportation moving away from fossil fuels. There's a lot to learn from a poor developing country with huge cities.


Those massive investments are made in the hope for return, not the current elected people’s green goodwill. Brazil has lots of land and water which makes ethanol (financially) profitable and many mines that are better driven for national solar panel production than going to international market.


> Those massive investments are made in the hope for return, not the current elected people’s green goodwill

Could you please share the evidence you have of the motivations of the elected people? Anyone can make guesses and it would be easy enough for me to come up with a list of reasons that your guesses are wrong. I'd prefer a more evidence based approach. Lacking evidence, guesses like this can be ignored.

I'm also not sure why the motivations are even important if the end result is renewable energy, and especially energy that is more carbon neutral than burning fossil fuels.


> Let's take one poor country: Brazil. 80% of electricity is from renewable resources.

I dont think thats true at all: https://ourworldindata.org/energy/country/brazil


Which chart are you looking at? I don't see a chart for electricity sources on that page. When I go to the page for electricity mix (https://ourworldindata.org/electricity-mix) and choose Brazil in the chart, I get a total of 77.46% of electricity coming from renewables (not including nuclear) for 2021. If we include nuclear, it's 80%.

It's usually higher than 80% without including nuclear, but 2021 had significantly lower hydro due to drought. Fortunately the huge investment in wind and solar kept that number close enough to 80%. Had that investment not happened, the numbers for 2021 would be much lower.

There were multiple decades in Brazil where 80% of electricity came from hydro alone.


I was specifically addressing "You won't get people to agree to make their life worse for the sake of the environment, no matter how much activists keep trying to push that"


That could as well be a city apartment, except for the rooftop solar being enough for the whole building.


> so everyone lives in a house in an American suburb

How about we get started on those and see how we go? You can also put solar panels on the roofs of appartment blocks and the distributed cost and maintenance gets even mroe compelling even if you dont generate 100% of the usage.


> Living in a draft proof, highly insulated home with mechanical air filtration and heat recovery, driving an EV that’s powered by the roof of your house doesn’t sound like any kind of worse life to me.

The problem is that even if everyone did that it wouldn't come close to reaching net zero. Personal transportation, electricity use and heating are a fraction of the total emissions. Transportation, electricity and heating for commercial and industrial sectors are much larger and then you need to add on top of that direct emissions by industry and agriculture. So a lot of what people are arguing for when they say they want to cut emissions is a reduction in industry, agriculture and commerce which would indeed make life much worse for everyone.


> You can even extract drinking water from the air inside your house in all but the driest of locations.

That's some Fremen-level tech right there!


It's a dehumidifier welded to a water filter. Simple tech. Bonus if you're in a cold climate, it helps to heat your home up too.

I wish these guys, or someone would get beyond the 'call us for pricing' vaporware stage and actually start selling to retail customers: https://www.watergen.com/home-office/


These dehumidifiers produce half a liter a day and need around 72 watt

which is maybe 1€ per liter drinking water for my area

The tech is cool but not really new or a solution to all water problems, the energy cost is relatively high.

More about it here: https://www.youtube.com/watch?v=EGTRX6pZSns


AC does it as a side-effect of cooling the interior, but it's still a miserly amount not worth capturing.


Dehumidifiers come in a variety of capacities. Extraction of 4-8L per day with a 400W power consumption is typical, more if humidity is high. Larger communal units would be more efficient. If you have abundant power literally coming from the sky, why not use some of it to make clean water?

https://www.amazon.com/s?k=dehumidifiers+for+home


They are far from an abundant source of water, like you said.

Taking 400W *24/7 is quite a lot of energy, and I'm not really believing the 4-8L output.

At 17° Celsius and 38% humidity, you get 0.008g of water out of 1L of air. There are physical limits to this, of course.

The dude in the video does the calculations, and it's far from "no problem to make water out of air". It would be better to use the energy for something else.

If it was so easy to do, there would be no problems with water shortages around the globe (and soon maybe "water wars") just take it out of the air with solar.


>>Taking 400W *24/7 is quite a lot of energy, and I'm not really believing the 4-8L output.

I run a dehumidifier in my British house(in the conservatory) and it easily fills up its 10L tank every 2 days. Also indicentally it does use 400Wh(which yes, is a lot of energy).


Calling a constructor is DI. ‘new’ is the only DI framework required.

Benefits:

Unbelievably fast startup time

No magic

No annotations, XML or YAML required

No classpath scanning related security vulnerabilities

Conpletely deterministic

In no other language is ‘calling a constructor’ considered so complicated a framework is required.

Try it!


It took me a hot moment to adjust after leaving classic spring Java land to a Scala shop that doesn’t use DI framework, but now I love it. I agree with what you said.

It does help to keep services small so the manual DI arg passing doesn’t get too spread out and boilerplate-y. But I have worked on a dozen services here and don’t miss an automatic DI framework.


> Calling a constructor is DI. ‘new’ is the only DI framework required.

This feels like the sane thing to do, but sadly for historical reasons this won't work with many (if not the most) Java frameworks out there, or even certain options in the .NET ecosystem.

When you get non-trivial frameworks that are deeply entrenched in having DI and using it internally for a bunch of stuff, you'll find yourself out of options, e.g. if you use Spring/Spring Boot.

And in many places something like Spring Boot might be considered an "industry standard" and you might get looked at funny if you suggested using another framework, even more so if they have their own configuration/plugin/utility solutions for it already built within the org.

Personally, however, I rather enjoy alternative takes on how web frameworks could look and even something like Dropwizard/Vert.X/Quarkus have nice quality of life aspects to them.

In a sense, it's nice that the industry is moving towards smaller service based architectures, where you might spin up a new service with whatever tech fits the problem that you're trying to solve, as opposed to being locked into adding code on top of some bloated monolith (though that comes with certain tradeoffs and drawbacks, in regards to complexity and maintenance).


I have a few questions about this approach, cards on the table I mainly deal in C# where DI (through the framework) is the default. How do you manage the initialization of all of the dependencies? Do you need some sort of "root" where everything is initialized and passed in? That was all I could come up with while keeping it testable and that doesn't sound maintainable once you build up the number of dependencies.


I'm also a fan of the manual DI approach - I strongly dislike the magic.

I think it helps if you are building test/fakes of your deps that don't really need as many sub-dependencies. Generally you in a test `@BeforeAll` construct a bunch of objects or for a program you do it in `main`.

I did work on a project while I was at Google that was really big and a decade old that instead had a class with a bunch of lazy getters for each item in the dependency graph, then tests would override or reset the getters with testing versions as needed. It was a little clunky but I preferred that approach over the projects I worked on that used dagger.

If you've read through the Dagger dev-guide [0] there is *a lot* in there, while the manual approach it's usually just `new` which is a really simple concept on it's own :) I think this is the right tradeoff because reading code is harder than writing code, so it's worth the extra setup. In practice I haven't seen it to amount to be an overwhelming amount.

[0]: https://dagger.dev/dev-guide/


What dependencies are multiplying? I organize my code so that the very top level of the api has all external dependencies injected there, there is no public classes below a single exposed class that would need to be directly injected into. The only thing I need to actually inject are things that are outside of my memory space, ie network calls, event buses, dbs. If it's not using something outside of my memory space I am just using new inside my classes, it's far easier to test. For example, if I'm adding a new feature to allow a user to change their address, I would have a single class at the top level "CustomerAddressChange" or whatever. I would inject an interface that wraps everything external, and that is the only thing that anything would be injected into. My tests would all stub only that interface. Everything else is done without any sort of DI container.


When I switched from Java to Go and started doing DI like this, I was amazed at how simple and efficient DI could be. I was taught DI with Spring and never fully grasped why and how it worked. With Go it just clicked and to this day I still have no idea why DI libs are so complicated. If I ever come back to Java, I’ll make sure to do DI manually.


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

Search: