Live data from Hacker News

Stop Building on Corporate-Controlled Languages

blog.deckc.hair

201–210 of 324 posts

Re: Stop Building on Corporate-Controlled Languages

#201

Earlier quoted context omitted.

Rust will probably encompass most of these use cases eventually. Features like e.g. RC with efficient cycle collection as found in Nim, or generational regions as found in Vale, will simply be implemented as add-on crates in Rust, complementing the existing borrow checker.

There are some design decisions mean Rust can't work with generational references and regions, unfortunately. They're incompatible with their form of borrow checking. In Vale, each struct has a generation in theory, but they are often merged with their parent struct. It requires some pretty interesting logic which can't be implemented in Rust. Regions require truly immutable references, which Rust doesn't have. Their…

I don't disagree that Rust's developer productivity story is still far from mature, especially wrt. async and its ecosystem (and the Rust design team agrees that this is a concern) but if you're going to argue for Vala as a "future design", we should similarly assess Rust's long-term potential. The language is improving quite fast and adding major new features (consider GAT and improvements in const evaluation) despite being quite stable and reliable in other respects. Very different from most "corporate"-focused languages.

(Don't get me wrong, I'm quite fine with also focusing on hobbyist, proof-of-concept languages for potential improvements to developer productivity. But then I'll probably want a Pony.)

Re: Stop Building on Corporate-Controlled Languages

#202
post #91

Earlier quoted context omitted.

> I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen. This is exactly where I am at. I use Windows/C#/.NET without any shame for absolutely everything. The more developers who give me grief on some principled basis that " bad, so everything related is bad", the more I double-down on my position. These non-technical argumen…

In the late 90's I used to sit next to a team of about 20 VB developers. When MS decided to make VB obsolete, those folks had to re-learn software development and were getting intern like opportunities because suddenly all that VB knowledge and experience was worth exactly zero. Hopefully y'all fare better when they decide to nuke C# and .NET.

It was technically possible for someone to write a VB compiler and enough of a runtime to integrate VB code with Visual Fred and the rest of the .Net ecosystem. That this apparently never occurred to anyone says interesting things about that development culture, but the big lesson is to not rely on a single source for a language implementation or tooling in general. Go not only has an open-source primary implementation, it has, like, a few thousand righteously angry hackers in its culture who would take Google abandoning it as a personal affront and would work on a replacement Go implementation in a pure example of spite-driven development.

Re: Stop Building on Corporate-Controlled Languages

#203

Earlier quoted context omitted.

In the late 90's I used to sit next to a team of about 20 VB developers. When MS decided to make VB obsolete, those folks had to re-learn software development and were getting intern like opportunities because suddenly all that VB knowledge and experience was worth exactly zero. Hopefully y'all fare better when they decide to nuke C# and .NET.

> all that VB knowledge and experience was worth exactly zero Except that didn't happen at all. Visual Basic still exists. From Microsoft (2020): > One of the major benefits of using Visual Basic is that the language has been stable for a very long time. (Source: Microsoft, on Visual Basic support in .NET 5: https://devblogs.microsoft.com/vbteam/visual-basic-support-p... ) As of January 2023, the latest version of Vi…

VB6 does not equal VB.Net.

I personally know developers who switched careers after Microsoft transitioned to .Net. I worked with them around 2001.

They didn't understand OOP concepts and were not interested in having to relearn everything. It felt totally unfamiliar and strange to them. Microsoft tried to make the syntax somewhat familiar, but at the end of the day .Net is an object-oriented programming language and VB6, try as it might, was not. And that was too steep of a hill to climb for them.

Re: Stop Building on Corporate-Controlled Languages

#204
post #51

Earlier quoted context omitted.

> The corp still doesn't need to take direction, nor input, nor patches from the community. >The corp can steer the language and frameworks wherever they want. Sure, you may be able to then fork it, but is that fork going to gain any traction? Probably not. These both apply to not-corporate projects as well.

But if it's a non-corporate project, and the lead/owner/BDFL decides to go in an evil (or just stupid) direction, and I fork it, my fork has a better chance of gaining some traction. It's not perfect, but it's somewhat better. (Or so I suspect - I haven't ever been in that position.)

I would assume this also applies to corporate projects as well.

Perfect example: There are 2 Plex alternatives I know of that sort of fit this mold. One is called Emby that started as open source and turned into a closed source commercial product. The other Jellyfin which is (from what I can tell) an open source fork of Emby from before it went closed. Both seem to have picked up some amount of traction.

Re: Stop Building on Corporate-Controlled Languages

#205

I think this is a fairly misguided rant, and ignores the real priorities (and risks) that I have as a developer - both personally and professionally. I'm happy to use languages funded by corporations - the incentives for them are clear, they fund development and work on the tooling and spec for their own use-case - they garner additional support, momentum, and goodwill by releasing the language under an open definiti…

He admits C was corp sponsored though. "Admittedly C also came from a corporation but it came free with every unix install and soon after I started using it, Richard Stallman et al. gave us GCC, a free C compiler." But at the time AT&T couldn't spy on its CC users though so the risk was lower I guess.

> But at the time AT&T couldn't spy on its CC users though so the risk was lower I guess.

Sure they could... What do you think there were doing when they were selling System III & System V?

