Hacker Newsnew | past | comments | ask | show | jobs | submit | DinaCoder98's commentslogin

I've always wondered what the semantics of "national security" are when the deployment of this phrase led directly to 9/11


gRPC is for long-lived services (and connections). Combining it with lambda doesn't make much sense.


If only there was some kind of long-lived proxy you could put in front of things that would handle connection pooling and would forward requests onto a short-lived backend, scaling up instances as needed to serve those requests.


Ok, this would still obviate the use of gRPC on lambda


Why?


The idea the individual consumer is responsible for policing industry is farcical on the face of it.


The individual consumer cannot police the whole industry, but they can choose what part of the industry they support. If many care, they can make an impact.

And that's the crux. Many, or most people don't give a shit. Not about climate change, not about plastic in the ocean. Not about animals living in factories without seeing the sun ever. They care about their immediate surroundings, their taxes and the money in their pocket. They don't want further problems, someone else should take care of that (unless it increases taxes).


> but they can choose what part of the industry they support.

Sometimes they can, sometimes they can't, sometimes it's up to what they care and focus about.

> If many care, they can make an impact.

Sure, theoretically. Expecting any results seems like a fool's game though. Who would bother when the state is right there and perfectly capable of making rational decisions better than any individual consumer could?

> And that's the crux. Many, or most people don't give a shit. Not about climate change, not about plastic in the ocean. Not about animals living in factories without seeing the sun ever. They care about their immediate surroundings, their taxes and the money in their pocket. They don't want further problems, someone else should take care of that (unless it increases taxes).

Yea, it's almost like this is a "tragedy of the commons" issue known to be extremely difficult to impact by individual decision making. And who can blame the individual? Who could shoulder that responsibility and emerge sane? The only entity involved one might expect to make a difference is the state with their ability to override the inherent irrationality of the masses.

Christ, what are people being taught in school these days?


"Who could shoulder that responsibility and emerge sane? The only entity involved one might expect to make a difference is the state with their ability to override the inherent irrationality of the masses. Christ, what are people being taught in school these days?"

Don't worry, they still teach everyone, that states are the only solution. They don't really teach, how that works, though. If a state is composed of lots of small parts with "inherent irrationality of the masses". Yet somehow when it is a state, it is suddenly sane?

Very convincing. Except that most states are rather busy with war now. The main thing they do to combat climate change, is talking and making resolutions how the world should look like in 2050. And in the superpower number 1, people will soon have the sane decision to vote for one, or another old senile person to fix their problems. I am sorry, but the data does not seem to support your hypothesis.

My thesis rather is, that the way the states are teaching everyone in general is flawed in the first place. And this is why most people have no understanding about fundamental things. But now they have the excuse, oh, I cannot do anything, but the state can. Very comfortable.


> Christ, what are people being taught in school these days?

Seriously. What is it with the young kids these days and their several-decades-old faux-environmental schlock


> their several-decades-old faux-environmental schlock

Sorry, what are you referring to?


> The individual consumer cannot police the whole industry, but they can choose what part of the industry they support

This is true. Because I know the lies about recycling plastic are just a myth, I personally always shop at the store that doesn’t use plastic, furthermore to spare the environment I don’t drive my car there, I ride my unicorn instead. /s

The myth that plastic can be recycled is harmful. The myth that personal responsibility has any impact on these issues is another harmful myth. Chosing paper over plastic at checkout doesn’t matter at all. Any change that could make any real impact has to be institutional or political. Those pushing us to ignore this are the ones who want to avoid such changes.


"I personally always shop at the store that doesn’t use plastic, furthermore to spare the environment I don’t drive my car there, I ride my unicorn instead"

Well, I do ride my bicycle to my local farmer store, where I can indeed buy things with very little or no plastic. I also drive my car to the bigger store to get everything else, but some years ago, I only had the big plastic store option. This local store did not came into existence, because it was mandated by politics. But because there was enough consumer demand for it.


Is there any evidence that x86 can compete with arm on per-watt computation?


I don't have numbers, just a hint-motivated question of how much improvement Apple's silicon has seen post-M1 compared to the competition. I've been lead to believe x86 has improved more in the same time period, but I'm too far removed from the details to back it up.


>Is there any evidence that x86 can compete with arm on per-watt computation?

x86 vs ARM? Yes. Plenty

x86 vs Apple's Implementation of AArach64 from A14 to A16? Not yet. We will soon have news from Intel and AMD Zen 5.


The reason we have bloat is it's easier to satisfy stakeholders if you don't give a damn. There's really no reason to discuss this at all once you realize this.

But of course, ranting and reading rants is satisfying in its own right. What's the problem?


I'd agree if our society had figured out any sane way to respond to crime in the first place, but that seems even worse than our barely extant resources for drug addiction in the first place. Somehow we're more willing to pay out the ass to make people feel bad than we are to make them feel better.


> Async work is generally slow and terrible, at least for the pace that you need to achieve to succeed.

Really depends on the work that needs to get done. Sometimes it's just a matter of time and work that needs to be put in, and async work is perfectly suited to that.


> And then everybody proceeds to write their own String library anyway.

Is this true? It was (is!) certainly true for C, but C has an especially emaciated expectation for string processing primitives. Any runtime developed after like 1995 that I can think of has fixed this by providing a sane string implementation people generally agree upon.


