News for hackers. Stuff that matters.

RX14

Have you considered the syntax crystal uses i.e. 42_i32 and 42_u8?
Re:Btrfs/ZFS/bcachefs under workloads classic benchmarks skip on Sunday September 20, 2026 @04:52AM (#49773895)
Personally I've had 0 issues with the bcachefs dkms packages from distro repos. Unlike zfs it keeps up with upstream kernel releases so it's far less hassle than running zfs dkms.
It's had consistent contributions for 5 years now, with the latest being about a month ago.
Re:Why BART uses a nonstandard broad gauge on Saturday July 09, 2022 @08:40AM (#32034507)
Hunting in modern rail vehicles is largely a solved problem using axle yaw dampers and other systems. I struggle to see why BART doesnt use a standard wheel profile and buy from a rolling stock supplier with experience of designing for good ride quality.
Re:Why BART uses a nonstandard broad gauge on Saturday July 09, 2022 @08:38AM (#32034487)
There are some trains which use independent wheels, but they need complicated mechanical centering mechanisms to replace the self-centering effect, and these are more expensive to maintain.
Re:Why BART uses a nonstandard broad gauge on Saturday July 09, 2022 @08:34AM (#32034456)
Long-distance trains in the UK manage about the same, with 200km/h max, but for more of the track (and higher accel/decel)
The -ls flag to find prints the same as ls
Re:Make LLVM Fast Again on Monday May 11, 2020 @05:32AM (#23140350)
I would greatly greatly appreciate an effort to benchmark builds without optimizations too. We've seen some LLVM-related slowdowns in Crystal, and --release compile times are far less important than non-release builds to us.
Re:Five Years of Btrfs on Monday January 27, 2020 @02:36PM (#22162915)
DBMSes always keep their database in the file system in a consistent state to be able to recover from system crashes. Taking a file system snapshot is equivalent to pulling the power on the database server in terms of data recovery, but databases are designed to support this.
Re:Five Years of Btrfs on Monday January 27, 2020 @02:32PM (#22162873)
It seems a lot of people have these stories, and then people like me and OP who have had btrfs survive the most fucked up situations (I've had a btrfs nas built on "random drives I've had lying around" and abused it for 5 years and had 0 bugs at all).

I'm not sure what causes it, but there seems to be an effect where btrfs loves you or hates you and few people with mixed experiences regarding data loss. One possible cause is distro choice tends to be per person and how up to date said distro keeps it's kernel. But, I'm not sure.

Re:Nim vs. Crystal on Sunday December 29, 2019 @07:47PM (#21909808)
My secondary motive is that I'm a girl :)

I certainly wasn't much more than sleepy and wanting to break the stereotypes on that particular expression when I wrote it.

Re:Nim vs. Crystal on Friday December 27, 2019 @05:08AM (#21890341)
First class? About a girl-year or two I'd guess. Fully usable? About half that.
Re:Nim vs. Crystal on Friday December 27, 2019 @05:07AM (#21890334)
If you reach out to manas directly, I'm sure they will be happy to have a sponsor for a particular feature.
Re:Nim vs. Crystal on Thursday December 26, 2019 @06:34PM (#21887805)
Yes, you can do the same optimizations in Crystal, and Nim. Someone should write these and post the code for comparison.
Re:Nim vs. Crystal on Thursday December 26, 2019 @06:26PM (#21887771)
Hopefully wasm's gc proposals will be implemented and get LLVM support, allowing languages like Crystal to sanely support wasm.
Re:Nim vs. Crystal on Thursday December 26, 2019 @06:22PM (#21887736)
Yes, we do so for more complex formats like YAML and XML. However, for JSON, reimplementing is worth it for binary portability.
Re:Nim vs. Crystal on Thursday December 26, 2019 @06:18PM (#21887723)
The basic foundations of a Windows port are already in place for Crystal, merged into master. In fact you can can already cross-compile a "Hello World" on Windows.

This means the port is in a place where the community can pitch in and help port little bits of the standard library, and help bring it into a release-ready condition.

Re:Nim vs. Crystal on Thursday December 26, 2019 @06:14PM (#21887694)
Unfortunately there's no concrete timeline, it's being worked on on-and-off by the community.

If you have free time, or free money, it'd be a great help to the effort.

Re:Nim vs. Crystal on Thursday December 26, 2019 @11:28AM (#21884869)
JSON is actually implemented entirely in Crystal for Crystal, I'm pretty sure it's the same for Nim too.

For a language which claims to be fast, having to use a C-based JSON parser would be a bit of a cop-out :)

Re:Nim vs. Crystal on Thursday December 26, 2019 @11:20AM (#21884805)
The JSON code is written in a way which forces the whole object to be loaded into memory - both in Nim and Crystal. It would be interesting to compare code clarity and benchmarks for a streaming JSON implementation though.

Agree that performance comparisons between Nim and Crystal are going to be largely moot. They're both "fast enough" for their target audiences.

Re:Nim vs. Crystal on Thursday December 26, 2019 @11:09AM (#21884713)
> We’ve been waiting for years.

I know, and it's unfortunate that there's not been time to work on this. I don't think people understand how small a language like Crystal is though. There's just one person working full-time on it currently!

If you'd like Windows support, one thing you could do to help is donate time or money to the Crystal project [1].

[1] https://salt.bountysource.com/teams/crystal-lang and https://opencollective.com/crystal-lang

Re:Nim vs. Crystal on Thursday December 26, 2019 @11:04AM (#21884685)
Nice article!

There's one small error, where the article says "With Nim, we were also able to link both the Nim and C files into the same executable, which Crystal sadly cannot do." However, this is not true! You've passed the object file you created directly to the linker, so it is in fact included directly in the executable.

I'm a core team member of Crystal, feel free to ask away.

Re:Lilith: x86-64 OS written in Crystal on Tuesday December 24, 2019 @05:47AM (#21871135)
We used to be a pretty nice purple, and I kinda miss that.
Re:Lilith: x86-64 OS written in Crystal on Monday December 23, 2019 @08:50AM (#21863555)
It's unique selling point is union types as a part of the type system, with whole-program type inference and flow typing. This has never been done before (as far as I am aware), and it is incredibly powerful and interesting. It's compile-time duck typing.
It's certainly decentralized, just federated instead of distributed.

And yeah, it sucks as a protocol (but not that badly, the standard is just weak like everything else the w3c produces) but it's better than reinventing the wheel. Or letting twitter unilaterally dictate a standard.

And please stop spamming the same message down the page.

Re:XMPP: A Communication Protocol for the Internet of Things on Saturday October 05, 2019 @05:01AM (#21164491)
Matrix is a fundamentally broken protocol held up by the prowess of it's UI design team.
Re:Apple approves previously rejected HKMap.live app on Saturday October 05, 2019 @04:00AM (#21164317)
A long poll connection (i.e., a TCP connection not sending packets) uses exactly 0 joules of battery until something is sent.
Someone who has been doing this for years before serverless existed can set up and manage this infrastructure trivially, using almost no time compared to developing the application and the business. It also provides you with security: you know the pitfalls and the problems with hosting these, serverless is another new technology which can go wrong.
Re:Aerc – An email client that runs in the terminal on Tuesday June 04, 2019 @07:35AM (#20093951)
I suspect it's because he's so successful at spawning developer communities around the software he writes. Just look at sway: between 1.0 and 1.1 he was nowhere near the largest contributor. I'd guess that means a lot of time to work on other projects.
Re:Firefox 66.0 Aims to Reduce Online Annoyances on Tuesday March 19, 2019 @10:46AM (#19431252)
It's not a feature and you can't disable it, previously it'd just crash. I think it's to do with the content workers being `exec`d from disk each time instead of forking from a master.

Older »