brabel (u/brabel) - Readit News

brabel commented on From M1 MacBook to Arch Linux: A month-long experiment that became permanenent ssp.sh/blog/macbook-to-ar... · Posted by u/articsputnik

baq · 10 hours ago

Also add a very important feature of ‘lid is closed - the computer is asleep and it wakes up when lid opens’. Both windows and Linux are simply broken in that regard.

What I need is Apple MacBook hardware with a 100% supported Linux OS. This combination simply doesn’t exist and there’s no amount of money to make it happen (yes I know about asahi.)

brabel · 7 hours ago

My god I had to put my Linux (Dell xps13 with Ubuntu from factory, though I installed KDE later) laptop in the drawer as I just couldn’t make it sleep with the lid down. It would simply wake up in the middle of the night and drive me crazy with the fan!! I loved that laptop but it gave me trouble after trouble (stuff like sound breaking after upgrades, Bluetooth failures and many more). My Mac just worked so I use only that now. Though it is old now, around 6 years, and I have to buy a new one soon. Luckily they are having good discount on the M4 right now as I suppose M5 is coming next month?!

brabel commented on I'm too dumb for Zig's new IO interface openmymind.net/Im-Too-Dum... · Posted by u/begoon

ksec · 16 hours ago

I think it is a trade off for between zig's development speed and documentation. It is Pre 1.0, extreme beta mode with lots of breaking changes.

Generally speaking I think it is the right trade off for now. Purely inferring from Andrew and the Zig's team online character as I don't know them in person, I think they do care a lot of DX, things like compiling speed and tools. So I think once 1.0 come I won't be surprised if it will have extremely good documentation as well.

And I would argue, writing good, simple, clear, detailed documentation is actually harder than writing code itself.

brabel · 15 hours ago