If you care about Unicode for real, yes.

Rust and Go both don't have a builtin package for grapheme iteration - and many naively (and incorrectly) think that a 'Go unicode rune == "character"' in Go. I assume the same happens with Rust `char` type.

If you care about unicode-aware string sorting (you should), rather than the naive string sorting the Go and Rust standard libraries provide out of the box... then you probably want a proper Unicode library.

I think the only language that gets Unicode 'right' out of the box is Swift, as it actually provides grapheme iterators, Locale awareness, etc. - but it comes at the cost of the language being tied to the (ever-moving) Unicode standard.


> I think the only language that gets Unicode 'right' out of the box is Swift, as it actually provides grapheme iterators, Locale awareness, etc. - but it comes at the cost of the language being tied to the (ever-moving) Unicode standard.

I think this might (at least partially) be why Rust's stdlib doesn't have this. If it did, then support for it would be tied to Rust's release schedule and which version of Rust you're using. Granted it is every six weeks, and it's usually trivial to update, but that's still a connection that could be an issue.

By having this be in a separate library it means that it can update as and when it needs to, and it's not inherently connected to a specific release of Rust.


I was pessimistic about grapheme-based orientation towards text, deleted it to research more, and I've come to the conclusion that this is simply not a consensus opinion. Can you give me an example where grapheme-based sorting makes a critical difference from codepoint-oriented sorting on a normalized text? Full unicode composition certainly seems to provide a reasonable solution with western languages, CJK characters, and romanization of CJK characters, but that leaves a hell of a lot of scripts that I don't know about.

I mean unicode is incredibly complex, but it doesn't even seem like there's a consensus outside of swift's string implementation of what a grapheme even is.

(Granted, this might support the above concept that people can't even agree on what a string is, but unicode code points seems like a reasonable baseline to expect from a modern language. That said, rust doesn't even include unicode normalization in the standard library, although the common crate for it seems like a reasonable solution.)


The issue I am aware of is with the Thai language that has zero-length unicode codepoints that get superimposed on the preceding non-zero-length unicode codepoint preceding it (or if none is present, an 'empty' non-zero-length placeholder). A non-zero-length unicode codepoint can have multiple zero-length unicode codepoints following it. (In Thai, no more than 2 for morphemically correct words.) For sorting, a normalization needs to happen in the order of these zero-length codepoints in order for unicode codepoint sorting to be correct. The standard practice in Thai is to have vowel signs before tone markers.

In recent years, application support for this has greatly improved.


> it doesn't even seem like there's a consensus outside of swift's string implementation of what a grapheme even is.

Linguistically it's easy, graphemes are the squiggles people actually draw, as distinct from how a machine encodes them. Of course since people aren't a single individual with just one consistent opinion that does mean there's room for nuance - maybe some people think this is two separate squiggles.


Even PL/I has better string handling than C.


Nope. It's not at all fixed because nobody can ever agree on what a "String" is and what performance guarantees the underlying data structure should provide.

Let's just assume a String is UTF-8 to make things "simple".

Is a String mutable or not? Should mutable and immutable Strings have the same underlying structure? If mutable, is a String extensible or not? Can a String be sliced into another String? Can those slices be shared? Should you walk across codepoints or characters (which could be multiple codepoints due to combining)? If you want to insert a codepoint in the middle of a String, what are the performance guarantees?

I can go on and on ...

"String" really has to be a library as there are simply far too many permutations once you step away from "Shove ASCII to tty".


Well sure, people may colloquially refer to a lot of things as "strings"—hell, you could refer to all sequences as strings if you just wanted to argue with people—but the idea of trying to encapsulate this all in the standard library in a single implementation seems confusing semantically and of questionable value. It seems a lot easier to work with a reasonable interpretation of a string with its associated tradeoffs—which again is implied by most standard libraries.

That said, I personally would balk at willing adopting any runtime that didn't enable iterating over a sequence of unicode code points, whether they be stored as utf8 or some 16-bit form, from a string of bytes in 2024 unless I were guaranteed to avoid having to deal with text processing of free-form human input.


> If you're constructing invalid `str` you already have severely fucked up.

Presumably it'd be better to know this immediately on initialization of the variable rather than at some point in the program that actually expects valid utf8—god forbid you transmit or persist the data before this happens.


That's why str::from_utf8 returns Result<&str, FromUtf8Error>. And if you know the string is UTF-8 encoded and don't want to pay the cost, there's `from_utf8_unchecked`, which is marked unsafe.


Ah, I thought you were referring to the benefits of such a system as compared to zig and blithely passing the responsibility of input validation on to the programmer. Rust of course demonstrates the benefit of checking validity at initialization.


Seems sort of like the opposite—a lot of the regulation is done by people installed by lobbying, sort of like a privately owned and operated part of government.

Of course it's terrible for everyone but shareholders there isn't really any domestic competition.


It's great for the entrenched leadership, but bad for the shareholders who would benefit more from a variety of investment opportunities in a diversified and growing market. I don't think all of these problems are good for the airline industry.

The shareholders in a company have no reason to want the government to kill off the competition - they could just as easily invest in that competition. Shareholders care about the size of the whole market and corruption steals from them as much as it steals from anybody.


https://news.ycombinator.com/user?id=DinaCoder99

Is this you as well? Is this even allowed?


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

Search: