Why is Rust difficult? • Hacker News Board

Re: Why is Rust difficult?

#181

Post by steveklabnik » Mon, Jan 22, 2018, 3:39 PM UTC

unethical_ban wrote: post #175

josephg wrote: post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I write somewhat simple programs and webapps for my job, from time to time. I use Python and its standard library, some modules, and the Bottle Framework. Pulling data from APIs, doing analysis, taking some user input, editing configs, etc. I hardly ever use classes unless I'm extending a vendor library. I have never used generics. Why are generics such a critical component of a programming language that every thread…

Here's a framing I found useful: as a user of a library, you may not particularly use generics. But as an implementor of a library, on the other hand, they're extremely useful.

However, comparing to Python won't make much sense; people see generics as essential to statically typed langauges. You don't need them for dynamically typed ones!

Re: Why is Rust difficult?

#182

Post by zeugmasyllepsis » Mon, Jan 22, 2018, 3:40 PM UTC

gkya wrote: post #165

josephg wrote: post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I haven't used Go all that much, but arent the interfaces meant to be used as generics, i.e. in your function you need some data X, and you'll do something with that X. The way you need to achieve this is that expect an X that satisifes a given interface, say Exampler. If a particular X does not support it, you write the method(s) on X's type to satisfy the Exampler interface. IIRC Pike said somewhere that you don't…

There is certainly some overlap between those features, but I think they largely cover different usecases.

For example, consider trying to implement a List data structure in Go. What type does the List hold? It poses no constraints on the type of things put in it, except that they must all share that type.

The List can store `interface{}`, but then there's nothing to stop you from adding two different types to the list. And what type of value would a method like `getFirstItem()` return? Just an `interface{}`, forcing the user to cast.

Go's interfaces express constraints on individual types (e.g. type A has methods Foo and Bar) but not across functions defined on a struct (e.g. the type that a List stores is the SAME type that the getHead() function returns).

Re: Why is Rust difficult?

#183

Post by currymj » Mon, Jan 22, 2018, 3:40 PM UTC

sillysaurus3 wrote: post #14

Is there a way to avoid the true-believer syndrome for Rust? I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z. Every tool has its flaws, but for whatever reason it seems extremely rare to discuss…

there is a culty vibe.

if i had to speculate why, it's that a lot of the more zealous Rust programmers simply have never had the skills or wherewithal to write in a systems programming language before. (I'd count myself in this category. I knew how to write half-assed scientific C++ but that's it.)

it's pretty intoxicating to finally be able to write code without a garbage collector and not screw it up, and be able to use a modern package manager at the same time to get all kinds of nice dependencies.

and getting over the borrow checker hump actually is one of those mind-expanding things like learning Lisp or Haskell is supposed to be. when I have to write C or C++ code now I have a little borrow checker living in my head helping me avoid mistakes.

these are very exciting experiences and the kind of thing that inspires zealous evangelism.

more experienced systems programmers, people who maintain major packages, and the Rust core team all seem to be a little more moderate in their enthusiasm even if they are huge fans of the language.

Re: Why is Rust difficult?

#184

Post by smaddox » Mon, Jan 22, 2018, 3:41 PM UTC

unethical_ban wrote: post #175

josephg wrote: post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I write somewhat simple programs and webapps for my job, from time to time. I use Python and its standard library, some modules, and the Bottle Framework. Pulling data from APIs, doing analysis, taking some user input, editing configs, etc. I hardly ever use classes unless I'm extending a vendor library. I have never used generics. Why are generics such a critical component of a programming language that every thread…

In Python, duck typing provides the benefits of generics, minus the static guarantees. If you're using duck typing in python, then you should be able to understand why generics can be useful.

Re: Why is Rust difficult?

#185

Post by steveklabnik » Mon, Jan 22, 2018, 3:42 PM UTC

stjepang wrote: post #179

steveklabnik wrote: post #172

Earlier quoted context omitted.

It also has possibly irreconcilable soundness issues :/ libfringe is another extremely interesting player in this space.

I'd like to read more about those soundness issues - do you have a link?

see https://github.com/Xudong-Huang/may/issues/6 as one example

Re: Why is Rust difficult?

#186

Post by carlmr » Mon, Jan 22, 2018, 3:44 PM UTC

bonesss wrote: post #96

carlmr wrote: post #72

Earlier quoted context omitted.

I went to F# from C#, but I felt the transition was easier than going from C to Rust. I kind of noticed that I used some functional concepts a lot in my C# anyway. I always liked side-effect free functions, I tended to do a lot with LINQ transformations already, etc. F# made a lot of these things nicer to use (+ pattern matching + discriminated unions +++)

