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

Programming languages endorsed for server-side use at Meta

engineering.fb.com

Post reply on HN
Print view View original

261–270 of 302 posts

Re: Programming languages endorsed for server-side use at Meta

#261

Post by al_mandi »

vonseel wrote: post #109

I’m surprised they said Rust is their new language of choice for CLI tools. I’m no expert but always saw Go as the better choice for CLI tooling where performance is important, Rust more of a low level language for highly performant libraries and tools, and Python a good choice for scripting or plumbing that needs to work and be easily maintainable, without special performance concerns (Python is my primary language,…

A good read about why golang does badly: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Re: Programming languages endorsed for server-side use at Meta

#262

Post by burntsushi »

metaltyphoon wrote: post #256
burntsushi wrote: post #232

Earlier quoted context omitted.

Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?

If I would have to guess it would be codecs.

What do codecs have to do with grep?

Re: Programming languages endorsed for server-side use at Meta

#263

Post by dom96 »

vaylian wrote: post #145
dom96 wrote: post #51

What's always been interesting about the languages Meta uses is the story of the rise and fall of the D programming language at Meta. I wasn't around at the time when Andrei was working there and advocating for its adoption, but it seemed like he hit a wall at some point. By the time I joined all D services were being deprecated or rewritten. Rust seems to be doing far better. Though it's also worth noting that Go ne…

Interesting to hear this from a Nim developer. Do you think Nim would be a good fit for what facebook needs? (Normally I don't check author's names in hacker news comments. But I wanted to check if this is WalterBright posting here)

Yep, I also just left Meta/Facebook after 4 years working there. I did spend some of my time trying to see where Nim could fit (together with a few other folks that liked Nim at FB), the best area we could come up with was CLI tools that interfaced with many internal C++ libraries. Nim would be a great replacement for Python here (it's fast and typed) and its ability to compile to C++ makes interfacing with C++ super simple (at least in theory).

It is true that Nim has the same problem as D to a certain extent: the ecosystem is limited and the benefit it brings over C++ just doesn't overcome that. A great example of this is why I said "in theory" above, in practice interfacing with C++ in Nim just hasn't been done enough to be mature. Multiple teams in a FAANG aren't going to take a risk adopting that.

Re: Programming languages endorsed for server-side use at Meta

#264

Post by int_19h »

burntsushi wrote: post #262
metaltyphoon wrote: post #256

Earlier quoted context omitted.

If I would have to guess it would be codecs.

What do codecs have to do with grep?

grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv).

However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.

Re: Programming languages endorsed for server-side use at Meta

#265

Post by burntsushi »

int_19h wrote: post #264
burntsushi wrote: post #262

Earlier quoted context omitted.

What do codecs have to do with grep?

grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv). However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.

Those are locales. I've never heard them referred to as "codecs."

In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)

Re: Programming languages endorsed for server-side use at Meta

#266

Post by xxs »

burntsushi wrote: post #232
xxs wrote: post #202

Earlier quoted context omitted.

grep inner loops are coded straight in Assembly. So Rust would be a poor fit.

Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?

ugrep has full SSE/AVX support

https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8c...

Re: Programming languages endorsed for server-side use at Meta

#267

Post by xxs »

int_19h wrote: post #264
burntsushi wrote: post #262

Earlier quoted context omitted.

What do codecs have to do with grep?

grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv). However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.

>in the kernel that gets executed due to some syscall from grep

That won't be considered 'inner loop'

Re: Programming languages endorsed for server-side use at Meta

#268

Post by int_19h »

burntsushi wrote: post #265
int_19h wrote: post #264

Earlier quoted context omitted.

grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv). However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.

Those are locales. I've never heard them referred to as "codecs." In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)

"en_US.UTF-8" is a locale. The "UTF-8" part is the encoding of that locale. Codec would be whatever piece of code parses the encoding.

Re: Programming languages endorsed for server-side use at Meta

#269

Post by 10x-dev »

nicolashahn wrote: post #225
10x-dev wrote: post #191

Earlier quoted context omitted.

I think its killer feature is the memory safety guarantees, but other than that, I just don't find it as readable as other modern languages, mainly because it's symbol heavy.

Fair, but like any language this becomes a non-issue given enough time with it.

I've never liked the "you'll get used to it" approach to life.

I prefer to make my life harder by pursuing the perfect solution. It has bitten me in the behind multiple times in the past :)

Re: Programming languages endorsed for server-side use at Meta

#270

Post by boppo1 »

kortex wrote: post #194
gary17the wrote: post #61

Earlier quoted context omitted.

> I’ve been holding off learning Rust. Rust is quite an easy language to learn and a pleasurable language to use, due to its modern ergonomics and internal consistency. Give it a try. The only trick is that Rust newcomers actually need to read up on Rust borrow checker and lifetime annotations first, as opposed to learning Rust only through hacking with it. Those two concepts are unique to Rust and need to be well un…

> Rust is quite an easy language to learn It's funny. I hear two different things, all the time. "Rust is easy to learn" and "Rust has a steep learning curve". Personally, I found it to be the latter, and that's as a serial dabbler/language polyglot. I had a bear of a time wrapping my head around lifetime annotations, and needed someone already familiar with them to sherpa me through that stage. I think it does a dis…

What makes C++ so hard to learn?
Post reply on HN