Yup, in Poland, a mobile phone number (pre-paid or not, it doesn't matter) is tied to a PESEL number [1] at the time of purchase. The official justification, as usual, was combating crime, but the end result is a tighter grip on citizens' privacy by the government while spammers and others continue their business as usual.
PSP S.A. is expanding abroad, so perhaps BLIK will be available in more countries in some time: "In September, the first BLIK transaction was made in Slovakia, and BLIK Romania S.A. received authorization from the National Bank of Romania to operate in the country. In November, the Polish Payments Standard transformed into a joint stock company, to support the execution of its strategic goals." [1] [2]
BLIK has one ugly caveat, though: it has no chargeback procedure.
At school (Polish class in Poland) we were always taught to prefer complex and compound sentences over simple ones, because it's more elegant and speaks well the speaker/writer.
It's not pretentious and there's nothing to see through here. This is the preferred style in Poland and it's widely used, especially by the educated people. Just because the sentences aren't simple, doesn't mean they're not informative.
Also, we were taught to prefer compound and complex sentences over simple ones where applicable, not at all costs. For instance, the quoted sentence from NTSB report is a bit too long in my opinion.
"a complex writing style preferred by educated people" - how is that not pretentious?
You started by saying complex sentences should always be preferred, but now you ended by saying "only where applicable" and the sentence under discussion was "too long".
> "a complex writing style preferred by educated people"
This is not a quote of me. Nor is it an honest summary of what I wrote. It also completely ignores the context: the "educated people" were supposed to "see through" - the same people who predominantly prefer the same style. I have also never claimed the style is not used by other people. Quite the opposite. Not to mention, that education until 18 years of age is mandatory in Poland anyway.
> how is that not pretentious?
The straw man you made up definitely is.
> You started by saying complex sentences should always be preferred
I wrote that we were always taught to prefer one over another (there were multiple teachers along the way), not that we were taught to always prefer one over another.
> but now you ended by saying "only where applicable"
There is no "but now".
> and the sentence under discussion was "too long".
Only if you're using technical writing in a situation where you shouldn't be.
Problem is the state of most English education doesn't even teach enough for people to recognize proper unambiguous technical writing, let alone appreciate it or attempt to compose it.
i imagine the language may change that though. With Polish having nominally 300k-400k words compared to English's >1m, i'd guess that it's a lot easier to misdirect and fluff up your writing in English.
It can if you count all the different forms of each word and proper nouns. But this way Polish may have even more words than english, given multitude of different forms. I've never checked that, though.
There's also the tendency in English to make new words out of existing ones to create new meanings, while in Polish we often use multiple separate existing words to create new meanings.
All in all, I believe English has more base forms than Polish.
This sentence isn't written for elegance but for meaning. The formal cause of the accident was the mechanical separation, but that happened for a reason, either mechanical failure (which means a failure in the engineering of the aircraft, which would have to be remedied by new engineering processes) or an assembly failure (which would have to be remedied by new assembly processes). In one sentence, the author drills down to exactly what went wrong that enabled the accident to happen. Identifying that is the first step to remedying it.
Could've been worse. In Korean schools they somehow find the worst, most meandering and pointless examples of English prose and shove them at poor students at exam time to test their "English comprehension" skills, when any reasonable native speaker would've said "Who the fuck writes like this?"
I remember an anecdote from my English teacher where a student went to London, and a taxi driver told her (the student) something along "What a lovely English! It's a shame nobody speaks like that anymore." ;)
What problem? To make sentences like the one from NTSB report quoted here? Well, personally I would've split it and I'm pretty sure my teacher would've asked me to do it too if I were the author. ;)
This is not about "writing to look smart". It's about using elegant style and using the language to it's full potential. There were multiple attempts to strip Polish people of their mother tongue and identity throughout the history, so we were taught to treasure both and use language's full richness. It's also simply nicer to listen to or read richer forms. These are the reasons for why we were told it speaks well of the speaker/writer. Also, elegance does not contradict communicating vital information. It's a false dilemma.
How come? A more fusional language is one where a single word can carry more forms of information where English would need more words (e.g. "my book"). This isn't directly related to how much information you should put in a sentence. OTOH, all languages are recursive which means you can construct arbitrarily long sentences - but you shouldn't, because human cognition has its limits.
In my experience as a speaker of a more fusional language, the sentences are shorter than in English, not longer.
It's surprising up to the moment the compilation error tells you that all of the members have to implement derived trait.
Nevertheless, it would be cool to be able to add #[noderive(Trait)] or something to a field not to be included in automatic trait implementation. Especially that sometimes foreign types do not implement some traits and one has to implement lots of boilerplate just to ignore fields of those types.
I know of Derivative crate [1], but it's yet another dependency in an increasingly NPM-like dependency tree of a modern Rust project.
All in all, I resort to manual trait implementations when needed, just as GP.
> It's surprising up to the moment the compilation error tells you …
Unfortunately this problem only shows up when you’re combining derive with certain generic parameters for the first time. The first time I saw this, I thought the mistake was mine. It was so surprising and confusing that it took half an hour to figure out what the problem was. I thought it was a compiler bug for awhile and went to file it on the rust project - only to find lots of people had beat me to it.
Aside from anything else, it’d be great if rust had better error messages when you run into this issue.
It took you 30 minutes to understand what "could not call Clone::clone because <type> does not satisfy Clone" means?The error message tells you exactly what the problem is and how to fix it.
This is a pet peeve of mine so I'm sorry to be overly dismissive. There are bad error messages out there in the world that are impossible to parse, but this is not one of them. Trying to file a github issue before attempting to understand the error message is insane to me.
Yes it took me 30 minutes. The error message in this case is uncharacteristically bad. Or I found it particularly confusing because of quirks in my understanding of rust’s type system.
Take a look. Do you think this quirk of derive is obvious from the error message alone? Would you have figured it out, in the context of a much more complex program with dozens of other changes that may or may not have been related?
The compiler error says my type didn’t implement clone. But #[derive(Clone)] was right there on my type, and my type was obviously cloneable. The error wasn’t on the derive - or anywhere nearby. My program even compiled successfully, right up until I tried to actually call clone() on my object. And my type trivially, obviously was cloneable because all the fields were clonable.
My first thought at the time was that my derive attribute was being ignored by the compiler somehow, but it wasn’t at all obvious why. The compiler’s suggested fix was also wrong and misleading. It suggests adding clone to an irrelevant type that shouldn’t impl clone in the first place. That’s the wrong fix.
In summary, the error message doesn’t offer the real problem, which is that the trait bounds added by derive Clone were wrong. And it didn’t suggest the proper fix - which was to impl clone manually.
I was very confused for a good while with this one. Get pissy if you want but I find this incredibly counterintuitive and I found the compiler’s error message to be uncharacteristically unhelpful.
If this quirk of derive was truly obvious, this blog post wouldn’t have hit the front page of HN in the first place. I cut my hand on one of rust’s sharp edges. Don’t get mad at me for bleeding a little.
The error message points you to the inner type and tells you to implement clone for it. Like you point out, it's sometimes not the correct fix - but the compiler can't be smart enough to tell you that. I'm actually at a loss for how this isn't anything but obvious if you know the language and type system. It's not magic!
My pet peeve is the learned helplessness around compiler error messages, particularly ones that go to great lengths to be informative and offer solutions instead of just throwing garbage at you.
> it's sometimes not the correct fix - but the compiler can't be smart enough to tell you that
Everyone said the same thing of most compiler errors until clang came along and showed everyone how much better compiler messages could be.
The compiler message here doesn’t suggest the true problem here, nor does it suggest the appropriate fix. I’m also clearly not the only one who finds this issue surprising and annoying. This blog post wouldn’t have been upvoted and commented on if it didn’t strike a nerve.
If nothing else, I think it’s quite obvious that the compiler’s error message could be improved. But better yet, I’d love to see it fixed in the language. The bounds derive places on its traits are simply wrong. There’s no reason why T needs to impl Clone. T is irrelevant.
For what it’s worth, I get what you’re frustrated about. I spent 2 years as a programming teacher. I feel like the first month of every cohort I wander around telling upset students that they forgot a semicolon. And the third month I wander around guiding frustrated students to read the compiler error message, which would have saved them 2 hours of guessing.
After banging my head into a wall for awhile on this issue, I made a reduced reproducing test case. Then I went looking in the rust compiler issue tracker. Only there did I finally see a proper explanation of what was going on, amidst a sea of other people struggling with the same thing.
That was half an hour of my life I won’t get back. I’m not helpless. But I am still pretty frustrated by the experience. I see it as a language level bug. It seems to take years and years of bike shedding for rust to fix stuff like this. I’d give even odds this still isn’t fixed in a decade from today.
But maybe, at least, we might be able to improve the error message?
> Aside from anything else, it’d be great if rust had better error messages when you run into this issue.
Would you mind filing a ticket detailing what you'd wish the error had been? Without additional context, the only improvement I can think of is adding a note explaining imperfect derives when hitting a missing trait bound coming from a local crate derived impl.
I mentioned in a sibling comment. The error message doesn’t explain or suggest what the problem is, and it recommends the wrong fix. (It suggests implementing clone for T, whereas here you need to manually implement clone).
Something like this would have helped me immensely:
> Note: even though struct Foo has derive(Clone), Foo does not implement clone in this case. derive(Clone) may have overly restrictive trait bounds (impl Clone where T: Clone). If this is the case, you may need to manually implement Clone for Foo with less restrictive trait bounds:
Would you mind filing a ticket on GitHub.com/rust-lang/rust with that exact request? (I'm on the go and am not logged on GitHub on this device and wouldn't want this feedback to be lost). This should be relatively easy to add and I agree it would be an improvement.
A quick web search revealed at least 4 other agent orchestration frameworks written in Rust [1][2][3][4]. Just being curious: did you decide against contributing to existing ones for some reason?
Thanks for the comment!
Yes, the idea was to create something much leaner and simpler that is not tightly coupled to any framework, yet provides robust graph execution capabilities. In fact, for this reason, GraphFlow can server as a graph execution framework for Rust application that are not AI oriented at all.
Same thing in Europe and North America. AppCloud is present on Samsung devices. Sometimes from the get go, sometimes after system update, sometimes after security update (the irony of that!). Carrier-locked or not, it doesn't matter. Sometimes it's visible only after switching the "Show system applications" toggle on application list in device settings. There are many people reporting that their Galaxy S series phones have it too. This AppCloud stuff is absolutely outrageous!
Checksums are slow on HDDs and using SSDs for backups is a bad idea, particularly for cold backups, due to data longevity and the tendency for SSDs to experience sudden total failures instead of gradual degradation.
Rust does not have this feature. Function names can't have spaces, for example. Underscores are used instead. Maybe there are some macros for arbitrary ASCII strings - I don't know - but it's not a language feature.
Whoops, I had an edit that apparantly did not submit. My comment is very wrong now, the only language in that list that supports "raw identifiers" in the same sense as Swift is Kotlin.
Although I still stress that it has never been an issue in Kotlin.
[1] https://en.wikipedia.org/wiki/PESEL
reply