Earlier quoted context omitted.
I've also heard that Rust compilation is slow, so I put off learning it for a while. I finally dug in deep recently and, to be honest, I don't understand the issue. Rust compilation is quite fast in my experience. Your comment was the first I've heard of spotifyd, so I downloaded it from github and ran "cargo build". I spent 3 minutes figuring out that I needed to install the "libasound2-dev" package, then I spent le…
> Maybe you're referring to --release compilation? Indeed.
My favorite Rust function
111–120 of 197 posts
Re: My favorite Rust function
#112I haven't used rust, so can you explain this to me: If I do the rust equivalent of: def add1(x): return x + 1 x = 1 y = add1(x) z = add1(x) then will x have been deallocated by the first call to add1 and will the second call to add1 fail? [You can ignore the fact that I'm using numbers and substitute an object if that makes more sense in the context of allocating / deallocating memory in rust.]
It depends: if add1 borrows the value then this code is fine. If add1 takes ownership of the parameter then no, this will not work.
(I realize you, saagarjha, probably know this already -- this is more a note to other readers.)
Re: My favorite Rust function
#113Earlier quoted context omitted.
C was the only sensible choice back then. Uber on the other hand has many languages available yet picked Go. So they certainly don't think it is "unacceptably crippled".
There is an implicit "for my use-case" following "unacceptably crippled". So, go is not "unacceptably crippled" for the use case of creating a ton of small, simple, easily maintainable services at Uber, but it might be "unacceptably crippled" for the use case of having fun with type systems, or whatever the author was interested in at the time they were considering go as an option.
Even the most charitable interpretation would conclude it's speaking in broad terms and not just "for my use case".
Full paragraph:
> 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.
Re: My favorite Rust function
#114Earlier quoted context omitted.
Sure, and my opinion is that this is a very shallow takeaway. My whole comment is just my opinion.
It is crippled admittedly by the authors themselves. The error checking pattern, no generics etc. are all to keep it "simple" yet are things most other programming languages have. Have you used Rust ? The borrow checker makes a lot of sense.
Re: My favorite Rust function
#115> 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.
Go is crippled. I know you disagree, but I can tell you why you disagree and why you are wrong. Simply put, you do not have enough knowledge to know why GO is crippled. Allow me to elucidate.. Imagine that you never knew about the concept of a negative number. You only knew about natural numbers. And for 5 years that's all you worked with... positive numbers. This does not mean you are inn-effective working with your…
type myEnum int
const (
someValue myEnum = iota
anotherValue
moreValues
)
> Sum typesConsider thinking about the types in your sum type and what they have in common, and define an interface that they share.
> Recursive types
Not sure what you mean. This is valid Go:
type tree struct {
value int
left *tree
right *tree
}
> Parametric polymorphismYes Go sucks in this area. `sort.Interface` is a good example of a workaround, but it isn’t ideal in any way.
> There is no this in GOLANG:
Is this not acceptable?
var x interface{}
json.Unmarshal([]byte(“[1,2,3]”), &x)
And if you don’t like that you get back a `[]interface{}` that happens to hold `int`s that you must type assert, just do it the better way: var x []int
json.Unmarshal([]byte(“[1,2,3]”), &x)Re: My favorite Rust function
#116Gotta 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?
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).
Re: My favorite Rust function
#117Gotta 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:…
Re: My favorite Rust function
#118Earlier 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.
Or maybe they have just expanded their "knowledge spectrum" and are experiencing an effusive moment?
Re: My favorite Rust function
#119Earlier 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 often see Go functions with a large number of lines- many of which are noisy boilerplate error handling. Combine that with terse variable names, type inference and it's straight up tiresome to filter out the important parts. These functions aren't even doing all that much.
There is a healthy middle-ground between excessive abstraction a la Enterprise Java and what Go offers.
Re: My favorite Rust function
#120Earlier quoted context omitted.
Go is crippled. I know you disagree, but I can tell you why you disagree and why you are wrong. Simply put, you do not have enough knowledge to know why GO is crippled. Allow me to elucidate.. Imagine that you never knew about the concept of a negative number. You only knew about natural numbers. And for 5 years that's all you worked with... positive numbers. This does not mean you are inn-effective working with your…
> Enumerations type myEnum int const ( someValue myEnum = iota anotherValue moreValues ) > Sum types Consider thinking about the types in your sum type and what they have in common, and define an interface that they share. > Recursive types Not sure what you mean. This is valid Go: type tree struct { value int left *tree right *tree } > Parametric polymorphism Yes Go sucks in this area. `sort.Interface` is a good exa…
- those are integers not enumerations. In Golang they have a type Bool which is either true or false. Can I define my own type using the same convention in GoLang? No. I can't. Ideally I want the ability to do this:
type Bool = Enum {
True
False
}
or type Tri = Enum {
True
False
QuantumTrueFalseDuality
}
But in Golang I'm locked in with what the creators provided as primitive types. I can't go deeper. Rust you can.> Sum types.
I don't think you know what a sum type is. This is what I mean by lack of knowledge. For sum type (A | B), A and B do not need to have a single thing in common and they do not need to share an interface. Think of a product type (A, B) as A and B and a sum type (A | B) as A or B.
The most glaring replacement of sum types in go are done with product types that contain errors from IO functions in GoLang. The Error type does not have anything in common with the Value it usually shadows and therefore both cannot be represented with an interface.
> Recursive types.
That's somewhat recursive. But that's a pointer. This works and is valid. Ideally though it shouldn't be a pointer but for efficiency during memory allocation this is a viable restriction. Recursive types only with pointer types.
> Parametric Polymorphism
I agree with you.
> Is this not acceptable?
No it is not acceptable. Interface is unusable until you make the type concrete with your asserts. Asserts are you executing a guess on a possible JSON permutation. In your second example you are guessing the type to be an array of INTs. What if that string was arriving over the wire as IO and you don't know what configuration it will be in? What if the typing was more complicated?
jsonString = "[1,2,True,[1,2,\"hello\"]]"
or jsonString = randomJSONFromIO()
The assert also leaves an opening for a runtime error which is unacceptable.imagine syntax like this:
type JSON :: []JSON | Struct{string: JSON} | bool | int | string | null
var x JSON = json.Unmarshal("[[1,2,True,[1,2,\"hello\"]],{}, null]")
JSON is a type represented using sums (|), products (Struct) and recursion (JSON). There is no possibility of run time errors here as you don't need to guess a specific permutation of JSON. You don't need to guess because such a type system can fully represent JSON. You see what is missing with go?