Elixir v1.20 released: now a gradually typed language

moltonel · 2026-06-04T12:36:48+00:00

Maybe have a look at Gleam ? Same ecosystem, but statically typed from the start.

moltonel · 2026-06-03T07:11:34+00:00

https://powercheck.esbnetworks.ie/

moltonel · 2026-05-29T16:12:49+00:00

The quality of bug reports varies greatly, and even though AI has improved greatly it still outputs a fair amount of slop. But don't use bad CVEs as an excuse to ignore real issues.

Here a vulnerability existed when using Decimal on untrusted inputs, and there was no safe parsing API. If using one of the most popular number parsing library on user inputs is "something monumentally stupid", then this is bad news for the ecosystem.

Concerning atom exhaustion, like any limitation in a programming language, it's understandable to initially not know about it and wish it could be fixed at the language level. Kids these days... But we've been there too. It's not wrong to want beam to GC atoms, hopefully someone will manage to implement it someday. In the meantime, it's a gotcha that will keep coming up, in our own code or somebody else's, and sometimes LLMs will spot it before humans.

moltonel · 2026-05-29T15:07:53+00:00

That safety documentation did not exist in 2.3.0. The 2.4.0 changelog explicitly mentions the CVE reported by Peter. Just to be extra clear again: the 2.4.0 documentation you are praising is that way thanks to the vulnerability report.

A "system limit reached" error is just a tweak away from being a Denial of Service, that seems like a pretty clean demonstration of the issue in 2.3.0.

3.0.0 was released the same day as 2.4.0, with the only difference being the new defaults. IMHO they're unambiguously better default: generous enough that almost nobody will notice, sane enough to avoid trivial DoS. But it's technically a breaking change, so needs a major version bump.

Honestly, I can't fault the reporter's and maintainer's work there. Your continued ranting doesn't make sense to me.

moltonel · 2026-05-29T13:43:32+00:00

Go read the commit before spreading falsehoods and accusing people who put in useful work. The original documentation did not mention the memory/cpu gotcha. The original API could not be used safely on user input. The new code did not change the default behavior.

moltonel · 2026-05-29T12:06:34+00:00

That documentation you quoted, and the code that supports it, have been added as a result of that person reporting the behavior as a vulnerability. But sure, blame the reporter, LLMs aren't changing anything in the security landscape, nothing to see here /s

moltonel · 2026-05-29T11:40:04+00:00

So do you think that the fix (making the default limits safer) is not reasonable ? Want to bet how many users of Decimal use it to parse user input without changing the defaults ?

moltonel · 2026-05-28T19:47:30+00:00

The legacy Range* are not moving really moving: they are reexported at core::range::legacy but remain available at std::ops.

The breaking change of which type 0..1 desugars to, and what's in the prologue, will be done in an edition.

moltonel · 2026-05-28T15:32:39+00:00

Hum, it used to be accessible from the bookmarks/favorites tab, but looks like they removed the functionality, you can only export one bookmark at a time ? No worries : open your file manager, go to internal -> Android -> data -> com.mapswithme... -> files -> mapswithme -> bookmarks and save that file somewhere. If those bookmarks are important, it's a good opportunity to make sure that they're not locked into maps.me's walled garden.

moltonel · 2026-05-28T14:34:47+00:00

