Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Building on Corporate-Controlled Languages

blog.deckc.hair

Post reply on HN
Print view View original

191–200 of 324 posts

Re: Stop Building on Corporate-Controlled Languages

#191

Post by ignoramous »

FireInsight wrote: post #118
brianolson wrote: post #103

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…

Kotlin is not just okay, it's pretty great IMHO. Elegant and expressive, feels familiar. The only reason I only use it when I need to is JVM, and the fact that googling anything Kotlin-related brings up results android. Just answering your question^^

Completely agree.

Outside of Android app development, AWS uses Kotlin for its backend systems: http://web.archive.org/web/20200706214913/https://talkingkot...

Re: Stop Building on Corporate-Controlled Languages

#192

Post by xahrepap »

stcroixx wrote: post #123
bob1029 wrote: 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.

C# and .NET is an MIT licensed code base.

Not to mention with a community that built an alternative implementation so strong that MS ended up buying the company the emerged from it. And this was before .Net Core was fully open sourced.

I’m not worried about C# or .Net getting nuked.

Re: Stop Building on Corporate-Controlled Languages

#193

Post by kortex »

Calavar wrote: post #98
brokencode wrote: post #63

Earlier quoted context omitted.

The whole ownership and borrowing system is a type of automatic memory management. It just happens at compile time instead of runtime like most automatic memory management systems. Manual memory management is possible in Rust, but is not typically something developers need to interact with. There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects aut…

> There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects automatically when they go out of scope. By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management. The compiler implicitly inserting a call to the destructor does not automate the decision of when/where to allocat…

> By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management.

That's not really what's meant by manual memory management. MMM almost always means things like malloc/free, arenas, buffers with pointers, etc. I would not call stack allocation "manual", and IMO Rust's system is closer to stack allocation than it is to either manual or automatic memory.

In terms of DX, bugs and ergonomics, you only really have two schemes: ones which requre some kind of free() call and thus permit use-after-free bugs (manual) and those that make it impossible (ignoring weakref and friends). Rust is not manual by virtue of no free() instruction. In the same breath, "automatic memory management" is not an exact antonym of manual.

Re: Stop Building on Corporate-Controlled Languages

#194

Post by brushfoot »

bitwize wrote: post #176
brushfoot wrote: post #150

Earlier quoted context omitted.

> 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…

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…

> VB.NET has only superficial similarities to VB 6 and before.

There are differences, but the similarities are more than superficial. Some of my first apps were in 6, and then I transitioned to VB.NET in the early 2000s. At the very least, it pretty familiar and intuitive.

Even VBA is pretty similar to the VB.NET apps I developed in terms of OOP, syntax, autocompletion in the editor, event handlers, and so on.

Again, there are definitely differences, but there was no "[relearning] software development and getting intern like opportunities" like the comment I was replying to said, and my knowledge and experience was definitely not "worth exactly zero." It was just an evolution.

Re: Stop Building on Corporate-Controlled Languages

#195

Post by philwelch »

nandalism wrote: post #181
rblatz wrote: post #27

Earlier quoted context omitted.

I’d also like to throw another counter example out. C# and Typescript from Microsoft are both excellent languages and are led by Anders Hejlsberg.

Is that the same Anders Hejlsberg who developed Turbo Pascal and Delphi for Borland, another company which microsoft successfully crushed in the 80's and 90's? (Hint: It is). We could have C# 30 years before we did if it weren't for microsoft.

C# came out in 2000; Microsoft didn't even exist in 1970.

Re: Stop Building on Corporate-Controlled Languages

#197

Post by brokencode »

Calavar wrote: post #98
brokencode wrote: post #63

Earlier quoted context omitted.

The whole ownership and borrowing system is a type of automatic memory management. It just happens at compile time instead of runtime like most automatic memory management systems. Manual memory management is possible in Rust, but is not typically something developers need to interact with. There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects aut…

> There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects automatically when they go out of scope. By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management. The compiler implicitly inserting a call to the destructor does not automate the decision of when/where to allocat…

Even in languages with a garbage collector you make decisions that impact the lifetime of an object. That is not what makes the memory management manual.

For instance, you can still have a memory leak in Java if you maintain a reference to an object that you never intend to use again. It’s still up to the programmer to prevent this.

> With true automatic memory management like tracing GC or reference counting, you have no idea where the or when the memory will be freed as you write the code, and the answer will usually be different over different invocations of the same code.

This just isn’t true, and it would be anarchy. You know that the object will be freed sometime after the last reference to it dies. This is the whole reason to use automatic memory management.

Reference counting approaches typically go even further and free the memory immediately when the last reference is eliminated.

And this is basically what Rust does with ownership. When the object goes out of scope and ownership is not transferred, the memory is freed. It’s just that it doesn’t always need the reference counting part. But you can rest assured that it will be freed.

With manual memory management, the programmer must manually free the object, and there is no automatic method to do this once there are no references. That is what makes it manual. The programmer might forget to free the memory or they might free memory too soon and try to use an object after it’s already been freed. This is not the case in Rust.

Re: Stop Building on Corporate-Controlled Languages

#198

Post by elcritch »

jchw wrote: post #23

My response to the plea in this article is simply "No thanks." If Go gets that bad, I'd be happy to use an ungoogled fork of it, or migrate to another toolchain or language, or whatever needs to happen. But until then, 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. I want production quality toolchain and runtimes. Tha…

One small note, but Nim's comptime support is on par with Zig's. It's preferred using comptime and templates over macros when possible.

Here's an example (1) of a compile time object to key value layer I did without macros. It's a basic wrapper to split an object's fields into separate key-value pairs for storage. The problem is that the storage system only has 16bit ints for keys which makes collision a large possibility. So this wrapper checks at compile time that there aren't duplicate keys.

1: https://github.com/EmbeddedNim/nephyr/blob/main/src/nephyr/e...

Re: Stop Building on Corporate-Controlled Languages

#199

Post by yashap »

hgsgm wrote: post #168
yashap wrote: post #142

The author specifically calls out Google/Go, Apple/Swift and Microsoft/C#, around tools that do compilation and package management spying on you. It's worth noting that this potential exists in both corporate-controlled and non-corporate-controlled languages, but ... have there actually been any incidents of Go/Swift/C# doing anything sketchy here? IMO this argument needs specifics, because non-corporate projects can…

I don't see the benefit of eschewing a proprietary runtime and them running your program on a proprietary OS owned by the same company.

Are you referring here to Apple/Swift/iOS/OSX, and Microsoft/C#/Windows? If so, good point, if you're writing iOS mobile apps, or OSX/Windows desktop apps, you're pretty tied to Apple/Microsoft regardless of the language you choose.

Not so applicable to Go - ppl mostly use it for writing servers running on Linux.

Re: Stop Building on Corporate-Controlled Languages

#200

Post by Jtsummers »

bitwize wrote: post #176
brushfoot wrote: post #150

Earlier quoted context omitted.

> 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…

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? And a procedural/imperative language? VB, C, C++, Pascal, Delphi, C#, Java, JavaScript, Ada, Python, Rust, Go, Fortran, etc. are all, fundamentally, procedural/imperative languages with varying degrees of OO, functional, and metaprogramming capabilities distinguishing between them. Some are bigger jumps (I'd point to Rust as the biggest in that group) than others, but what "reskilling" does a programmer or developer need when switching between languages in roughly the same language family? It's not like they had to jump to Haskell or Prolog or something that was majorly different.

Post reply on HN