HN user
martin@martinsvanberg.com
One thing that would be genuinely useful would be the ability to integrate Claude with the Metal debugger somehow, to get automated analysis of GPU profiling. The .gputrace format is proprietary and cannot be easily analyzed, and it seems that the new "agentic coding" integration in Xcode also does nothing to expose this data to LLMs. Oh well.
I kind of see myself from ten years ago in this blog post! I also obsessively studied Mandarin Chinese in my late teens for the sheer fun of it, before doing a math undergrad. I even wrote comments on Hacker News about it a decade ago: https://news.ycombinator.com/item?id=7622940.
At the time I had seemingly limitless motivation for grinding away on flashcards and other learning materials. My progress was strong and I passed the HSK6 after a year and a half or so of studying, which at the time was the highest level of certification offered. I think they changed the system since and added more levels beyond 6. You can do amazing things if you're dedicated!
Today my Chinese is absolutely unusable, and my views on China have soured to the extent that I don't really want to revive my old skills. My takeaway is that learning one of these languages, the CJK languages, Arabic, or similarly weird languages, is just too much effort and I don't think it's worth it. I clearly had a lot of excess energy at the time that I could've directed towards something better. Knowing Chinese is about as useful as juggling and you might as well get really good at juggling if you're bored. It'll save you a few thousand hours.
This is because you chose to live an expensive life. Most of the world gets by on less.
As a current Nix user, what I would really like is a statically typed language to define builds. Recreating Nix without addressing that feels like a missed opportunity.
This one has some more traction: https://github.com/fu5ha/ultraviolet
Bit of a side note, but COSMIC depends on the rustybuzz text shaper which is deprecated: https://github.com/RazrFalcon/rustybuzz/issues/74. There was some work underway to bring it up to sync with the latest harfbuzz and then handing over ownership to the harfbuzz team, but this seems to have fizzled out.
I think the final remark about a hypothetical language, Rust-like but without all the low-level requirements, is important here. There is essentially no widely-adopted programming language out that feels like a modern ML with a good tooling situation. Until that happens, Rust will continue to awkwardly serve the audience of such a language while never truly being what they want it to be.
A 4K monitor has 8.3M pixels, so you could equivalently say that it's ~three 4K monitors.
Lots of negativity in here. I for one am excited about the prospect of an editor that is as responsive as I remember Sublime being back in the day, with the feature set I've come to expect from VS Code. An editor like this simply does not exist today, and betting on the Rust ecosystem is entirely the right choice for building something like this in 2023.
And in that case, what causes the discrepancy in productivity between London and SF?
You'd think there would be an arbitrage opportunity in paying more $$$ for London talent. Still surprises me that this hasn't happened after all these years of huge differences.
How does Meilisearch compare to ElasticSearch from an operational point of view? I've experienced ElasticSearch to be quite painful to maintain, requiring lots of manual tweaking to balance shards and careful design of indices.
From the slog Github repo:
You might consider using tracing instead. It's been a while since slog was created and it served Rust community well all this time. It remains a stable, featureful and battle-tested library, used in many important projects.
In last few years, another ecosystem for Rust was created with similar features and a very good support for debugging async code and already larger dev team and community.
Please check tracing and see if it is more suitable for your use-case. It seems that it is already a go-to logging/tracing solution for Rust.
Reasons you might want to stick with slog anyway:
async support doesn't benefit you
you consider mature, stable code & API a plus
it has some features that tracing is missing
great performance (I have NOT done any comparison, but slog's performance is very good).
I've used both of the suggested methods under "Current standards for scaling out databases" so I see where this is coming from. But I peeked at the AWS reference architecture, and it places a Consul and ReadySet deployment in my environment for me to run and maintain. I feel like any sales pitch for this really needs to convince me that having these things in my environments is going to be worth the hassle in terms of milliseconds and dollars, as opposed to just using RDS read replicas and paying a bit more. Then again, I can see this being an obvious choice if you're growing very quickly or have tight latency requirements.
With that said, it looks like cool tech and I read Jon's Rust for Rustaceans which serves as a stamp of quality for this even if I haven't tried it yet!
The project has run out of funds: https://github.com/onivim/oni2/issues/3811#issuecomment-9103....
Considering how many people are annoyed by the trend of Electron everywhere, it's a bit sad to see an ambitious native editor like this unable to secure funding.
It's not written in JavaScript.
Since it's closed-source, privately owned and not based on any open standards, it doesn't work on Linux or any mobile device that isn't using Google Play Services or iOS.
It's convenient, but it's an absolute travesty that we've left such an essential part of digital infrastructure to big banks.
A lot of new technology eventually becomes boring technology, and this is because of adoption in companies exactly in the way the author is discouraging. When the new becomes boring, everyone gets to reap the benefits of the new tech.
The world of software rests on the hard work of others, whether it's open source maintainers spending their free time making libraries for peanuts, or it's people going through the pain of productionizing a new technology. Being in the boring technology club is in a sense also being in the freeloader club, never contributing back to the state of the art.
It's a good article. It makes us aware of the drive many have to use the new thing, and the negative consequences of following this drive blindly. But I'm also happy that people do it.
Over the years I have learned and dipped my toes in many programming languages, and I'd need some kind of reason to look into yet another language. What are Raku's main contributions to the programming language design space that I probably haven't seen elsewhere?
It seems like there's a ton of interest in Bevy! You must be spending a lot of time discussing things, reviewing PRs, doing outreach and community building like here. Is there any time left for the hard feature work? Are there any core members apart from you?
(Don't burn out!)
But people don't use Brave because they care about privacy. It's the whole monetization angle that appeals to people, right?
Presumably they think decentralization is a benefit in its own right.
Languages like Haskell and Go already have multicore GCs. How does OCaml's multicore GC compare? Is the work taking a long time because it is doing something brand new in the design space, or is it simply hard to integrate it with a mature language that was designed to be single core?
If you're running macOS, remember that built-in bash is from 2007 and won't support all the fancy stuff like ${VAR^}.
I think it's just not gonna fly in many organizations. You need the people who are going to be working with it and maintaining it to buy into it, and you also need to convince whoever is in charge of technology choices that it's a good idea. If you are the latter yourself, then that's half the problem solved.
It's probably easier to join an organization that is already positive towards it.
I look at go and I see an admission of defeat in programming language design. The central idea of go is that the way to have a language that is productive in the large is to impair it as much as possible. Unfortunately this idea seems to have been wildly successful.
The problem is that revenue from paying subscribers is not enough. For most newspapers, ads are needed to run a profitable digital business. Ads cannot be removed for paying subscribers, since paying subscribers are precisely who advertisers want to target. And if you want to display ads on the internet, you have to track people just like your competitors Google and Facebook do.
If news companies believe their core purpose is the dissemination of valuable information, it would make a lot of sense for them to provide a text-only static version of their website.
I think most serious news companies think they have an important democratic mission. But at the end of the day, the economics have to make sense in order for quality journalism to exist in the first place.
So Apple made a decent MacBook Pro again. Good. But they still haven't made things right for the lemon they sold me. My keyboard is still not working, even after I handed it in for repair twice. Now I'm expected to shell out a few more grand just to have a working f key, and Apple is not even willing to acknowledge that they for years sold faulty products to gullible idiots like me.
Would it really hurt their octibajillion dollar valuation too much to just make things right for the customers who got shafted by their broken keyboard design?
This was announced on the Future of Coding Slack [1] not long ago. I encourage people who are into things like structured/projectional editors, visual programming and other wild re-imaginations of programming to join.
None of my colleagues or friends are using Sublime anymore. I think that there's a chart somewhere at Sublime HQ that looks like a ski slope.