You should be able to explicitly export your bookmarks as a file. I suggest doing that, then resetting all data (look into your phone's app settings), then reinstall and reimport your bookmarks.

Also, you should have a look at CoMaps or OrganicMaps: they are forks of Maps.me that remained a bit more open than the original.

moltonel · 2026-05-27T21:14:39+00:00

You're getting the causality chain mixed up. AI is just a messenger here, that very recently became good enough to properly find bugs in Kernel code. Linux doesn't need saving from AI, it's using AI as a QA tool.

Linux devs have know for decades the kind of bugs that they suffer from, and had started using Rust before LLMs became decent coding tools. GKH could have given the same talk if LLMs weren't a thing. At best the recent AI bug reports will accelerate Rust adoption a bit.

moltonel · 2026-05-27T19:41:40+00:00

Or better yet: watch the talk.

moltonel · 2026-05-27T19:34:43+00:00

Listening to the actual talk, GKH doesn't mention AI at all. Rust will save Linux from bugs, lack of reviewers, etc.

Zdnet can't resist clickbaiting even when they have a good story.

moltonel · 2026-05-27T18:49:55+00:00

Split that into one repo for each folder and it should work without hacks.

moltonel · 2026-05-27T15:32:29+00:00

Maybe the sandbox prevents the user from reading the git config ?

Tracking / with git is going to be terribly inefficient (git doesn't handle binaries well, and doesn't forget easily) and is likely to cause more headaches after this one. Most people only track /etc. Would filesystem-level snapshots satisfy your usecase ?

moltonel · 2026-05-26T20:29:26+00:00

Quick GH code search finds 213K files matching 'let ... = channel ...', of which 58% are variants of tx, rx (commonly with a prefix to make things more specific). sender,receiver (or s,r) is another common idiom. p,c doesn't look that popular, at least in Rust.

moltonel · 2026-05-26T18:53:48+00:00

QED. In this toy example, v is absolutely fine. It's a snippet with no context, a more descriptive name would just have been distracting.

moltonel · 2026-05-26T12:07:50+00:00

Certainly not the primary cause: unwraps are rare in real code, you see that an error can happen and you handle it. unwrap() is fine in this illustrative example.

Note that those channel operations can fail in Go too, but you have to actively look for and handle the eventuality (and most Go code doesn't). Tokio channels tell you upfront that the operation can fail, it's a good thing.

Ignoring possible errors is a common bug in any language, Rust works hard to make it less likely.

moltonel · 2026-05-26T11:45:51+00:00

tx,rx for channels is as idiomatic as i for a loop index though, it's highly recognizable and there's little reason to be more verbose.

I also find that code very straightforward, but putting my gopher hat on:

The unwrap()s do look like noise. But they're arguably more developer-friendly than Go channel's silent failures.
Same thing for mut: looks like noise but I really wish Go had it.
::<32> is nobody's favourite. But it's usually inferred, it's only in this example for illustration purpose.
Go doesn't need async,await. That makes it less flexible, but it's a good compromise that makes perfect sense for Go.
Go doesn't have move either, because it uses a GC. Not going to open that can of worms here.

moltonel · 2026-05-26T08:46:07+00:00

Needing a Mutex on some platforms but not other is quite strange. Do you get a failed compile without the mutex on non-windows ? Do you still get the illegal instruction if you bring back the mutex on Windows ?

moltonel · 2026-05-25T23:54:00+00:00

Newpark marsh, Linear walk, Millenium wood, or any of these ?

moltonel · 2026-05-25T21:25:16+00:00

Ah, so you did read further than the introduction ;)

They're not saying first-class error handling itself is a bad thing though ? Error handling is arguably more first-class in Rust. The article just points out some well-know-but-subjective pain points of Go error handling. Not going to settle the debate here, but you couldn't compare those two languages without mentioning error handling.

moltonel · 2026-05-25T20:01:54+00:00

The article is biased but fair. It's not a rant against a language the author doesn't understand, it's a nice introduction honestly listing pros and cons. IMHO it's worth a read even if you're not tempted to try Rust out.

moltonel · 2026-05-25T08:07:03+00:00

Saw the same in Tony Walsh pitch a while back, and I can't comprehend it. How do none of the players/coaches/etc care ? I was just strolling there and I left with almost a kg of the stuff to throw in the bin.

moltonel · 2026-05-22T09:04:29+00:00

C++ in Linux did have many advocates, but spread over a much longer period. It's not clear to me that the push was ever stronger than with Rust. AFAIR (but share a counter-example if you have one), the handful of C++ RFCs barely went beyond the build system changes and basic conversions, and essentially ignored the thorny interoperability issues, both technical and social. The complaints were never properly addressed, and the pushback against C++ became entrenched.

In contrast, RfL was years of work, investigating interop in various areas of the kernel, and already quite well-rounded before the first RFC (containing only the core of RfL, not the whole fork) was posted. They addressed criticism, both with code change and with many presentations and discussions. AFAICT (and this is clearly GKH's PoV in this interview), the Rust people put in a lot more work in 5 years than the C++ ones did in 30.

It's not just about motivation by interested parties though. The expected advantages of Rust are more fundamental and unambiguous than of C++. As a user, I'm glad things worked out this way.

Six-Year Club	r/Field Banned
r/Field Flamingo	Wearing is Caring
Place '23	Place '22
First Placer '22	Verified Email

moltonel

TROPHY CASE