I've written many APIs. Never have I got it right without first writing lots of tests, finding the rough corners, improving it... and so on. Writing documentation after that is absolutely mandatory for the end result to be a high quality API. As you write how it is meant to work, you will definitely find things that don't really make sense, or that should not be as hard ( I think this post shows just such an API that hasn't gone through this process ). IMHO documentation is NOT optional. The implementation is NOT how you mean for the API to be used.

brabel commented on I'm too dumb for Zig's new IO interface openmymind.net/Im-Too-Dum... · Posted by u/begoon

hardwaresofton · 17 hours ago

I'm not a Zig PM but the first obvious fix for the issues the OP wrote about is to write better documentation, including usage examples (the more the better, almost to a fault). Also doubles as a good time to reflect on whether the user is having to do too much.

If the tradeoff was absolute performance/avoiding introducing load-bearing performance-lowering abstraction I think that goal was achieved, but DX may have gone out the window.

brabel · 16 hours ago

You’re not familiar with Zig’s culture, I guess. Complain about the lack of documentation and be prepared for the flood of “just read the stdlib code” helpful comments by pretty much everyone who writes Zig right now. Because most APIs are just as hard to use as in this post (check things like HTTP and even basic file system operations) only the strongest survive.

brabel commented on Go is still not good blog.habets.se/2025/07/Go... · Posted by u/ustad

traceroute66 · 2 days ago

> Just all-around a trusty tool in the belt

I agree.

The Go std-lib is fantastic.

Also no dependency-hell with Go, unlike with Python. Just ship an oven-ready binary.

And what's the alternative ?

Java ? Licensing sagas requiring the use of divergent forks. Plus Go is easier to work with, perhaps especially for server-side deployments.

Zig ? Rust ? Complex learning curve. And having to choose e.g. Rust crates re-introduces dependency hell and the potential for supply-chain attacks.

brabel · a day ago

You forgot D. In a world where D exists, it's hard to understand why Go needed to be created. Every critique in this post is not an issue in D. If the effort Google put into Go had gone on making D better, I think D today would be the best language you could use. But as it is, D has had very little investment (by that I mean actual developer time spent on making it better, cleaning it up, writing tools) and it shows.

brabel commented on Data, objects, and how we're railroaded into poor design (2018) tedinski.com/2018/01/23/d... · Posted by u/dvrp

mcdeltat · 3 days ago

IMO the nice thing about Erlang and Elixir is their foundation of representing data is rock solid. Because data is fully immutable, you get a lot of nice things "for free" (no shared state, reliable serialisation, etc). And then on top of that you can add your interfacey, mutable-ish design with processes, if you want. But you will never have oddities or edge cases with the underlying data.

In contrast with languages like C++ and Java where things are shakey from the ground up. If you can't get an integer type right (looking at you, boxing, or you, implicit type conversions), the rest of the language will always be compensating. It's another layer of annoyances to deal with. You'll be having a nice day coding and then be forced to remember that int is different to Integer and have to change your design for no good reason.

Perhaps you disagree with Erlang's approach, but at least it's solid and thought-out. I'd take that over the C++ or Java mess in most cases.

brabel · 3 days ago

That's also Clojure's approach. It's very nice to program with immutable data at a high level, but for certain things, you just need to use the computer's primitives as they actually are, with all the mess that entails. So, I would say we need languages like C++ and Java (but perhaps we should all be using Rust, which makes the mess much more manageable, despite bringing in a lot of complexity that programmers need to wrap their head around, by for example, making it really easy to represent data, and defaulting to immutability) even if it would be "nice" to avoid them where possible.

Erlang and Elixir (and Clojure), however, lack a static type system, which makes it really difficult to use them at large scale (I am happy if you can provide convincing evidence to the contrary - I just haven't seen any). There's Gleam, which is a beautiful, simple language, that has a very good type system, but unfortunately, it's a bit too simple and makes certain things harder, like serialization (e.g. https://hexdocs.pm/gleam_codec/).

Haskell and Ocaml are more usable, but for some reason are extremely niche. I don't think there's any popular language that's in the "statically typed, functional" school, which I think shows that humans just don't prefer using them (they have been hyped for decades now, yet they just never stick). Perhaps a new generation of these languages will change things, like Unison for example (which stays away from Monads but provide an arguably superior abstraction, Abilities - also known as Effects). I think I would love for that to happen, though as I said before: sometimes you still need to reach out for bare metal performance and you have to use Rust/C++/D or even Java.

brabel commented on Universal Tool Calling Protocol (UTCP) github.com/universal-tool... · Posted by u/edweis

brabel · 3 days ago

Why is everyone complaining, this is great and a much needed improvement over MCP. MCP is not yet the "definitive answer", perhaps there's time to replace it with something better.

brabel commented on SimpleIDE github.com/jamesplotts/si... · Posted by u/impendingchange

shortrounddev2 · 3 days ago

I've wanted to create an IDE which uses a multi-window design. I think most IDEs are just doing a left-drawer bottom-drawer layout where the left drawer has all your files in a tree and the bottom drawer has your terminal. I've somewhat recently taken to detaching the solution explorer from the main window in Visual Studio and I'm kind of enjoying it. It's like what used to be GIMP's original default interface, with a main editing canvas and a few floating toolboxes

brabel · 3 days ago

IntelliJ lets you detach separate windows for almost all of the minor panes.

Click on the 3 dots on the top bar, View Mode, Window. It works for example for the file tree, Runners pane, Terminals etc. And it's easy to "dock" them again (an icon shows up in the window to do that) so you can try it easily.

I always keep some stuff like diffs, for example, in separate windows, it just makes me less confused about what's "temporary buffers" (as you would say in emacs) VS "actual files".

brabel commented on A statistical analysis of Rotten Tomatoes statsignificant.com/p/is-... · Posted by u/m463

michaeljx · 3 days ago

I am doing my movie selection via Plex, which has both tomatoes' and IMDb scores in the movie description

brabel · 3 days ago

You guys are opening yourself to manipulation. Why not just be open for surprises? That’s what I do. Most of the time it’s bad surprises, but the occasional masterpiece that everyone else seems to hate make up for it. I do seem to not have the same taste as most people writing reviews though. I almost always find other people’s opinions ludicrous.

brabel commented on Code review can be better tigerbeetle.com/blog/2025... · Posted by u/sealeck

brabel · 3 days ago

Author has not tried IDE plugin for GitHub / Bitbucket reviews!? We review code directly in IntelliJ with full support for commenting, navigation, even merging without leaving the IDE. Solves all problems the author has.

brabel commented on Why Nim? undefined.pyfy.ch/why-nim... · Posted by u/TheWiggles

wolvesechoes · 6 days ago

> excellent performance.

I wanted to check those languages at some point, didn't have time, but I doubt they offer a performance for the stuff I am doing. It is also another reason I discard Java and Go (C# seems slightly better than those).

I deal primarily with scientific/engineering calculations, mostly ODE simulations, so I have some demands regarding performance. Python is of course important, but not for the core production code. Fortran is nice for math stuff, but not much else. C/C++ are as performant as awful. Rust is viable, has nice tooling and ecosystem, but introduces too much hassle that is not that important in my domain. Julia has nice ideas, but poor execution, low quality tooling, AOT delegated to some package that may or may not work with your code etc.

I played with D and it strikes a nice balance. With LDC and careful allocation strategies it can be as performant as Rust, with DMD it compiles much faster, and outside performance-critical code parts it is more ergonomic because of GC. Tooling is decent. Because contrary to sentiment popular on this website I actually think Visual Studio is still the best IDE out there, I am glad that Visual-D exists.

My main issue with D is exactly that - it didn't take off. As a consequence the knowledge-base is small, a lot of things are poorly documented etc. With Nim it is similar, but worse.

brabel · 5 days ago

Do you have any open source code you can share that demonstrates the kind of application you wouldn't be able to get the desired performance in Go/OCaml/Dart?

I ask because I've seen Dart beat Java/Go/D (very high memory throughput, no idea what Dart is doing differently but it's amazingly good at it)... but I can imagine that if you only perform numerical computation, Dart may miss optimisations that will make it slower (normally, it will be optimised to approximately the same as you'd written in C, but in some cases it can hit the "slow path" - those are getting less and less every release, and if you provide an example the Dart team would likely be happy to fix that).