necrobrit

Speaking as someone from Edinburgh where the locals are notoriously jaded (ask someone that has lived in edi for a few years what festival shows they went to this year): It's more that we _forget_ rather than never knowing.

Asks me what cool things to do nearby on the spot and I'll probably draw a blank. But say what you are doing instead and I'll probably go "oh yeah! That's brilliant! I love thing X".

I do know where good dog walking spots just outside Edinburgh are though, and I'm still regularly discovering more because I'm effectively a tourist ;).

Well, sure, it's all relative and no system is perfect. Not every mother is perfect, doesn't mean I escort mine around the house at gunpoint whenever she visits.

> Many Europeans support this - they don't understand how government censorship can quickly get out of hand.

This argument can be made for government in general, although granted technology does make it easier for a smaller group to overreach. I'm a European and do hear your concern, but I feel comfortable supporting restrictions on speech _as long as_ there is also a functioning and just legal system that those restrictions operate within. Though there does seem to be a worrying trend towards technology bypassing the legal system and just giving enforcement agencies blanket access of late.

We all also have our own cultural biases and blind spots. I offer this not as whataboutism but as a different perspective: I'm _way_ more frightened by the authoritarian police culture (I base this on interactions with the police in a period I lived in the US) in the US than I am of the UK governments internet censorship. The internet censorship could do a lot of harm, but I think not as much potential harm as a large militarised police force willing to bust down doors on command from above.

Table buckets are currently quite hard to use for a lot of use cases as they _only_ support primitive types. No nested types.

Hopefully this will come at some point. Product looks very cool otherwise.

Good point!

Yes _however_ the nodejs benchmark at least is handling each message asynchronously, whereas the go implementation is only handling connections asynchronously.

The client fires off all the requests before waiting for a response: https://github.com/matttomasetti/NodeJS_Websocket-Benchmark-... so the comparison isn't quite apples to apples.

Edit to add: looks like the same goes for the c++ and rust implementations. So I think what we might be seeing in this benchmark (particularly the node vs c++ since it is the same library) is that asynchronously handling each message is beneficial, and the go standard libraries json parser is slow.

Edit 2: Actually I think the c++ version is async for each message! Dont know how to explain that then.

Data is a bit light on the ground given we haven't had masses of EVs for all that long. But I wouldn't necessarily have this expectation based off of phones and laptops.

EVs have really high-end battery management systems and cooling, which will have a huge impact on battery life.

Heck even my phone is lasting better these days with just better software battery management in Android. My current oneplus 9 is going on three and a half years old and hasn't notably degraded in battery life. Whereas I'm pretty sure I remember all my previous phones having noticeable battery degradation after a year or so.

Definitely preferable to intersections. A roundabout means there is only one place to look for oncoming cars, rather than potentially 4.

Although ideally the crossing on a roundabout should be set back so far they arguably aren't even on the roundabout... so space is an issue.

The preference for 4 way stops in a country that otherwise prioritises traffic flow so much is really jarring. Traffic lights too to some extent.

About 5 years ago my wife an I were doing a California road trip. At one point on a relatively rural road -- I think it might have been Dry Creek road heading into Napa but cannae mind exactly -- we got stuck in traffic for around 45 minutes. We thought there must have been some huge accident or roadworks closing the road. But got the the end and nope... 4 way stop essentially letting one. car. through. at. a. time.

I distinctly remember exclaiming "why the f wasn't that a roundabout" after clearing. Funny that it is now one of my strongest memories of that trip haha.

>You cannot just take one part of that system and expect to magically reap the benefits.

Yeah, specifically people only focus on the "repo" bit. Build system, PRs, history browsing, etc all get handwaved away after you stick all the code in a single repo. These are the extra hard parts though!

I think if you were to properly implement "monorepos" in git world it would actually look a lot like a Github _organisation_, rather than a Github repository. Each git "repo" in the "org" would be a workspace with it's own segregated UI so that you can for example check out just that workspace, or see only that workspaces commits or issues -- but some features such as github actions workflow triggers and PRs would be able to span multiple workspaces.

Github doesn't really seem to have put much thought into really supporting monorepos though. They have added some support (e.g. codeowners) to support "repo"-as-monorepo, but have also added some features that could go towards supporting "org"-as-monorepo (e.g. dependabot dependency updates and the dependency graph). But it all stops well short of a complete monorepo toolset.

> It seems to be a necessary evil for a company to grow

Yep, the needs of a company change when and if it grows. Early days, a small team "getting shit done" is probably what you want to find your place in the market, make early customers happy, etc. But as you scale on all axes: time, headcount, headcount turnover, customer count, feature count and so on, that early pile of shit that got done can start to bog you down. Even worse if no one recognises the need to change and continues adding to the pile.

