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

Rust – A hard decision pays off

pinecone.io

Post reply on HN
Print view View original

131–140 of 386 posts

Re: Rust – A hard decision pays off

#131

Post by throwaway894345 »

golergka wrote: post #84
throwaway894345 wrote: post #75

Earlier quoted context omitted.

I sort of agree, but I also think type systems are somewhat overrated compared to performance, static compilation, native compilation, easy cross compilation, good tooling, expansive ecosystem (esp devoid of C dependencies). I think TS and Go are on par with respect to tooling and ecosystem, but I would rarely trade Go's static, native compilation model (distributing a single static binary is pretty awesome) for some…

> distributing a single static binary is pretty awesome It is, but does it really matter when you write backend? I've written and operated Node-based backends at scale, and I can't honestly remember any bugs or outages that would have been prevented by this. At the other hand, there's a lot of potential bugs and problems that didn't happen because proper usage of TS's type system prevented me from committing them.

I'm not claiming a single static binary is going to prevent bugs or outages. It's just a surprisingly nice property (though less-so on the backend). For example, because Go distributes as a single static binary, we can make scratch images that weigh in at only a couple of megabytes. This (alongside fast compilation) means we can iterate more quickly in the cloud (pulling images onto nodes and starting them is almost instantaneous). This is particularly helpful when you have an outage and you're trying to get things un-stuck (you can try a lot of things in a short amount of time). It's one of those things that aren't obviously valuable until you've tried it.

Again, it's not the end-all-be-all, but it's a surprisingly nice property.

Re: Rust – A hard decision pays off

#132

Post by zmix »

throwaway894345 wrote: post #41

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling.

Why not D?

Re: Rust – A hard decision pays off

#133

Post by nazka »

golergka wrote: post #82
nazka wrote: post #70

Earlier quoted context omitted.

Talking about Haskell and stuff. You what I want? Rescript to replace entirely Typescript. That will be so much better.

Personally, I love ML-family languages and would enjoy writing in Rescript more, indeed. But I write software not to enjoy the process, but to solve business needs. And using Rescript, Scheme or Haskell drastically limits the talent pool and rises the cost. Which, BTW, can be very good for some businesses, that would want to hire only the best programmers anyway and are ready to pay for it. But that's some, not all.

Yes I agree. Also if you know your business won't need a lot of dev, like stuff like Instagram where I think they were still at 60 engineers even after hitting 1B active users, it can also be a good thing to use a niche (but viable) language to attract some bright engineers and they will be thrilled to be able to have a job to use it. Now I don't have such startup (yet) so I can't do it :)

I just wish ReScript would have gained traction and replaced Typescript. But who knows maybe it can still happen.

Re: Rust – A hard decision pays off

#134

Post by rob74 »

AtNightWeCode wrote: post #83
throwaway894345 wrote: post #41

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

Docker is built with Go. Compare doing things with Docker api between Go and Python. I usually recommend people to "script" things with Go but I start to think that Go has to go... https://docs.docker.com/engine/api/sdk/examples/

I would say in this case it's more the API designers' fault than Go's fault. Looks like the Python API is operating at a higher abstraction level than the Go API - using the Python API you can just call a "macro" that does everything required, in Go you have to call each operation individually.

Re: Rust – A hard decision pays off

#135

Post by tinco »

t6jvcereio wrote: post #113
drexlspivey wrote: post #109

Earlier quoted context omitted.

How hard can it be for C/C++ devs to learn Rust? Python devs on the other hand..

That's not the point. If no one knows the language, no one knows if it's appropriate. All you know is the language marketing claims

Even though it's software engineering, which supposedly isn't really engineering, you can still apply engineering principles. Disregarding all the bullshit debates about whether Rust is better than Go, there are actually differences between the languages that you can objectively research.

Maybe no one in that specific company really knew the language, but there's loads of people actually using the language, it's not like it dropped from the clear blue sky. It's not like there's a Rust salesperson that knocked on their door with a leaflet. They're not even the first persons to write a database engine in Rust.

I wonder if other engineering domains have this same silliness. Do the architects have intense debates over steel H beams vs wooden LVL beams, and at some point newbie architects believe you should only switch from one to the other as an architecture firm if your architects have experience with it, because the only way to know if it would work is reading the marketing claims.

A compiler is just a tool. If you're doing a rewrite you better pick your tools correctly, and it seems like they did. You could theorise they were lucky somehow, or you could recognise that they're experienced, educated and skilled and made the right choice based on their researched.

