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

My favorite Rust function

blog.jabid.in

Post reply on HN
Print view View original

151–160 of 197 posts

Re: My favorite Rust function

#151

Post by likeliv »

steveklabnik wrote: post #80
Rusky wrote: post #41

Earlier quoted context omitted.

NLL does not change those semantics; drop still runs at the end of the scope. It counts as a "use" for the purposes of NLL and thus keeps values with destructors alive.

For some history, it was talked about changing this, but we couldn’t, due to back compatibility and it wasn’t clear it was actually a good idea. This was called “wary drop”.

Would be nice if types could annotate their Drop trait with #[early_drop] if the drop has no visible side effect, do rust could free the memory earlier.

Re: My favorite Rust function

#152

Post by qznc »

flywithdolp wrote: post #150

can someone elaborate on this passage: The beauty of programming language design is not building the most complex edifice like Scala or making the language unacceptably crippled like Go - but giving the programmer the ability to represent complex ideas elegantly and safely. Rust really shines in that regard. i'm fairly ignorant on the various differences but my general feeling was that Go is quite useful?

The usual quip because Go has no Templates/Generics, so you have to sacrifice type safety all the time by casting to and from Interface{}.

Re: My favorite Rust function

#153

Post by saturn_vk »

baby wrote: post #97
jchw wrote: post #22

> or making the language unacceptably crippled like Go Gotta say, I lost a lot of respect for the author at this point. It’s not like I don’t love Rust - quite the contrary - but if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight. Go has been one of my languages of choice for over half a decade now, and for good reason.

I work with Rust only these days, it’s really an awesome language and I wish everyone working with system languages would switch to Rust. Yet, I find Golang to be a much clearer language to read (and I read a shit ton of code). I hope they don’t add generics, but I wish they would options, results, sum types in general, redeclaring variables, the ? Operator, etc.

I doubt that any genetic syntax will significantly impact go readability. The only syntax overhead will be in type definitions, not in type usage, and the later is present a lot more than the former. Couple that with the current need to add extra type assertion on type usage, and you may be looking at overall readability improvement

Re: My favorite Rust function

#154

Post by erik_seaberg »

ErotemeObelus wrote: post #126
AdieuToLogic wrote: post #106

Earlier quoted context omitted.

> > or making the language unacceptably crippled like Go > ... if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight. Perhaps the author used a poor choice of words and instead could have phrased their intent along the lines of: Go lacks the semantic density needed to express solutions in both a concise and consistent manner. Were this the case, it wou…

I think it's a syntax problem. ASCII doesn't have enough bracket characters to simply & clearly represent necessary language features. So it's harder for an intelligent human to sort and categorize these aspects. Pre-generics Java is about the appropriate amount of language complexity for our current lingua franca

Java is tolerably mediocre now but vintage 1996 Java was awful (and slow). I enjoy Scala, but even I can see why it's more than most of the industry is ready for. If there's a sweet spot, Kotlin seems close to it.

Re: My favorite Rust function

#155

Post by likeliv »

flywithdolp wrote: post #150

can someone elaborate on this passage: The beauty of programming language design is not building the most complex edifice like Scala or making the language unacceptably crippled like Go - but giving the programmer the ability to represent complex ideas elegantly and safely. Rust really shines in that regard. i'm fairly ignorant on the various differences but my general feeling was that Go is quite useful?

One of the philosophies behind Go is to keep the language extra simple.

See "less is exponentially more".

The same way some electric bikes are restricted to a given speed to keep their user safe. Some people call it "crippled", while some other call it "simple and safe to use".

Re: My favorite Rust function

#156

Post by tsimionescu »

baby wrote: post #116
c3534l wrote: post #92

Earlier quoted context omitted.

