Live data from Hacker News

Fun facts about Rust's growing popularity

jonathanturner.org

131–136 of 136 posts

Re: Fun facts about Rust's growing popularity

#131
post #24

Earlier quoted context omitted.

> However, in cases where people say that some language is bad, it means that it simply does not fit their tasks. I disagree. It is possible for a language to simply be a bad language. Intercal is intentionally so. I will refrain from mentioning unintentionally bad languages in order to avoid a flame war.

Nobody would have accused Brainfuck of being a good language but it turns out that its radical simplicity works well for integrating with optimization algorithms for creating self-programming AIs. It's all about a niche, except INTERCAL, you're right about INTERCAL.

Wait, what? I really want to see some links or papers about that. Care to share?

Re: Fun facts about Rust's growing popularity

#132
post #4

Best fact: Rust users are apparently called Rustaceans. I did not know this, and have never seen this wonderful term before.

Please please please can we stop with the Rustacean/Gopher/etc crap? You don't need a cutesy label to identify that you use a tool. I enjoy Doctor Who (though it's been getting worse for the last 5 or so years) but I do NOT want to be called a Whovian. What's the first image that pops into your head when I say "Trekkie"? It's probably not someone with good health and hygiene, is it?

Yep. I'm a programmer. I can use any number of buzzy labels to describe my skill set, and I'll cheer for Rust all day, but I'm just a programmer.

Re: Fun facts about Rust's growing popularity

#133

Earlier quoted context omitted.

To me, Swift feels very similar to Rust only a lot simpler. Arc is also (imho) a nicer solution than a GC (though people have different opinions on that). Even better, with future versions, some of the features of Rust (i.e. lifetimes) will also come to Swift in an opt-in way. It is still a young language but fun to code in.

What's coding in Swift like outside of being on macOS? Is the tooling decent on Ubuntu / *NIX or Windows?

It's really coming along now with Swift 4, but it is still (of course) behind the Apple platforms.

The "core language" pretty much works great on Ubuttnu, but there are still minor annoyances getting it installed, or building it, on Linux. Other Linux targets, also doable, but more annoying. Windows, I haven't really heard of people doing for real. Not sure that's even on anybody's radar.

What's really awesome is how far Swift has come with the core lib Foundation, which is a from-scratch clone of Apple's Objective-C and closed-source macOS/iOS Foundation library[1], written in Swift, in the open. It is not done, but huge swaths of it are now done[2], and that makes coding in Swift on Linux a lot more pleasant, since we don't typically want to waste time rolling our own regex support, Unicode string manipulations, basic geometry routines, HTTP networking, date formatting, etc. But Foundation is a huge, almost 30-year-old library that has evolved continuously and has shipped with every OS X/macOS/iOS release. An open-source Swift re-implementation of that sounded like "yeah right" bullshit/fantasy when they announced it but now it looks very real just a couple years later.

Tooling is different issue, though. Swift is a modern language with excellent support for auto-completion and in-editor hinting and help. People complain about it all the time, but Xcode is so much better than any IDE on Linux (or any other platform) for coding in Swift that I do most of my Swift-on-Linux work using a Mac, with Ubuttnu running in VMWare Fusion. If a basic editor will do, though, you have a lot of choices. For builds and package management, Swift Package Manager is now built into Swift, and works great. (It also has an option to automatically generate Xcode project files from Swift packages, which is hugely useful; my practice, and I think the prevailing or at least emerging convention, is to keep the package and source in git but treat the Xcode project as a throwaway item, not in version control, that can be generated whenever needed. So you don't need Xcode, but its easy to use for editing convenience when you want, assuming you have a Mac. But not all devs need to have Macs.)

I think you still have to like Swift a lot to choose it for your Linux project, but it is doable. I'd be surprised if Swift adoption on Linux didn't quintuple or sextuple by the end of 2018.

[1]: https://github.com/apple/swift-corelibs-foundation

[2]: https://github.com/apple/swift-corelibs-foundation/blob/mast...

Re: Fun facts about Rust's growing popularity

#134

Earlier quoted context omitted.

Nobody would have accused Brainfuck of being a good language but it turns out that its radical simplicity works well for integrating with optimization algorithms for creating self-programming AIs. It's all about a niche, except INTERCAL, you're right about INTERCAL.

Wait, what? I really want to see some links or papers about that. Care to share?

https://arxiv.org/abs/1709.05703 is the best one which is explained in these blog posts http://www.primaryobjects.com/2013/01/27/using-artificial-in...

Re: Fun facts about Rust's growing popularity

#135

Well, a fun fact: there is nothing funny about that list :). It should have been called "Some facts about Rust's growing popularity". Now, my predicament: I love Rust's type system and tooling, but it's really hard to justify to myself the pain of writing correct Rust code (borrowing, lifetimes, etc.) when I know I can get almost the same effect by using a GC language + immutable messages. And I don't need that last…

You're overlooking that Rusts "solution"(borrowing, livetimes, etc. ) is not only solving the same problem that garbage collection tries to solve. Garbage collection is "only" solving the "memory resource problem". Rusts solution is a more general solution to the "general resource problem" .. like file handles, sockets and of course memory and besides that gives you tools to never get bitten by data races. Nothing (b…

GC helps with file handles. Just give the "file" object a destructor that closes the underlying handle.

Re: Fun facts about Rust's growing popularity

#136
post #135

Earlier quoted context omitted.

You're overlooking that Rusts "solution"(borrowing, livetimes, etc. ) is not only solving the same problem that garbage collection tries to solve. Garbage collection is "only" solving the "memory resource problem". Rusts solution is a more general solution to the "general resource problem" .. like file handles, sockets and of course memory and besides that gives you tools to never get bitten by data races. Nothing (b…

GC helps with file handles. Just give the "file" object a destructor that closes the underlying handle.

... and, it will be eventually closed. Maybe. Definitely before the program quits. Not sure that it'll be closed before you run out of file handles, though.
Post reply on HN