They compiled customer lists, and sales contacts, contract agreements and everything else you'd expect from an org selling commercial software. Was it "automated" in the same way that tracking use from a package manager is? No. Was it tracking? Fuck yes.

Unix wasn't free until the FSF began the GNU project...

Hell, even the BSD variants of unix were sold - they weren't free software. Are there free implementations that exist today? Yes. They exist because the item being sold and maintained by the corporation is NOT the spec for the language/os (the recipe) it's their implementation of it.

Re: Stop Building on Corporate-Controlled Languages

#206

Yeah, I don't want to use the Microsoft language (C#) Certainly not the Oracle Language (Java) I like the Google Language (Go) and it's BSD so maybe safe-ish? I'm not in that ecosystem, but I'd use the Apple language (Swift) if I had to. Maybe the JetBrains language (Kotlin) is okay? I hear lots of buzz about the Mozilla language (Rust), maybe they have a good history of open source stewardship. The Guido language is…

Rust isn't a Mozilla language. It started there but it has it's own foundation and isn't under Mozilla's stewardship.

Re: Stop Building on Corporate-Controlled Languages

#207

Earlier quoted context omitted.

There are some design decisions mean Rust can't work with generational references and regions, unfortunately. They're incompatible with their form of borrow checking. In Vale, each struct has a generation in theory, but they are often merged with their parent struct. It requires some pretty interesting logic which can't be implemented in Rust. Regions require truly immutable references, which Rust doesn't have. Their…

I don't disagree that Rust's developer productivity story is still far from mature, especially wrt. async and its ecosystem (and the Rust design team agrees that this is a concern) but if you're going to argue for Vala as a "future design", we should similarly assess Rust's long-term potential. The language is improving quite fast and adding major new features (consider GAT and improvements in const evaluation) despi…

That's a fair perspective. I don't have the same faith in Rust's dominance for high-level use as these problems seem inherent to their kind of borrow checking, but its possible they can compensate for it with improvements like the ones you mentioned.

Re: Stop Building on Corporate-Controlled Languages

#208

Earlier quoted context omitted.

These Microsoft examples are 20 years old. The company has changed leadership to a team that embraces open source years ago and I think they've done a pretty good job demonstrating this embrace. They have adopted open source Java, they further open sourced .NET, they've embraced Linux containers in Azure and WSL on windows, etc. Might be about time to reconsider this perspective of 'hate Microsoft'. Full disclosure:…

Microsoft is certainly embracing open source. It looks like Mono is still with us after open sourcing .NET, though it's now sponsored by Microsoft. They bought GitHub and kept it running. Are they still doing the extend with useful features not found elsewhere part? I don't follow their stack closely enough to know.

Visual Studio Code's Free version is crippled by, among other things, not being able to use certain language servers.

Re: Stop Building on Corporate-Controlled Languages

#209

Earlier quoted context omitted.

VB.NET has only superficial similarities to VB 6 and before. Microsoft discontinued the original VB in favor of VB.NET, but the engine lives on in VBA and Microsoft has used VB6 to build various internal things (I think some of the UI to Windows Defender is VB6). But for most "Microsoft shops", VB6 was a dead end, and that left a lot of VB developers out in the cold. They had to reskill with the .NET stuff (significa…

> They had to reskill... This always baffles me. It doesn't surprise me, but it baffles me. Why are so many professional developers having to "reskill" to adapt to a new language? We're not necessarily talking about new domains (that would be different, there's a lot I don't know about server administration and automation, for instance, given my background primarily with embedded and desktop systems). But a language…

Did you use VB6? It was less a language and more of a wysiwyg windows desktop GUI application builder. If that's what you learned in school and it was your first professional job, you would have a very difficult road ahead of you learning something like C. Maybe 3 out of the 20 were successful moving on. Some VB apps had almost no code at all that wasn't auto generated by the platform and bound to UI elements to handle button clicks and so on.

Re: Stop Building on Corporate-Controlled Languages

#210

Earlier quoted context omitted.

VB.NET has only superficial similarities to VB 6 and before. Microsoft discontinued the original VB in favor of VB.NET, but the engine lives on in VBA and Microsoft has used VB6 to build various internal things (I think some of the UI to Windows Defender is VB6). But for most "Microsoft shops", VB6 was a dead end, and that left a lot of VB developers out in the cold. They had to reskill with the .NET stuff (significa…

> They had to reskill... This always baffles me. It doesn't surprise me, but it baffles me. Why are so many professional developers having to "reskill" to adapt to a new language? We're not necessarily talking about new domains (that would be different, there's a lot I don't know about server administration and automation, for instance, given my background primarily with embedded and desktop systems). But a language…

VB6 is an entirely different beast. A professional VB6 developer who didn't have formal training was very well insulated from what their code actually did - that's not to say that they weren't, or that their weren't extremely talented VB6 developers. It's just that for many developers who fell into it from scripting or who invested all of their time and learning into the pre-.NET ecosystem, they had to choose to relearn a significant amount of technical content. Even though the languages were syntactically similar, jumping from VB6 to VB.Net meant learning an entirely new framework and object model, and having to deal with some issues that were hidden from them before.

In many cases it was as different as using BASIC vs Pascal or even C to write CLI tools (a hurdle I jumped in high school in the mid-90s, and despite doing alot of stuff with PEEK and POKE in basic, understanding pointers took me longer than I care to admit :P)

Post reply on HN