> In the case-control study, individual-level analysis resulted in a hazard of skin cancer (of any type except basal cell carcinoma) that was 1.62 times higher among tattooed individuals (95% CI: 1.08–2.41)
> The Armed Forces, on the other hand, are negative and write in a letter to the government that the proposal cannot be realized "without introducing vulnerabilities and backdoors that can be exploited by third parties
First time I am seeing an organization against this. Kudos to them for standing up.
According to the original article (Swedish: https://www.svt.se/nyheter/inrikes/signal-lamnar-sverige-om-...), the reason for the armed forces to be against it is because they recently started advocating for its personnel to start using Signal to reduce eavesdropping, so backdooring Signal would decrease the armed forces security.
> Men Försvarsmakten är negativa och nyligen uppmanade försvaret sin personal att börja använda Signal för att minska risken för avlyssning.
In fact, they are negative because they say that this can't be done without opening up the service to vulnerabilities that could be used by others.
> I ett brev till regeringen skriver Försvarsmakten att lagförslaget inte kommer kunna förverkligas ”utan att införa sårbarheter och bakdörrar som kan komma att nyttjas av tredje part”.
> In a letter to the government, the Swedish Armed Forces writes that the legislative proposal will not be able to be implemented "without introducing vulnerabilities and backdoors that may be utilized by third parties."
Yes, but your deduction is incorrect. They're saying the SAF are negative _and_ they recommend their personell to use the service, not that they are negative _because_ they recommend it.
I don't see how you can know that "because" is incorrect. This seems like it could be possible to me:
(Possibly) SAF is negative because they use Signal, and don't want a law that would introduce vulnerabilities into Signal that could be utilized by third parties.
TOR was sort of famously contributed to by a dude in US Naval research early on, right?
They are militaries, not police or intelligence forces. The job is to be ready to do war, not nanny and snoop on civilians (Some of that might be a necessary side effect but it isn’t their reason for being).
The NRL originally developed onion routing and Tor. It was then open sourced, stewarded by the EFF for a few years, before becoming its own non-profit. The NRL still do a ton of work on Tor and its ecosystem, primarily through academic research and occasionally code, though the Tor Project is obviously now the biggest player in the space. The original motivation was to enable communicating with covert assets (intelligence services and the like) overseas, which requires lots of non-military cover traffic to be useful, hence the opening up. Its popularity as an anti-censorship tool has motivated a lot of the continued support from various US agencies, including the NRL. Really though, the NRL is a largely civilian institution, and while the people who work there do work for the military, they aren't typically enlisted, have limited security clearance if any, etc. It's sort of like the Navy's version of Microsoft Research, or Bell Labs.
Militaries need intelligence services to be their eyes and ears. That said, most people who are not in their country's armed forces, government, or intelligence service vastly overestimate how much another country's intelligence services actually care about them. Most people aren't that interesting and don't have any intelligence value for another country's government.
US Navy research labs developed onion routing and the core of Tor
arguably, one of the reasons it was released to the public was to get large amounts of traffic using onion routing. because if it's just 50 data steams that are entirely ONI or NSA then it's easy to hit them with timing attacks.
but 2+ million streams from all over makes it a lot easier to hide.
They're not using/advocating to use Signal for their military control/communication:
> This week, Brigadier General Mattias Hanson, the Swedish Armed Forces' CIO (Chief Information Officer), decided that calls and text messages that do not concern classified information should, as far as possible, be made using the Signal app. The decision aims to make it more difficult to intercept calls and messages sent via the telephone network.
Seems people were using SMS for those messages they are now advocating to use Signal for.
Also, seems they've done a review (obviously) but unclear if they had access to something internal from Signal to do the review, feels like they had to:
> The Signal application has been deemed by the Swedish Armed Forces to have sufficient security to make it difficult to intercept calls and messages.
Any decent military will be using multiple forms of communication systems.
I was a communications specialist for the Swedish Armed forces 10+ years ago, including a tour in Afghanistan and a tour in Kosovo.
We used radio links for internet that I can tell you, were more adversarial than friendly.
The Swedish military is highly capable when it comes to network communications. A small nation will have to think differently.
You could potentially use an instant messaging system in control by someone else, if you are willing and capable of sharing encryption keys with whomever you are going to communicate with beforehand.
>Because everything in Signal is end-to-end encrypted, we can rent server infrastructure from a variety of providers like Amazon AWS, Google Compute Engine, Microsoft Azure, and others while ensuring that your messages and calls remain private and secure.
Your source doesn't support your claim. The exact snippet you quoted, interpreted strictly, only means they have the option to host it across providers, not that they actually do so. It also doesn't say anything about where it's hosted. It can be hosted in AWS, GCP, and azure, but all in the US, for instance.
I think the hatred of global variables comes from the fact that they are hard to use correctly. This article also makes the point that to use correctly you need to follow a bunch of rules.
I’m normally open minded about what I read posted here but that article does nothing but frustrate me. I can’t count the amount of times I’ve dealt with legacy spaghetti code that used global variables and the pain and suffering that results from that.
Exactly the issue; inevitably someone will forget to follow those rules, at which point esoteric bugs will have been introduced.
I think it’s somewhat similar to unchecked memory access. Used correctly it works just fine and offers extremely high performance. Unfortunately, history has shown that over enough time mistakes will be made. As an industry we’re now to the point of actively denouncing entire languages over the risks of unchecked memory access.
Using software development patterns that rely on the engineers to follow a bunch of rules to do things correctly will eventually burn you. Better to avoid them entirely if at all possible.
There's plenty of things in programming that are "hard to use correctly". I seen many codebases that you must clone an object because passing it in a function because there was so much spaghetti data structures that you'd end up accidentally mutating something you didn't mean
Are there any circumstances where starting a new project with perl makes sense today? I am curious because I only encountered perl in legacy codebases.
Perl as a scripting language remains undefeated. As in, let's say you are considering Awk for some task. It's probably worth learning how to do that task in Perl instead. The same applies to many classic uses of bash scripts: today, the biggest reason to choose to write a shell script is to provide some service which will be universally available on plausible platforms, and Perl isn't that ubiquitous any longer. But for most of what shell scripting was intended for, Perl is a more powerful and less, let's say idiosyncratic, choice.
Of course, with a bit more verbosity, any such script could be written in Python. Perl was designed to fit this exact niche, so it has a bunch of small affordances for doing script munging eloquently (not to say elegantly!) but Python, or Ruby for that matter, can also get the job done. Most people who know either of those languages thoroughly would pick what they know: they'll do the job, and that spares learning another language, which is indeed a quirky one.
But for those who do know Perl, it remains a very good fit for a Practical Extraction and Reporting Language. For those who do a lot of 'scripting' tasks in the original sense, it's worth learning imho.
Except, I know how to slice and dice text with awk, and can do it without leaning on ChatGPT or studying language documentation. Never made the leap to perl, the few times I tried I was put off because to a newbie the language looks like gibberish.
I would never consider perl for anything new in 2024. I still use awk very regularly.
> Except, I know how to slice and dice text with awk
I meant to say something more like "if you need to learn awk to do it, you may as well learn Perl instead". I figured from context that if you're "considering using awk", you don't know it, or you'd be "using awk". But no matter.
Perl can do everything Awk can, at least as well if not better. As fiddly, arbitrary, and limited, as Awk is, it's a lot less language, and that does come with advantages.
But I know from experience that you can learn the Awk subset of Perl as easily as you can learn Awk, and then you have a basis for extension to more tasks of a similar nature. If you want to see what I mean, there's a utility a2p[0] which translates Awk to Perl, this suffers slightly from machine translation, but it's a good demonstration that Perl can do everything Awk can in not just a trivial sense, but in the sense that it's designed to make Awk unnecessary.
So if you can get over whatever aesthetic hangup you have about Perlian line noise, you might discover you like it. Anyone using Awk "very regularly" is leaving a lot of potential on the table by refusing to learn Perl. Then again, sometimes it's best to stick with what you know.
I've started to write my one off scripts with an AI prompt, and Python as a simpler and more verbose language with a bigger training corpus is easier for that. Or I ask for a bash script! Still writing my one liners in Perl but they're getting shorter and shorter.
Ok, but if you’re comfortable using it, Perl is really fun, pleasant, and easy to quickly express ideas in. One of its conscious design decisions is to be flexible enough to rapidly bang out some quick hack you’ll never look at again in absolute incomprehensible gibberish shorthand, or to use in a very methodical, disciplined, and structured way — so if you write something unmaintainable, that’s because you chose to.
I haven’t turned to it as my first choice in years, but it still has a place in my back pocket for if I ever need a quick and dirty text munging Swiss Army knife.
I've used Perl extensively for a few years professionally. For prototyping, say text-processing stuff, I reach out for awk/sh, which are usually sufficient.
If I need more than a prototype, I reach out for Go. I have two major complains with Perl:
- it's more difficult to deploy (Go can be cross-compiled to a single binary which can then be scp(1)'d around, solid stdlib, no need to deal with dependencies on the remote, or modules split in multiple files);
- lack of static typing. You can get away with writing additional tests, but at the end of the day, that's just more work.
So despite being quite confortable with a fair subset of Perl, I (genuinely) can't think of a reason as to why I'd want to use it.
I have perl stuff written literally 20 years ago, that still works without issues, even on modern computers. If you need something to do the job and in ten years be called "legacy codebase", then do it in perl... because if you did it in python, you'd have to fix the 2.6->2.7 stuff, then 2.7->3.x stuff, and maybe even more than that. If you did what people here on HN like, so, use a 'language of the day', you'd have code written in ruby (now rust or go or whatever), which very few machines have installed by default now.
In a previous company, I had to support TypeScript code that wouldn't even survive 12 months without something breaking upstream. Granted there were a lot of other things that company did wrong...a hell of a lot! But it's insane how little importance people seem to place on code longevity these days.
I’m not on about fixing tech debt. That’s a completely different problem to picking boring technologies that don’t need constant ongoing maintenance just to keep running.
Tech debt is going to happen regardless of the technologies you pick. But some technologies require more effort to keep up-to-date than others.
I’d also argue that keeping technologies up-to-date isn’t “tech debt”. It’s operational overhead. Tech dept is something else entirely.
In my experience, tech debt often requires too great an investment to fix so the team just ends up bikeshedding to show progress but without real benefits.
Look at C. Each revision has added a bunch of minor fixes but has never addressed the core issues of the language that realistically require a rewrite (function pointer syntax, undefined behavior, null safety).
And there’s the fact that features bring in money and tech debt simply doesn’t. It’s still a business at the end of the day.
Right. I started a perl codebase in 1999, which has slowly evolved and is still one of my main projects to this day. The language has slowly improved, there are decent libraries for everything you might want to do, and I've basically never had to rework or throw away my code because of incompatible changes in the language.
For reference, PHP at the time was at version 4, Python was around 1.6, and noone had heard of Ruby.
I have perl code I wrote in 1992 that still works properly, without changes. The binary executables have changed ISA from MIPS 4 to x86_64, and are compiled fortran (gfortran). There's even a switch I use to be able to read the large endian binary files in gfortran.
My c code from 1996 requires rework. My C++ code from 2014 requires rework (I had to do this with others code as well to use a std capability). Python code rarely survives 3.6 -> 3.12 never mind 2.7 to 3.x. I worked at a company that had (very unwisely) written a massive part of its infrastructure in Py2.7, and was using it a decade past its expiration date.
Are you kidding? Python code bases break week-to-week because pip is full of unversioned transitive dependencies, broken distro nonsense, and who knows what else.
As of 3.13, Python doesnt have a GIL either. JVM-based Ruby implementations don't have a GIL. Perl on the other hand never had a GIL, it just more or less defeated the purpose of threading by copying the entire interpreter state including all variables in every thread. Modules that explicitly work with threading are as rare as hens teeth on CPAN, it's almost always some flavor of async like Coro (hell I bet POE still works too).
python 3.13 most certainly has a GIL, it can just be optionally disabled, and this feature is in experimental status. see https://peps.python.org/pep-0703/
Oh, I thought the experimental state was earlier and that 3.13 was the official no-GIL release. Presumably it's going to eventually drop the GIL entirely (probably Python 4 if there ever is such a thing) but nonetheless I stand corrected, thank you.
I was curious about this and did some casual googling. It spawns an interpreter per thread. However, it seems this is not advantageous performance wise. From docs [1]
The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that makes them easy to misuse. Few people know how to use them correctly or will be able to provide help.
No, instead they have subinterpteters with all of the massive overhead that brings re: data sharing. And even fewer CPAN modules are remotely thread safe than PyPi modules, probably in absolute as well as relative terms. That’s a low bar.
As a result, threaded Perl code or frameworks are extremely uncommon, even relative to Python.
I guess if the team is (only?) familiar with Perl. But then again, its the same with PHP. Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
I guess some people just want to stick with what they know, and refuse to learn anything new.
> Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
That really depends on the use-case. If you need a batteries-included web framework, the top 3 that come to mind are Spring (Java), Django (Python) and Laravel (PHP).
I recently read a new idea of why PHP is useful to people - it's the lowest-overhead server-side Web page language available. If you want a tiny amount of functionality, you write a tiny amount of PHP and don't have to do anything else. So it scales much, much better in the tiny-to-medium-sized project range.
(I can't personally vouch for the claim but it's the best explanation I've heard for how such a reviled language has survived this long.)
I run a WordPress site for my wife's business. Would I pick it up again in 2024? Absolutely. It has nothing to do with what I "know", there's still no better CMS/ small diy e-commerce solution for, frankly, peanuts in hosting.
I really don't have much issue with modern PHP either, it gets the job done and unlike Perl is still very much evolving.
I think there are worse things than modern PHP (speaking as somebody whose primary contact with PHP is being traumatized by legacy PHP 7 projects). Afaik, the only places that will start a new PHP application today are places where the expertise is in PHP and Laravel/Symfony. I don't see a big enough benefit from migrating to a whole new stack that wouldn't be accomplished by some focused maintenance and refactoring if you're already working with PHP 8.1.
I write PHP for a living and I only write headless apps with Symfony and Laravel. Blade is an awful template engine with a primitive parser. Twig is tolerable, but for me nothing beats the DX of Inertia with Vue.
You are most likely right. I just fear spreading complexity everywhere. But I also want to take advantage of the vast compute available at clients. So, I am conflicted. Vue is probably a good compromise. Please share your best references on Inertia/Vue.
Only deployments of Inertia I have are internal code I can't readily share, but all it does is replace the very typical pattern of passing json-encoded props to a a blade template that contains a single React/Vue/Svelte component. Now you just return Inertia::render('My/Component', $arr) from your controller or route handler function, and you're good to go.
It also has various magic for router links that do partial refreshes and working with classic (non-json) forms and whatnot. I use none of those, I'm all about json and useFetch() instead, and Inertia's pretty good about getting out of your way when you don't need it. It lets you write as much or as little in SPA style as you want, it's more or less your favorite JS framework as a view layer directly without having to interpose another view as a middleman (the middleman is there, but it's all implicit: you add the @inertia directive inside your <div id="app">, and that's it)
I don't "start a new project" in Perl, but I certainly write a lot of Perl. Mostly one-liners and small scripts, and mostly throwaway. Perl is a very efficient language for string processing, thanks mostly to its built-in regex engine.
Once it grows a little bit more and starts requiring maintenance, I tend to rewrite it in a more maintenable language. Preferably a statically-typed language.
I'm considering it. It might be a language that does not need constant changes because of useless churn. Especially now, with the Raku split worked out.
On the other hand, the changes in my Ruby project have always been very manageable. Both the language and the ecosystem were reasonable those last years.
It's been my first choice for 30 years for anything involving a lot of non-trivial work with textual data (Including xml, json, etc.). And one-liners and any quick throwaway script, of course.
All Perl code I have ever seen, has been "write-only". Just completely unreadable and it was easier to just look at the output instead of the code when converting it to Python to get actual maintainability.
You are getting downvoted, but for me, it is the same experience. It's a dead language, and we are switching to Python, that is far better to maintain for me and for all our new hires. I mean, Perl doesn't even has a debugger on Windows.
Not true by any stretch. I've used komodo[1] for more than 2 decades as a debugger in Linux, Mac, and Windows. More recently VSCode on all 3, for debugging.
Definitely not a dead language. A mature and stable language, which won't surprise you.
The author mentions lustre, the web framework for Gleam that was inspired by Elm. I really like Elm. However, the limitation for me was the lack of a really robust component library. When I say component library, I don’t mean aesthetics but function. For example, a feature complete search bar with autocomplete, multiselect, create, delete, clear, etc. functionality. The reason I use typescript is because of component libraries like Mantine where generic components such as a search bar are already implemented, fully functional and accessible. I hope someone sees this gap and tries to fill it so that functional languages can be viable on the web!
Author of Lustre here! Yeah I agree, lack of a robust headless component library like radix-ui or react-aria is such a mark against Elm. I think it's even more important for Lustre because really all our users are going to be backendy folks with little interest in the nitty gritty frontend stuff.
Lustre will eventually have a companion ui library to plug this gap but it turns out maintaining all this stuff is a bit of a time sink, so I'm taking baby steps ^.^
ReScript is really solid in this niche IMO. It's basically ocaml that compiles to js. The standard library includes excellent bindings to react, so you can use react components without too much extra work. You do have to write your own type annotations for them, but it's way way less trouble than elm ports.
Looks like a great idea! It doesn’t support languages I am interested in right now but I will be sure to go back and check it out again. One suggestion, for words that break a line, the effect of typing perfectly on the background disappears. It might be a hard problem to solve but if the word is going to be on the next line when written completely, it should be in the next line when I start typing.
Almost all frontend fuzzy search libraries I tried fail in correcting small typos (whoch is pretty common when searching). From the demo it seems this library can handle it. I will definitely be trying it out on my own project. Thanks for sharing it!
I don’t know where the translations are coming from, but the quality of the Turkish/English translation was lacking. Unfortunately, It does not inspire enough confidence for me to use this tool.
The same is the case for the "Spanish" example, which is only barely understandable and lacks basic grammatical gender concordance:
> Una carrera comparativamente segura y próspera con algún prestigio básico automático es peligrosamente tentador para alguien joven, que no ha pensado mucho sobre lo que le gusta realmente.
If that's what's being presented for the world's 2nd most spoken native language and 4th most spoken overall, I shudder to think what the ostensible "Polish" equivalent phrasing is like:
> Porównawczo bezpieczna i dostatnia kariera z pewnym automatycznym prestiżem jest niebezpiecznie kusząca dla młodej osoby, która nie zastanawiała się zbytnio nad tym, co naprawdę lubi.
Hmmm we assumed that the translations for the Paul Graham essays would have been properly translated. Someone else pointed out a French issue earlier, both the French and Spanish examples were taken from their 'official' translation. Now I'm questioning everything. Unless we seriously messed up a copy and paste, it's possible we just used a bad source.
It is a bring-your-own materials type of app, so if you bring an authentically translated work, you avoid this problem. We try not to do any translation ourselves (although we of course allow it for convenience if you choose it)
It reads as a direct word for word translation of English as opposed to native speaker conveying the overall meaning using native language idioms and such. Its very difficult to translate things word for word and have them sound „native”. That’s why when you have side by side text is something complex, like a novel, translating authors often take creative license with text to make it sound reasonable.
The demo article only had a couple translations, so we auto-translated some missing ones. Sorry the Turkish one isn't great!
Most of the app we try to encourage you to use professionally translated works to learn whichever language you're studying, so try to do as we say not as we do :D
As I’ve commented elsewhere, to the extent you are using machine translation: note that GPT is bad at translation to languages other than English. Telltale sign is not declining for gender. I saw this a lot with GPT4’s Polish. Better to use one of the standard translation services.
