How about possibly also failing for being too US centered, basically being an "internet portal" but mainly for the US. Sure Yahoo where _huge_ 2000, but it was never the main goto portal in Scandinavia where I grew up using internet from the mid 90s.
Here Altavista was the defacto standard for search until Google replaced. For the portal aspect of Yahoo, there were local alternatives with more relevant material.
Of course it possible to limit the number of virtual threads. A web server can have a limit on number of virtual threads too, and queue incoming request before dispatching to to workers (virtual threads).
As other have said, this can be achieved with a semaphore and the bulkhead pattern. You can also limit the number of number of connections.
I would expect any "production ready" web server using virtual threads having some sort of limiting. That must be the case right?
"This seems rather … procedural. Even though we get all the nice guarantees of working with side effectful functions in Haskell, the code itself reads like any other procedural language would. With Haskell, we get the best of both worlds."
Working with the IO monad is much more complex, especially if you want to use other monadic types inside that code.
> Working with the IO monad is much more complex, especially if you want to use other monadic types inside that code.
Yes, mixing other monadic types with IO can be a challenge. One possible solution to that is not just not use other monadic types inside the code. Just use a general-purpose effect system instead. I recommend effectful or Bluefin (the latter my own project).
For me it is if in a cosy position and doing something cognitively demanding. Fell asleep very often during my university studies reading literature. It can happen also if trying to learn something new technical at work, but only if I don't sit at a desk.
> The main benefit of Liskov's substitution principle is ensure developers don't need to dig into each and every concrete implementation to be able to reason locally about the code.
Yeah, but doesn't help in this context (enable local reasoning) if the objects passed around have too much magic or are mutated all over the place. The enterprise OOP from 2010s was a clusterfuck full of unexpected side effects.
I suspect that enterprise anything is going to be a hot mess, just because enterprises can't hire many of the best people. Probably the problem we should address as an industry is: how to produce software with mostly low wattage people.
It is still true what she says. Having an interconnected electricity system is problematic when countries like Germany misbehave by having a horrible energy politics.
That said, it would had been better in Sweden if they hadn't phased out nuclear too! There is a electricity shortage in south of Sweden where industries are denied establishing new initiatives.
Sweden has an overproduction of energy, it is just generally generated in the north (where the hydro is) and consumed in the south (where the people are).
The 'shortage in the south' is just a political lens for explaining the high prices from the introduction of energy zones in 2011. Before then, there was one price for electricity in Sweden and this worked to the benefit of the consumer.
Stepping back, do we really want the south to invest in _generating_ electricity? And if so, at what granularity? At the kommun level, or the län? At what point is that granularity ok but the whole-of-Sweden granularity that we had before the privatisation push is not ok?
It's a single power grid but the transmission lines north->south are insufficient to carry all the potential electricity generated by hydro at peak production.
Actually this is a good thing. There's demand for energy so prices go up. This in turn makes investments in energy generation in Sweden more lucrative since they apparently have a lot of energy revenue coming in from abroad to finance more such projects. There are a lot of renewable energy projects in and around Sweden and the wider region. And of course they are actually manufacturing and exporting a lot of wind turbines as well. Wind technology is a substantial part of their economy.
There is no energy shortage in Sweden. They can export as little or as much power as they want. But of course with prices being high that means they export a fair bit and that causes prices to rise. Which is causing Sweden to make a lot of money from this business.
If they want lower prices locally, they should look at their local energy market, infrastructure, and regulations instead of blaming the Germans for being able to pay market rates for energy to Sweden.
It is but that doesn't help us here in Sweden, we pay the highest bid price for the electricity generated here but being exported.
The last government at least put in place windfall taxes to pay us back during the massive cost increase in the first winter after Russia invaded Ukraine. We got compensated a few months later the prices went insane. The current government already said they won't do that, which is rather absurd since a lot of our electricity is generated by Vatenfall, a state company.
Long-term, macro whatever it may be a good thing I suppose, but short term, the average are suffering under multiplied energy costs. Monthly bills are still double that of what they used to be and any government compensation measures have long ended.
End users should not suffer under government / market fuckery.
This type of "hurr more money good" thinking is exactly the reason why there's a massive energy crisis across Europe, where individuals and enterprises end up paying gigantic electricity bills. People are _dying_ from this situation. Energy is not a random market like any others where number goes up means everything is good. _Lives_ depend on it.
Java is definitely not even close to being "highly expressive". It has been a very simple language, and was always very conscious of remaining that with a slow, but well-thought-out evolution, learning from others' mistakes.
Hmm maybe I'm too out of touch. You're talking about recent java (12+) vs go ?
I stopped working in java so maybe I'm too bruised by the J2EE 5 era, but what I saw from Go was an order of magnitude less verbose than my memories of java.
Please don’t take this rudely. But if you haven’t used a language or looked into in over a decade perhaps you shouldn’t comment on it?
That being said you should really check out how streams, records, switch expressions, pattern matching and all of the recent additions in the last 5 years have made Java a magnitude less verbose than Go.
- a ton of java is still legacy, ask works with java 7 vs java 17 and enjoy the laugh
- I assumed java culture was still too rotten by its roots. I've used streams but whenever I have to import BiFunction I feel very sad.
on the other side, the few go code I've seen was always very concise, or even when the code base wasn't very well designed it was, at worst, still below java
Only 2% [0] of runtimes are on Java 7. There is a large majority on 8 still and 45% are running Java 17. That being said Java 8 is still less verbose than Go. The number of lines needed to do basic programming like iterating collections or error handling is a magnitude larger in Go.
You’re basing your opinion on your feelings rather than objective facts of being in the ecosystem. Yes you may have to import BiFunction but that isn’t anymore verbose than having to write:
Java EE was/is a whole platform, framework, deployment model all in one.
Also, most of the verbosity of that early version was very high flexibility (everything could be replaced) plus an XML-based configuration. I wouldn't really count XML in Java's verbosity, nor do I think that comparing it to vanilla Go is meaningful.
For similarly scoped libraries Java is less verbose due to go's error handling being all over the place.
