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

Rust in 2018: easier to use

jvns.ca

Post reply on HN
Print view View original

261–270 of 305 posts

Re: Rust in 2018: easier to use

#261

Post by nicoburns »

curiousGambler wrote: post #39
eecc wrote: post #24

Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018. http://www.arewewebyet.org Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position

I get the impression Go runs the microservice space. It's built for it and is incredibly fast despite the GC. I don't see Rust claiming that position anytime soon.

Rust's USP over Go isn't more speed, it's better abstraction, and better correctness. Go is definitely a good tool for microservices, and it isnt going anywhere. But writing Rust is a joy, and I wouldnt be at all surprised if it also carves itself a niche in this area.

Re: Rust in 2018: easier to use

#262

Post by steveklabnik »

quotemstr wrote: post #246
steveklabnik wrote: post #225

Earlier quoted context omitted.

Many do, yes. Panics are non-recoverable errors, and aborting produces leaner code, which is important on embedded.

Panics are recoverable though

They’re not guaranteed to be, so you can’t rely on it. You can say that you do, but then you may cut yourself off from the rest of the ecosystem. Libraries generally can’t rely on either behavior, applications choose.

Re: Rust in 2018: easier to use

#263

Post by Dowwie »

timClicks wrote: post #47
nafizh wrote: post #3

Anyone has suggestions on learning rust for a python programmer who is also not strong on systems concepts?

Hopefully I am not overstepping bounds by mentioning my book, but I encourage you to take a look at Rust in Action by Manning. It's written for current programmers who want to learn Rust as well as enough of the systems programming concepts that seem to sneak into Rust docs and discussion.

I appreciate your hard work and sacrifice.

Really looking forward to learning from your material, when it's ready.

Re: Rust in 2018: easier to use

#264

Post by chmln »

pjmlp wrote: post #173
chmln wrote: post #158

Earlier quoted context omitted.

> Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity There is nothing in Rust that makes it inherently unfit for APIs or the web. To dismiss the entire language is simply lazy. Having GC also doesn't necessarily make one language superior to another. While http ecosystem is still in active development, if there was really a choice between Rust and JS for e.g. writin…

The thing is, the choice isn't between Rust and JavaScript, rather between Rust and a list of other languages. Having a GC means having easier ergonomics to write data structures and distributed algorithms. I do like a lot Rust's type system, just the ergonimcs aren't quite there yet.

> just the ergonimcs aren't quite there yet

You're correct, but "Rust isn't easy to use for purpose X just yet" is substantially different from "Rust is inherently unfit for X"

Re: Rust in 2018: easier to use

#265

Post by lieuwex »

elygre wrote: post #105
tomsmeding wrote: post #96

Earlier quoted context omitted.

Their choice of executable name is slightly unfortunate in Dutch, where 'kak' basically means 'shit'.

I think “kak” would be better translated as “poo”. Parents will routinely talk to their kids about “kak”, similar to the way US parents will use the word “poo”. The word “shit” generally has a much stronger meaning (and is therefore often obscured, as “s..t” or something similar.

I think "kak" still would be translated better as "shit", you wouldn't curse with "POO!". But in Dutch you can curse with "KAK!", just as 'SH*T!' in English.

Re: Rust in 2018: easier to use

#266

Post by Dowwie »

StreamBright wrote: post #10

Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…

Looks like we found the javatarian!

I had to look up on Wikipedia when Rust was conceived: 2010. It took me another moment to realize that it's already been 8 years.

We should be flying in spaceships programmed with Rust by now. This is ridiculous.

Re: Rust in 2018: easier to use

#267

Post by e12e »

phillipcarter wrote: post #254
marmaduke wrote: post #241

Earlier quoted context omitted.

I wanted to get into f# but had a hard time with tooling, cross platform. For example, I'd see a great library and the instructions assume VS while I'm on Linux. There are a variety of build tools and package managers. As Python dev since 10 years I can't point fingers -- Python is probably worse though I've memorized the idiosyncrasies -- but I couldn't justify my way up the tooling learning curve in addition to the…

(I work on F# at MS) Do you remember the library? The landscape has changed dramatically in the past ~6 months with .NET Core 2.0 support. For example, I can use Fable[0] and Giraffe[1] with the .NET CLI[2] to build full-stack F# apps on my machine which runs .NET Core. The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support…

> The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support, but we're quite close to finishing that.

Is there a viable cross platform ui option for f# on core?

Re: Rust in 2018: easier to use

#268

Post by e12e »

stevedonovan wrote: post #67
hateduser2 wrote: post #30

Earlier quoted context omitted.

I like the idea but Rust has so many issues in front of it I’m not sure it has the energy to invest in something like hay.

Yes, the compiler is a permanent construction zone and there can only be so many projects on site, let alone workers. So this feels like something that _should_ be doable outside the compiler, but using its metadata. (BTW, "rustc --explain does at least give you some nice text)

Sounds like having --why output --explain for each error might be the 80% fix?

Re: Rust in 2018: easier to use

#269

Post by e12e »

shadowmint wrote: post #46
banachtarski wrote: post #29

Earlier quoted context omitted.

> Nobody with a sane mind would write C or CPP micro-services why? I do this all the time. Maybe I should check into a nearby asylum.

The point isn’t that no one does it, its that its hard to do right. ...and that is flat out the case for c++, unequivocally. In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at. Rust isn’t the right so…

> ...and that is flat out the case for c++, unequivocally.

Arguably, this is why Google made go.

But I'm not sure c++ micro services are a terrible idea. I think the real problems come with a) feature creep as opposed to writing new micro services, and b) the temptation to write "fast" c++.

Just writing plain obvious c++ should give you a leg up on most languages (esp for micro services). But then, rather than refactor and think about the algorithm and data structures (and get a 10x performance benefit from a simpler solution), you could probably get a 2x improvement from a more convoluted, "special" c++ implementation.

And that's where you're likely to encounter elder horrors lurking.

[ed: I'm however more and more convinced there's no such thing as "plain obvious c" that doesn't have a number of serious issues along the lines of not checking mallloc return values, to utf8 string handling etc.]

Re: Rust in 2018: easier to use

#270

Post by phillipcarter »

e12e wrote: post #267
phillipcarter wrote: post #254

Earlier quoted context omitted.

(I work on F# at MS) Do you remember the library? The landscape has changed dramatically in the past ~6 months with .NET Core 2.0 support. For example, I can use Fable[0] and Giraffe[1] with the .NET CLI[2] to build full-stack F# apps on my machine which runs .NET Core. The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support…

> The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support, but we're quite close to finishing that. Is there a viable cross platform ui option for f# on core?

Yup! Fable. In fact, a web app written in fable will even run in more places than a .NET Core app due to the reach of browsers.
Post reply on HN