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

141–150 of 305 posts

Re: Rust in 2018: easier to use

#141

Post by pjmlp »

foldr wrote: post #138
pjmlp wrote: post #131

Earlier quoted context omitted.

I do enterprise consulting, in projects which happen to always have some kind of offshoring involved. Projects where the languages are easy to pick up and anyone can do it, are always the first on the pipeline to give away.

Are you really saying that Rob Pike is part of some kind of conspiracy to offshore all the coding that's currently being done at Google SF? Golang has been around for a while now, and there's no sign of that happening.

No, I am just stating that the goals of having the language designed for such target audience, can have that as side effect.

Just like it happened with Java.

Re: Rust in 2018: easier to use

#142

Post by xfer »

yen223 wrote: post #22
grayrest wrote: post #17

Earlier quoted context omitted.

> Ocaml almost fits the bill, but the tooling around it is lacking to put it mildly. I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.

I've built several toy projects with ReasonML. I found the overall experience fairly positive, so please take this comment kindly. I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things. I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward reference…

No builtin utf-8 strings is a good/bad thing is debatable.

You don't need to use bucklescript toolchain to write Ocaml, it has a very good package manager, the build-system tooling is getting better, already has great editor support for many years now(merlin).

I think the tooling scene is much better than Haskell. Not sure what you mean by "no forward references"?

Re: Rust in 2018: easier to use

#143

Post by xfer »

z0ltan wrote: post #31
StreamBright wrote: post #11

Earlier quoted context omitted.

Depends what is your goal. Learning a language with decent type system? Learning a language with lower level access to operating system features? I would suggest to learn OCaml because it got really popular in 2017 thanks to Facebook & Bloomberg, it has an amazing type system and you can use it to build CLI tools and web pages (Reason/Bucklescript) with an insanely good tooling (utop, jbuilder, merlin) and the commun…

I have always been interested in OCaml, but I have a genuine question though - last when I looked at seriously at it, the standard library seemed to be a bit of a mess lacking a lot of features. A lot of modern resources seemed to focus on using Jane Street's Core(?) which I would not like to use - I'd rather depend on the standard language for standard features. Is this still a thing, or am I mistaken, or both? Plea…

You don't need Core, the shipped stdlib is good enough for toy projects. There are other stdlibs like containers and janestreet has split their stdlib into smaller pieces. What's your issue with having to use alternate stdlibs?

Regarding books, Real World Ocaml is very well written, although some examples might need tweaking.

Re: Rust in 2018: easier to use

#145

Post by xfer »

StreamBright wrote: post #126
pingiun wrote: post #19

Earlier quoted context omitted.

> It is new, it is shiny but lets wait its 10th birthday before it can be taken seriously and pls provide a decent async io / http library before we even get started what else can be done in Rust. Have you not looked at it for a while or don't you think tokio/hyper is good?

Hyper is not good enough Tokio is WIP.

You do realize hyper depends on the tokio/future framework?

Re: Rust in 2018: easier to use

#146

Post by Shoothe »

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

Thanks for mentioning the page. I'm about to write a simple JSON/HTTP service and decided to use Rust but I was wondering why the author would not use Rust for web services.

Re: Rust in 2018: easier to use

#147

Post by 534b44a »

ilammy wrote: post #102
tomsmeding wrote: post #96

Earlier quoted context omitted.

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

Eastern Slavic languages like Russian also give a similar vibe to this word ('shitter').

Какаю would the translated to "I poo" (hence Кака would be "poo"). Срач would be the stronger word in Russian [1].

[1] https://en.wiktionary.org/wiki/%D1%81%D1%80%D0%B0%D1%87

Re: Rust in 2018: easier to use

#149

Post by dullgiulio »

pjmlp wrote: post #141
foldr wrote: post #138

Earlier quoted context omitted.

Are you really saying that Rob Pike is part of some kind of conspiracy to offshore all the coding that's currently being done at Google SF? Golang has been around for a while now, and there's no sign of that happening.

No, I am just stating that the goals of having the language designed for such target audience, can have that as side effect. Just like it happened with Java.

It's pretty bad that people outside the SV can code /s

Re: Rust in 2018: easier to use

#150

Post by fhars »

yen223 wrote: post #22
grayrest wrote: post #17

Earlier quoted context omitted.

> Ocaml almost fits the bill, but the tooling around it is lacking to put it mildly. I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.

I've built several toy projects with ReasonML. I found the overall experience fairly positive, so please take this comment kindly. I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things. I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward reference…

There ist no ReasonML -> Ocaml compilation step in that chain, ReasonML is just another syntax for ocaml.
Post reply on HN