Hacker News Reader

Comment by reacharavindh | Hacker News Reader

It’s not useless. I for one associate language with their run time properties..

Written in Python - easy to understand, but lacks performance. Probably cant use more than 1 CPU core. Needs a lot of memory.

Written in Go - fast enough for most cases, all CPU cores, but possibly high mem usage becUse of GC. I need to plan for it.

Written in Rust - possibly new and maturing, uses memory effectively, likely to use all cores. Easy to deploy (single binary)

Written in JS - probably not for me - personal taste and hate of npm ecosystem.

Written in C - probably the best performing, but less robust, no memory safety.

So, “written in” helps in judging whether to care for that project or not to some extent.

View on HN

At least it's not Rust-this or that-4-Rust. The bundling of the language in the title of the app is a fad I hope I see the end of.

Yes, Python, we get that you wrote WhateverPy in Python.

This, for me, is due to lack of package namespacing in these languages. Someone took 'xyz' ? Well I guess I'm going to be 'xyz-rs'

Rust has its own -rs thing going on.

Mostly for bindings though.

Ah, that would make sense. I’ll have to take your word for it.

For me, I primarily think about stability:

Python/Go/JS/C -> runtime crashes due to type errors and/or data races

Rust -> no runtime crashes due to type errors/data races

Why would go and c which have static typing suffer from type errors ? Why would go that has a data race checker and quite good concurrency primitives be more prone that rust ?

Rust seems to have its merits but I find the parent post more level headed in that it tries to characterize language runtime, admittedly subjectively but not in a rust==good, rest==bad way.

You can easily cause a C/Go program to crash/abort due to runtime type errors. If you've written C, you've miscast something at some point. Go in particular relies extremely heavily on runtime reflection. Both languages have poor type systems.

Go's race detector is useful and we've caught bugs using it, but it's nicer when the compiler prevents you from having those bugs in the first place.

>quite good concurrency primitives

That's gonna be a "yikes" from me, dog: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s...

I'm not a Rust fanboy, I simply like languages where it's more difficult to represent invalid state (Haskell, Ocaml, Rust, etc.) than in the mainstream languages I suffer with in my job on a daily basis. Rust happens to have great tooling and is the most likely to make inroads on these issues I care about (runtime stability + code correctness via good type system).

Go doesn’t rely heavily on runtime reflection. Putting it in the same category as C or JS is disingenuous. Rust has a great static type system, but I’ve never seen a Go program fail on a runtime/reflection type error before.

I'm not sure what to say. Go code (stdlib, popular libraries, etc.) uses runtime reflection _everywhere_. I've been using Go since 1.2 and I've seen too many runtime crashes due to type errors to count.

It is used for things like printf and JSON marshaling. I’ve been using Go regularly since 2012 and this isn’t a real problem. The reflection in the standard lib and popular third party libs (and most unpopular third party libs for that matter) is rock solid. Moreover, reflection probably accounts for less than 1% of Go code—not sure where you’re getting “everywhere” from. So I guess I’m calling your bluff.

Even if your claim of "probably ... less than 1% of Go code" is accurate, appearing somewhat less often than 1 out of every 100 lines of code is _everywhere_ to me...

To be clear, I didn't say "less than 1 out of every 100 lines", but in any case I don't consider yours to be a reasonable definition of "everywhere". Especially since such a low frequency doesn't support your claim that "you see runtime type errors too many times to count". Perhaps you're using libraries that are far, far below the ecosystem's average quality?

Gosh, Rust evangelists did a really good job brainwashing the community. Take a look at big Rust projects that do anything useful, like Tokyo. You'll find dozens of unsafe blocks everywhere, so much for static analysis. True, in the most simple cases linear types will slap you on the wrist, but most bugs happen in the complex parts of code anyways.

I'm not part of the Rust "community" and don't participate in any of its fora, I just like a lot of the ideas it's pushing forward (see sibling comment). "unsafe" doesn't dIsAbLe AlL pRoTeCtIoNs like the anti-Rust crowd likes to say. I've written a few small (5,000+ LOC) programs in Rust over the last five years or so and I've only personally had to dip into unsafe once in my own code. I didn't claim that Rust prevents all bugs, I pointed out that Rust programs are more stable in the case of _runtime type errors and data races_ (which they are).

You're talking about a library that is forming the base of multithreaded applications. 99% of other libraries don't have nearly as much unsafe

where is Java in the list :D

Sorry, but by and large that's "red goes faster" type of reasoning.

Red is a property of a car totally unrelated to its performance characteristics. The language software is implemented in absolutely has an impact on the performance and behavior of the software.

This is more like "Carbon is faster than aluminum." Yeah, it's a generalization, but it's a useful one.

I don't know what you people get out of pretending you can't derive much from being told what language something is written in.

Reply on news.ycombinator.com