I've seen a few really brilliant engineers struggle with this in various ways: 1. Start hating their job but being confused because they love the company -- not realising that the company has become a very different beast to the early days. 2. Struggling to get out of the "get shit done" mentality and just floundering. Even becoming a net negative contributor in some cases.

Worth remembering this I think in an industry where rapidly changing companies are so common. Your company might be a good fit _now_ but that does not mean it will stay that way!

100% and one of the great things about k8s is that this diagram applies to essentially any application. Standardisation is awesome.

I'm not convinced you read your own links.

1. Is a report on the need to evaluate how prevalent the practice of recycling food scraps from manufacturing as feed actually is, as apparently the FDA (or the author of the report anyway) doesn't have access to good data on the topic.

2. Is advice that appears to be targeted at large institutions that want to _start_ recycling... doesn't really say much about the prevalence except that it isn't a novel idea.

Plus, the original article says: > Individual households were responsible for more than half of that, with the rest coming from retailers and the food service industry.

I can immediately think of a counter example: corps vs corpse. Literally from the same word origin, wildly different pronunciation.

Interesting. This is a pretty common criticism of unions in the anglosphere as well -- often alongside a note that the problem has been "solved" in Germany via worker codetermination.

Have you found this situation to be universal in Germany or only at some employers? This is one of those things I'd actually expect "the market" to be good at regulating. Bad union or management kills a company, company with better management or union fills the market void etc...

Seconded! Odersky is a great lecturer (and very practical lecturer despite Scalas "academic" reputation) and the course was very well organized.

I did the course on the first or second run however, not sure if it has been kept up to date or if it is still well run.

Was disappointed with the follow up courses though, the lecturers didn't live up to Odersky.

I think something has been lost in translation here. At least in the US and UK, responding with "Not really" to a statement usually implies that the statement is completely incorrect. As in, you aren't offering a simple correction from "everyone" to "a majority", but rather suggesting that it isn't even a majority.

It's both... simultaneously.

The "feature set" really is smaller than Java or Kotlin (especially if you count in terms of "keywords as features" and ignore things included for Java compatibility).

The flexibility though can be genuinely overwhelming (the name, scala[bility], refers to scalability of the syntax, not performance). Both in terms of the syntax flexibility , e.g. where curly braces are optional vs not or different ways of writing lambdas, and powerful/flexible features like implicit. However there are very rarely special cases to these, it's all very consistent once you know the rules.

Even the infamous underscore is "logically" consistent in it's use, it's just a placeholder in both contexts you typically see it used (context of variables and context of types).

Even my go-to example of a special case in scala, vararg unpacking:

`foo(myArgs: _*)`

Despite being a special case actually reads kind of consistently.. it reads like a type ascription[1] asking for myArgs to be treated as a varargs of whattever type. So consistent with other "type context" usages of underscore despite otherwise being weird.

[1] https://docs.scala-lang.org/style/types.html#ascription

That's an excellent deadlift if you are doing it for reps.

Handy for reference: https://symmetricstrength.com/standards#/90/kg/male/-

Really looking forward to this dropping! Writing complex data out of spark jobs is super easy, but getting it back into strongly-typed-Scala has been a big pain point.

The experimental release is a bit broken though, encountered a pretty big bug: https://issues.apache.org/jira/browse/SPARK-12714

concurrent.futures isn't really _another_ parallel library... its just the standard libraries higher level interface to both the multiprocessing and threading modules.

See the PEP: https://www.python.org/dev/peps/pep-3148/

Wow, yeah, this thread: https://forum.filezilla-project.org/viewtopic.php?f=1&t=3294...

I think it is best to avoid these guys.

> you’d measure how many days they’d last at the optimum temperature and match the gelatine formula so it would also last the same amount.

Because the gelatin will also respond to sub-optimal temperatures and spoil faster. Presumably this means you could reasonably set the gelatin tag to the actual point of spoilage for the product -- rather than the 'peak freshness' current 'use-by' dates usually represent.

A curriculum of books to go along with these would be great.

The thing with online courses / video series is that they can give you a great introduction to the topic, but it is often difficult to know where to go next for a deeper understanding!

Also useful for filling in gaps of prerequisite knowledge e.g. "before diving into this stats book, make sure you understand the concepts from this basic algebra book!"

Interesting how the various Scala frameworks have been slipping down the charts from round to round -- an effect of changing methodology?

Back in my uni days, aka not that long ago, the scala (which I love)/perl (which I hate) comparison is what made me realise that language arguments are almost always pointless. Any choice you make in a certain class of language is probably going to be roughly equal in terms of ease of use, productivity, whatever; so you might as well just go with what you are comfortable with.

Does that 'or' method actually exist in a library somewhere or was it just for illustration?