Go is simple to the point where it annoys a lot of programmers, especially programmers who like to do fancy stuff with their programming language (the kind of person that's attracted to Rust, for instance).

I’m mostly working with Rust, and I really like it, and I can even understand why WRITING Golang can be frustrating at times, but it should be clear to everyone that Golang is the best language to READ.

I completely disagree, coming from a Java and C# background.

There are nice aspects to reading Go, but any function which does some kind of error-prone operation is so hard to grok, it gets tiring - the actual purpose is constantly interrupted by 'if err := nil' so much.

And gods help you if there is some actual non-trivial error handling going on, as you've generally learned to gloss over and can easily miss that one place that actually does something with an error other than log and return.

Also, while admittedly rare, trying to review code that needs to copy structs around, if they also involve pointers or slices, is just hell.

Re: My favorite Rust function

#157

Post by tsimionescu »

hu3 wrote: post #55
gautamcgoel wrote: post #17

Gotta admit, that really is a cute example. However, I was a bit surprised when the author described Go as "unacceptably crippled." What is he referring to?

Interesting how developer views can differ. Someone describes Go as "unacceptably crippled" while Uber engineering has 1500 microservices written in Go, making it their primary language. https://news.ycombinator.com/item?id=21226347

I can speak as someone who is building a microservice application in Go and was actually part of the decision to use Go, rather than Java or C# which we traditionally used.

I also find Go-the-language unacceptably crippled. Unfortunately, Go-the-runtime is the only best runtime for microservice-based applications, if you want a GC, especially if you want to run the system on limited hardware.

All the other options are either too bloated to comfortably spawn in large numbers (Java, C#, Node, Python, Ruby take too long to start, use too much RAM , and/or give you too large containers), or are too new and unproven (Nim).

So, we chose to use the inferior language and line with a small hit to productivity (language choice has little impact on productivity after the learning stage anyway) for the superior runtime system.

Re: My favorite Rust function

#158

Post by vertex-four »

root_axis wrote: post #82
viraptor wrote: post #47

Earlier quoted context omitted.

It may be an unnecessary dig, but the author may indeed be familiar with Go and still think it's unacceptably crippled for all their use cases. The whole post is just their opinion.

In my anecdotal experience, the type of programmers that evangelize and talk shit about programming languages tend to be on the less informed side of the knowledge spectrum.

I occasionally program Go because it has an amazing amount of libraries - I basically use it for random microservice type things that glue systems together. (Most recently, an HTTP login endpoint that sends and receives XMPP messages to authenticate the user.)

I don't like it. I program Rust the rest of the time. I'm considering learning Perl5 so that at least my type system lets me do vaguely expressive things - I'm utterly fed up of half my code looking like:

    foo, err := something()
    if err != nil {
        return nil, someErr{err}
    }
I got very used to Rust's try!() macro, now ? operator, and being able to map over Results to convert between error types in a single line that feels much less noisy - I have functions in Go that are a dozen or so lines that would've been 3 in Rust, and tbh I struggle to follow what the function actually does when 3 out of 4 lines are to do with the failure case.

I would consider "unacceptably crippled" to be a reasonable description of Go, even if it's the best tool I have for some jobs.

Re: My favorite Rust function

#159

Post by tsimionescu »

TheDong wrote: post #46
gautamcgoel wrote: post #17

Gotta admit, that really is a cute example. However, I was a bit surprised when the author described Go as "unacceptably crippled." What is he referring to?

The usual suspects for things missing from go are the following: Generics, sum types, match statements, tuple types, compile-time data-race detection, type-safe concurrent-maps, hygienic macros, immutable types/references, functional constructs such as 'map', 'filter', or monads, marker interfaces, better error handling, type-inference for consts that isn't garbage, etc. Less common complaints are that it's missing:…

From the first list, adding generics would essentially automatically also give you type-safe concurrent maps and map/filter/zip/etc.

Re: My favorite Rust function

#160

Post by erk__ »

foopdoopfoop wrote: post #21

Reminds me of Coq's definition of `False`: `Inductive False := .` i.e., `False` has no constructors and hence is an empty type. Anyway, this means that for any type `A`, you can construct a function of type `False -> A` because you just do this: `fun (x : False) => match x with end.` Since `False` has no constructors, a match statement on a value of type `False` has no cases to match on, and you're done. (Coq's type…

That is made that way to mirror how logic usually is made to work in propositional logic.
Post reply on HN