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

Why is Rust difficult?

vorner.github.io

Post reply on HN
Print view View original

241–250 of 260 posts

Re: Why is Rust difficult?

#241

Post by kqr »

majewsky wrote: post #98
tatterdemalion wrote: post #16

Earlier quoted context omitted.

What we could do better than we do today - and your comment about ergonomics alludes to our work to improve this - is ease the onboarding of that complexity we have to be "honest" about. Its a design constraint of Rust that it must maximize user control, but that does not imply that users have to be faced with all of those choices as soon as they first try to write Rust. In some respects I think this article is an at…

I would like a language that has knobs (e.g. file-level pragmas) for strictness, which you could turn all to one side (to get something as strict as Rust) or all the way to the other side (to get something like Ruby) or somewhere in between. For example, a REPL would be pretty non-strict: When you define a function, you don't have to annotate types on the arguments, and everything gets passed around as generic object…

For the record, in PL jargon, "strictness" commonly refers to how soon the arguments in a function call are to be scheduled for evaluation. Using it to talk about the extent of static correctness checks can be slightly confusing!

Re: Why is Rust difficult?

#242

Post by stubish »

always_good wrote: post #129
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…

On the other hand we ripped out channels and went back to mutexes. And my experienced Go-developer friends seem to have all the same reluctance to use channels after ending up in channel hell. There are good aspects of Go concurrency like how the whole ecosystem is async by default (like Node's), but truly praising the model is something I mainly hear from beginners.

This is something I noticed with Go. Channels are great and all and occupy a decent chunk of the tutorials and whatnot, but they see to be rarely used apart from a fairly cumbersome way of handling timeouts and cancellation. It seems if you stick concurrency in your libraries you end up in knots, and its left up to the code that uses the libraries to wire up all the synchronous & blocking bits.

Re: Why is Rust difficult?

#243

Post by stubish »

josephg wrote: post #76
jchw wrote: post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> 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'm a little bit tempted to make a simple compile-to-go language. I'd get lynched at Go meetups for fragmenting the ecosystem, but it might be worth it. I like almost everything about go except the language itself.

If you rephrased that as 'a templating language for generating Go code', it would slot into the 'go generate' build stage and people would love you (if you got it right ;) ). The only current solution to boilerplate and lack of generics is code generation, but the templating languages all seem to suck for Go code generation so people are stuck with writing Go programs to generate Go code (like the various enum generators), or attempt to marry Go code with the standard text templating which is awful to work with (like, say, Xo).

Re: Why is Rust difficult?

#244

Post by stubish »

flavio81 wrote: post #239
dullgiulio wrote: post #85

Earlier quoted context omitted.

I do hope it's not true that people from the community would attack you for writing a compile-to-go language. I don't think it's such a bad idea, considering how stable the language itself is, it's a pretty solid bet.

>writing a compile-to-go language. Why not fix Go instead?

You can't fix Go directly. You have to convince the language designers that it needs fixing. The fastest way of doing that would likely be at least a proof of concept, or better yet, a complete tool that gets significant community uptake.

Re: Why is Rust difficult?

#245

Post by carlmr »

Rapzid wrote: post #234
carlmr wrote: post #186

Earlier quoted context omitted.

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…

F# is my language crush. Been following it and hoping to use it for a long time. I'm in a leadership position and could MAYBE push to standardize on it however the current more likely scenario is TypeScript(I know, I know) due to my having already successfully pushed that out haha. Unfortunately the ship is already a bit far from shore. Trying to move us completely away from Python for infra due to its tooling/langua…

>I'm in a leadership position and could MAYBE push to standardize on it however the current more likely scenario is TypeScript(I know, I know) due to my having already successfully pushed that out haha.

If you're currently on JavaScript that's definitely an improvement. You could push for F# + Fable in that case. The F# Ionide VSCode extension is written with Fable. It's like TypeScript, just better.

http://fable.io/

Re: Why is Rust difficult?

#246

Post by frankzinger »

steveklabnik wrote: post #177
titanix2 wrote: post #38

Earlier quoted context omitted.

This is the exact reason I won’t learn Rust past looking quickly the doc: the promotion made by some very vocal people is a huge turn off. Notably by saying that everything must be rewritten in Rust, it implies that every other language is sh*t and people using them are dumb. Of course I don’t like that view for my work nor I won’t to be associated with this kind of people. This is a bit sad because the language prob…

Where are you seeing these kinds of comments? Can you link me to them? I’d like to tell them to cut it out.

It's calmed down the past year or so but before that it was so insane (especially here on HN) that the impression will be hard to erase for those who were around to see it.

Re: Why is Rust difficult?

#247

Post by vlovich123 »

coldtea wrote: post #119
vlovich123 wrote: post #112

Earlier quoted context omitted.

Spectre & meltdown would like to have a word with you. Yes, memory/concurrency are a large class of problems for C/C++, but plenty of security issues still exist in other languages (check out the CVE count for Django for instance). The thing about security is that attackers will predominantly use the path of least resistance. As prevention evolves so does the sophistication & vector of attacks (e.g. timing attacks at…

> Spectre & meltdown would like to have a word with you. Both are highly atypical, once in a decade, CPU issues, so represent 0% of software related bugs.

Those 2 bugs are part of the class of timing attacks which are quite common for security & no amount of memory safety will help you there (as Spectre & meltdown have shown they're not even restricted to the SW domain). Same goes for things like not sanitizing inputs for things like SQL injection, XSS etc. AFAIK Rust doesn't do much on that front either. I don't disagree that memory related errors are the cause of a lot of problems. However, I think that's because C/C++ is so common & it's such low-hanging fruit, why bother? I see no evidence that attackers are running out of tricks to pull to exploit SW regardless of the language it's written in or the countermeasures you have deployed.

Re: Why is Rust difficult?

#248

Post by vlovich123 »

kilburn wrote: post #120
vlovich123 wrote: post #82

Earlier quoted context omitted.

You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web br…

> As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that. Not very mainstream, but take a loot at elm's compiler errors [1]. They worked hard in this direction, and the result is both helpful and beautiful. You can try loading up any of the examples in the online editor [2] and introducing a random bug, just to see how the compiler barks tries to gently teach…

I think my point was that they may teach you if you already have some fundamental knowledge (or help remind you of the rules anyway) but they're not instructive in and of themselves (you could copy-paste the suggestion to "fix" your problem quickly but that's not really increasing your understanding I think).

Re: Why is Rust difficult?

#249

Post by ralfn »

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 doesn't need generics because it doesn't try to statistically type your code in the first place.

    def example(a):
        return a
Would be perfectly legal python code. But in Go you would have to choose the type of A and duplicate the function under a different name if you want it to work with a different type.

So, when a language implements static typing without generics they actually mean 'lots of code and approaches legal in Python would be rejected'.

So it doesn't add a feature to the expressiveness of the code. It fixes a bug in the type system so that the expressive code is considered legal. Of course better type systems have existed since the 70's, but the set of people that know the ins and outs of how to implement those and the trade offs behind it does not include Rob Pike. His interests and skills are different (and the cause of some of the better features of Go)

Re: Why is Rust difficult?

#250

Post by flavio81 »

stubish wrote: post #244
flavio81 wrote: post #239

Earlier quoted context omitted.

>writing a compile-to-go language. Why not fix Go instead?

You can't fix Go directly. You have to convince the language designers that it needs fixing. The fastest way of doing that would likely be at least a proof of concept, or better yet, a complete tool that gets significant community uptake.

Ah, unlike programmable languages like Scheme or Lisp, where I can modify the language as needed, by using code.
Post reply on HN