Nah, this is a very good point; I've seen things similar to this in the past and it's a cool idea -- but "subscription modeling" every little tool is not a good path to keep going down.
Free and open source is important and it's perfectly fine to be critical here.
Demanding everything be free and open source is important if you don't want independent developers to be able to make a living, and instead wish to create a world where the vast majority of software is controlled by big tech, who are the benefactors of "free" software. The less you're willing to pay people making good software, the more territory predatory ad/tracking-fueled "free" software gets. The more territory you give them, the more they're going to buy out open source software to destroy. We see this happening more and more recently, with uv, bun, vite etc. being bought out - if they can't put food on the table, they will sell out to monopolists.
I agree that I would never pay a subscription fee for any kind of system functionality, but there is a lifetime purchase option available, so there is no grounds to critique that here. Having extra payments models available in addition to a regular purchase model does not make a product worse.
I made a very good living developing open source software for more than a decade. Nothing about open source software precludes one from making money, it's just a different business model from closed source.
A business model that supports a tiny fraction of the market. To the extent there is money in FOSS, even then most of it is provided by the funding of big tech (a whole host of some of the most widely-used FOSS, like Linux, LLVM, Go, Rust, C#, Typescript, VSCode, React, are all obviously corporate-backed). Independent developers who can make a living selling FOSS exist, but are absolutely on the fringe.
Yeah, but I didn't do that. I think I really did mean "little tool" here. This (likely) just isn't the right scale for a pay-to-play project. Obsidian kind of figured this out, but my gut is that this thing is too small.
You just don't get it. It's a critical system tool that's being discussed here. For someone serious about their privacy, it's a valid point. It's not open source nor is from a reputed enterprise. What's preventing the developer from adding a key logger or so?
> What's preventing the developer from adding a key logger or so?
They can log my keys all they want, I would never give a program like this internet access because it has no valid reason to ever connect to the internet (after purchasing a lifetime license). If you're serious about your privacy surely you take a little bit of responsibility for not giving every program you run unfettered access to your system?
I push back against people criticising independent software for not being free because I believe it is deeply harmful for our industry. My initial reply didn't have much susbtance, but then neither did the comment I was replying to.
I think the Google Go style guide is really nice and pragmatic. There are some references to the GoTips for some advanced subjects. I hope they release it someday.
Although the handhelds have been backwards compatible, only the Wii and the Wii U had backwards compatibility. The SNES, N64, Gamecube and Switch did not have backwards compatibility.
The SNES and the Gamecube did have the Super Game Boy and Game Boy Player respectively though, but I'd probably count that as sideward compatibility rather than backward compatibility.
Although NativeAOT sounds cool and it's better than nothing: I don't like that it comes with a bunch of limitations[1]. I would have loved this if you could just use it without any changes, but I'm very worried that at some point I used something that prevents me from getting it to work and I have to figure out which limitation I just walked into. Correct me if I'm wrong.
Those limitations are often obvious. With AOT, you don't have the VM around, you can't load new bytecode or introspect the objects. I would focus on writing working code, and try to go AOT close to the end. If it fails and it's not fixable, tough luck, but it works on the standard runtime.
Technically speaking, there is VM (you could also consider GC to be a part of it, but in HN understanding it's an umbrella term that can mean many things). Because the type system facilities are there which is what allows reflection to work.
The main source of confusion as to why some believe that NativeAOT prohibits this are libraries which perform unbound reflection in a way that isn't statically analyzable (think accessing a method by a computed string that the compiler cannot see and not annotating with attributes the exact members you would like to keep and compile the code for) or libraries which rely on reflection emit. But even reflection emit works for limited scenarios where runtime compilation is not actually required like constructing a generic method where argument is a class - there could only be a single generic instantiation of __Canon argument in this case, which can be emitted at compile time. You can even expect the reflection to work faster under NativeAOT - it uses a more modern pure C# implementation and does not need to deal with the fact that types can be added or removed at runtime.
That's interesting - I would have thought targeting aot at the outset and then switching away only when the design became incompatible would be more effective, only because by going for aot at the end I'd probably have introduced some code or dependency that isn't aot compatible and yet too much work to replace
With source generation, I'd say that its biggest limitation is rapidly diminishing. Even ASP.NET Core is embracing it, allowing for better support for json deserialization and eventually MVC.
reply