Re: Rust – A hard decision pays off

#136

Post by coder543 »

reitanqild wrote: post #119
danwee wrote: post #114

Earlier quoted context omitted.

Wow. That's quite something. I like Go, but more often than not I keep stumbling upong these kind of situations (N LOC to do something in Y, 10xN to do it in Go).

In addition to a emulating certain teachers dogged insistence of making sure students can't have nice things (an absolute no-brainer feature like generics only showed up recently...!), last time I tried to use Go for a web project a few years ago I was also amused by the lack of templating libraries - the way to make pages was to string together header + main + footer, the old PHP way...! Not a single library support…

Umm... what are you even talking about?

Go has had templating built into the standard library since... forever?

And Go templates can use other templates, as long as they're all loaded into the same context, if that's what you were getting at.

simple examples of Go's built-in templates: https://gowebexamples.com/templates/

templates using other templates: https://levelup.gitconnected.com/using-go-templates-for-effe...

Re: Rust – A hard decision pays off

#137

Post by nazka »

t6jvcereio wrote: post #113
drexlspivey wrote: post #109

Earlier quoted context omitted.

How hard can it be for C/C++ devs to learn Rust? Python devs on the other hand..

That's not the point. If no one knows the language, no one knows if it's appropriate. All you know is the language marketing claims

I think at this point Rust has more than marketing points. Then if you have some bright people, and I mean doing what they are trying to do and feeling that RockDB is a slow database... They should be able to pick it up. I don't think it's an unreasonable decision as a CTO/CEO.

Re: Rust – A hard decision pays off

#138

Post by throwaway894345 »

SoftTalker wrote: post #123
throwaway894345 wrote: post #120

Earlier quoted context omitted.

I actually don't care as much for iterators as I thought I would. Beyond some simpler map().reduce() stuff they tend to fall over pretty fast, and I end up spending too much time trying to make iterator chains work before defaulting to for loops. I also dislike how anemic Rust's stdlib is. I'm sure there are good reasons, but I like that I can just reach for Go's stdlib for annotating errors or dealing with JSON. Oth…

I guess that's subjective, not knowing rust I see a few more lines in the first example but beyond that it does not jump out at me as being "way more complex."

Hah, it took me and a bunch of other people in the Rust discord a fair amount of time to figure out how to get the first example to compile correctly in the first place, and I find the “transpose()” business to be particularly convoluted. I think even Rust people would prefer the imperative version. I also suspect there’s some hindsight benefit at play in that it’s easier to make sense of the first snippet than it was to write it.

Re: Rust – A hard decision pays off

#139

Post by t6jvcereio »

tinco wrote: post #135
t6jvcereio wrote: post #113

Earlier quoted context omitted.

That's not the point. If no one knows the language, no one knows if it's appropriate. All you know is the language marketing claims

Even though it's software engineering, which supposedly isn't really engineering, you can still apply engineering principles. Disregarding all the bullshit debates about whether Rust is better than Go, there are actually differences between the languages that you can objectively research. Maybe no one in that specific company really knew the language, but there's loads of people actually using the language, it's not…

> Do the architects have intense debates over steel H beams vs wooden LVL beams, and at some point newbie architects believe you should only switch from one to the other as an architecture firm if your architects have experience with it, because the only way to know if it would work is reading the marketing claims.

That is one way to put it, which is convenient for the point you're making. A different way, more convenient for the point I'm making is that if you're budding roads and you need a bridge, you probably wouldn't hire a firm that only has experience building tunnels.

So you see, your analogy is meaningless, because making an analogy is not a convincing way of making a point. Anyone can make an analogy.

My argument on the other hand that experience is a very important factor, is a lot more convincing because anyone who has any kind of professional career already agreed with it.

Re: Rust – A hard decision pays off

#140

Post by mannykannot »

meragrin_ wrote: post #104
bluejekyll wrote: post #22

Earlier quoted context omitted.

I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. Rust fit the need they had pretty well (on paper anyway since they didn’t have experience with it), and the industry is showing it to be a good choice for solving these types of problems. That’s not rolling the dice, it’s taking a chance based on research.

> I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. I think hoping a Rust rewrite would fix "complex runtime issues which were almost impossible to reproduce or isolate" as rolling the dice. If you cannot reproduce or isolate an issue, how can you know a rewrite in another language will fix the issue?

"Almost impossible" is not quite "impossible", and once you have done the almost impossible a few times and isolated the cause of some of the problems, you may have gained some apprehension of the scale of the overall problem you are facing.
Post reply on HN