The two languages are approaching a superficial parity, as C# eats up more and more functional concepts. I find it interesting, too, because many of the arguments about things being 'too hard' compared to C# make no sense when those concepts are baseline knowledge in both languages. The positive parts of the functional approach will make code more solid in any language, and C# is working hard to support that approach…

I agree. I just wish more other people knew F# so I could use it for more projects. I've also almost stopped using Python for my scripting purposes. F# is just so much more elegant, and if the scope of the script grows, I can grow it to a proper project.

The only reason why I still use Python every once in a while is pandas. If I have to analyze some big tables, it's still far ahead of anything in any other language I know. Sadly F# Deedle feels very clunky, especially when processing a lot of text (which my data frames are usually full of).

Re: Why is Rust difficult?

#187

Post by rspeele » Mon, Jan 22, 2018, 3:44 PM UTC

unethical_ban wrote: post #175

josephg wrote: post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I write somewhat simple programs and webapps for my job, from time to time. I use Python and its standard library, some modules, and the Bottle Framework. Pulling data from APIs, doing analysis, taking some user input, editing configs, etc. I hardly ever use classes unless I'm extending a vendor library. I have never used generics. Why are generics such a critical component of a programming language that every thread…

Python is a dynamically typed language so when you say you've never used generics, that makes sense -- the concept does not apply to dynamically typed languages. But I bet you frequently use lists and dictionaries, and perhaps occasionally use higher-order functions like map, filter, and reduce. All of those would be generics in a typical statically typed language, because with static typing you don't just have "a list" but "a list of ints" or "a list of strings".

Go has built-in generic arrays, slices, and dictionaries, but nothing else, and you can't define your own functions that work on those without specifying the type. So say you write a function that shuffles the elements of an array, like Python's random.shuffle(list). You can't make your function work for all kinds of arrays. You have to have a different function to shuffle arrays of strings, arrays of ints, arrays of FooBarClass, etc. even though the shuffling logic doesn't give a damn about what sort of thing is in the array.

I have a suspicion that this occasionally leads developers to write code inline that they previously would've extracted into a utility function. See the answers here:

https://stackoverflow.com/questions/12264789/shuffle-array-i...

Re: Why is Rust difficult?

#188

Post by joshbaptiste » Mon, Jan 22, 2018, 3:45 PM UTC

narimiran wrote: post #171

kumarvvr wrote: post #13

After years of using Python, it's been difficult to wrap my head around GO and Rust. I really wish there was a course on Rust / Go for python programmers.

> After years of using Python, it's been difficult to wrap my head around GO and Rust. I had the similar post-Python problem, until I settled on Nim [0] - it has Python-like syntax, significant whitespace, and ease of writing (but don't expect Python level of it), while compiling to C and providing significant speed benefits. Also there is a brief "Nim for Python Programmers" [1], which might interest you. [0] https:…

Ditto.. Nim was just easier for me to absorb as a Python person myself and I'm really enjoying it.

Re: Why is Rust difficult?

#189

Post by gerad » Mon, Jan 22, 2018, 3:46 PM UTC

unethical_ban wrote: post #175

josephg wrote: post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I write somewhat simple programs and webapps for my job, from time to time. I use Python and its standard library, some modules, and the Bottle Framework. Pulling data from APIs, doing analysis, taking some user input, editing configs, etc. I hardly ever use classes unless I'm extending a vendor library. I have never used generics. Why are generics such a critical component of a programming language that every thread…

When you don’t have type safety you don’t need generics. Example: in python you can call a function with any arguments (numbers, strings, whatever) and it can return anything (usually something of the same type). With go you can do this as well, but you lose compile time type safety, have to add a bunch of gross code, and incur a small performance penalty.

Re: Why is Rust difficult?

#190

Post by tjalfi » Mon, Jan 22, 2018, 3:46 PM UTC

pjc50 wrote: post #109

pjmlp wrote: post #79

Earlier quoted context omitted.

Well, I happen to consider factory control management, weapon targeting and missile tracking systems, some big serious context. Here is just one of them. http://www.militaryaerospace.com/articles/2006/10/lockheed-m... "PERC Ultra offered Lockheed Martin the responsiveness it needed to meet its most demanding timing requirements. In addition to real-time threading and deterministic garbage collection, PERC Ultra provi…

Is this where we bring in the anecdote about the missile flight control system which never freed any memory, because the minumum time to OOM was less than the maximum flight time of the missile?

Ask and ye shall receive[0].

[0] https://news.ycombinator.com/item?id=14233542