On Learning Rust and Go: Migrating Away from Python • Hacker News Board

Re: On Learning Rust and Go: Migrating Away from Python

#191

Post by tannhaeuser » Sun, Mar 24, 2019, 3:18 PM UTC

theshrike79 wrote: post #173

Annatar wrote: post #76

Earlier quoted context omitted.

There is one and only one language that's both correct and the best tool for scripting: Bourne or its superset the Korn shell (not even bash).

From Google's Shell Style Guide[1]: "If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date." [1] https://google.github.io/styleguide/shell.xml

Well if Google says so ...

Python brings a ton of dependencies, thereby seriously limiting your deployment options. And, together with Python's not-so-great package management story, this spells a lot of trouble for as long as Python 2 and 3 need to coexist. Many useful Python 2 programs (such as Apple's old caldav server based on twisted) won't be ported over to 3, and the migration to Python 3 creates an unnecessary burden on apps that chose Python as user-scripting language, such as Blender. There might be reasons to use Python, but the aesthetics (or lack thereof) of a scripting language, or an artificial limit on the number of lines most definitely isn't one of them.

Re: On Learning Rust and Go: Migrating Away from Python

#192

Post by amelius » Sun, Mar 24, 2019, 3:18 PM UTC

0815test wrote: post #162

amelius wrote: post #157

Earlier quoted context omitted.

Rust is still in research phase, as many programming patterns have no clear counterpart in Rust. Even though Rust's approach is very interesting, it might very well be that its strict typesystem turns out to be a dead-end for some existing programming patterns. Also, writing self-referential data-structures is very difficult in Rust (but not impossible) due to the type system. I suspect that a lot of developers who j…

> Also, writing self-referential data-structures is very difficult in Rust (but not impossible) due to the type system. Not really true (at least, not nearly to the same extent) since Pin was stabilized. I suppose that only serves to prove your point about Rust still being "in research phase", though!

Good to know, but I guess that Pin does not solve the problem of indirect self reference, such as when you have a tree where every node points back to its parent (e.g. for convenience or performance reasons), or a doubly linked list where each link has a forward and backward pointer (?)

Re: On Learning Rust and Go: Migrating Away from Python

#193

Post by theshrike79 » Sun, Mar 24, 2019, 3:23 PM UTC

akjha wrote: post #147

dcuthbertson wrote: post #12

Earlier quoted context omitted.

Maybe I'm picking nits, but the author is comparing programming experiences in each of those languages, which is perfectly valid. For example, last year I was part of a team that rewrote a very large Node.js program (several hundred thousand lines of code) in Go. The differences in following control flow and in the edit-build-test loop are like night and day. We've found Go meets our needs better than Node.js for wri…

Interesting. What are some the benefits you felt with Go in comparison to Node.js? We already have a largish (couple hundred thousand line) Node.js app written in Typescript and are looking towards other alternatives for the future product as I am not very happy with the quality of Node.js ecosystem.

In my experience the active aversion to all kind of magic make Go code more maintainable even if you're not familiar with that particular part of the code base.

Stuff goes in, stuff comes out. You don't need to wonder if something outside of the scope magically comes around and changes things in the middle.

Also Go's concurrency pattern with goroutines and channels fits really well to my mental models of how stuff tends to work in my field.

Re: On Learning Rust and Go: Migrating Away from Python

#194

Post by steveklabnik » Sun, Mar 24, 2019, 3:23 PM UTC

civility wrote: post #182

0815test wrote: post #153

Earlier quoted context omitted.

The Rust compiler is well known for having rather less-than-stellar performance, and this can definitely impact larger projects. (Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation. It's not exactly an easy issue to address, given that LLVM itself is rather old and clunky code; written in C++ for maximum portabil…

> Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation. Considering clang generates LLVM IR and compiles much more quickly than Rust, this argument doesn't hold. The Rust compiler generates IR which chokes LLVM and makes it slow, but they didn't have to do that.

Yes and no; we can reduce the amount of it, but since we have different features, we will pretty much inherently generate code that skips FastISel. For example, “match” generates IR that’s not part of it. (See here for more: https://internals.rust-lang.org/t/why-cant-rust-use-llvm-fas...)

It’s a huge problem with a number of different causes.

Re: On Learning Rust and Go: Migrating Away from Python

#195

Post by root_axis » Sun, Mar 24, 2019, 3:23 PM UTC

bayesian_horse wrote: post #71

pagefault123 wrote: post #37

Earlier quoted context omitted.

Perhaps there should be apostasy punishments for Python defectors. /s Python's typing story is far from perfect and rather annoying compared to other languages. Python is good for interacting with the operating system, networking and other things. But wanting a proper compiler is an honest motivation.

There are type checkers now. Personally I find type systems a lot more annoying because they lead to more verbose code and more cognitive load. There are studies that show bugs being proportional to the number of lines of code, regardless of language. And that effect seems to be more significant than the difference among dynamic and static type systems. Defensive programming can be achieved through various means. Typ…

A proper type system offers a level of safety and correctness that simply cannot be achieved without one, especially as the complexity of an application grows. Also, the supposed lack of cognitive overhead without a type system is actually a subtle form of technical debt where you move faster because you eschew thinking deeply about your data structures up front, but inevitably pay a bigger price in production when you have to debug data type errors at run-time. The debt has to be paid again by every new developer tasked with working on the project because they have to organically absorb an understanding of the application's data structures that could have been explicitly defined and enforced by the computer. Finally, the extent of "defensive programming" required to begin to make up for a type system actually adds a ton of extra code itself (e.g. tons of guard blocks testing brittle application values at run time). Not all type systems are created equally, but a code base without types is pretty much always worse than a comparable one with types (the exception being shell scripts and other relatively simple programs that aren't maintained by a team of developers)

Re: On Learning Rust and Go: Migrating Away from Python

#196

Post by theshrike79 » Sun, Mar 24, 2019, 3:26 PM UTC

ChrisSD wrote: post #40

This is more of a general observation but why are Rust and Go so often mentioned in the same sentence? They are designed around very different use cases such that a direct comparison doesn't seem to warrant as much attention as it seems to get.

Both are modern languages but with (IMO) vastly different views on how a language should be constructed.

Go went with simplicity to a fault. No generics (use code generation instead), just one way to make a loop, garbage collection.

Rust on the other hand has all the bells and whistles a language could have combined with the ability to micro manage every bit of memory you're using.

People tend to lean either way.

Re: On Learning Rust and Go: Migrating Away from Python

#197

Post by mlthoughts2018 » Sun, Mar 24, 2019, 3:31 PM UTC

yakshaving_jgt wrote: post #185

mlthoughts2018 wrote: post #128

Earlier quoted context omitted.

I’ve worked professionally in Haskell across three jobs (one huge corp, two start-ups), and seeing how bad Haskell functions in practice, when quickly mutating state to incrementally modify behavior is live-or-die necessary and under constant business pressures from product managers who don’t care about the paradigm of the backend. I’ve found so many unexpected runtime errors in Haskell, behavioral bugs that require…

I see. I guess I should rewrite my Haskell projects into something else then. Yes, I am more than satisfied with how quickly I can develop features according to business needs. Yes, I am more than satisfied with the [observed] robustness. Yes, these businesses are currently 100% of my income. But as you rightly point out, Haskell is bad . /s A few things are interesting to me here: 1. How we've managed to come to suc…

I did not intend to “attack” you and I don’t believe that’s a good-faith characterization of what I wrote.

I do attest to this same criticism of Haskell from time to time because I believe it’s important to refute the very frequent, baseless claims that are often made on Hacker News that claim that functional programming or static typing can make any difference on the reliability or rate of defects in software: they cannot and do not.

I’m not at all trying to dissuade anyone else from using Haskell if they want to use it, and in fact I’d even go so far as to say Haskell is my favorite programming language.

As long as everyone checks the wild claims at the door, and we all admit that there is no difference in terms of safety, robustness, performance, reliability, readability, etc., between Haskell, Scala, Rust, OCaml, Python, Java, Go, Erlang, C++, C#, F#, C, FORTRAN, etc.

None of them is conceptually superior or dominant across a wide range of use cases. It’s just as easy to get hard-to-fix errors in all those languages, just as easy to categorically prevent other classes of errors, just as easy to design for compositional or extensible interfaces, etc.

As long as everyone is essentially willing to accept a No Free Lunch theorem about programming languages, then I don’t care what language people like to use or happen to prefer for personal reasons. I’m not attacking any such preferences.

But when there are unqualified comments about some paradigm or language (like functional programming, or Rust, or Julia, or Haskell, or static typing) being strictly better than some alternatives (like OOP or Python or C), then it’s worthwhile to counter that claim by pointing out that no, in fact, all those paradigms easily lead to the same problems and in no way offer any type of widely applicable solution to the usual problems of developing software.

Re: On Learning Rust and Go: Migrating Away from Python

#198

Post by oselhn » Sun, Mar 24, 2019, 3:32 PM UTC

coldtea wrote: post #186

oselhn wrote: post #183

Earlier quoted context omitted.

Only if they are correct. I am pretty sure that in old code base it will not be correct unless automatically checked before commit.

That's trivially settled with a static type checker. So the argument is analogous to saying "how can I trust the types in this Java program are correct, if it has never been compiled". Well, whether some "old code base" has them correct or not, just run the type checker and find out.

If you do that you will probably hurt your productivity. There still will possible errors made by using 3rd party code.

In my opinion optional type checking is not comparable to statically typed language guaranties. So if I do not need types I would use python. If I need/want type specification I would use statically typed language.

Re: On Learning Rust and Go: Migrating Away from Python

#199

Post by [deleted] » Sun, Mar 24, 2019, 3:33 PM UTC

ryanianian wrote: post #148

ptx wrote: post #48

Earlier quoted context omitted.

I've been doing some Java lately, and it seems to me like Java libraries are often doing (and making the programmer do) a lot of work just to get back the dynamism that Python has by default. Many kinds of errors are only detectable at runtime: * dependency injection errors, * template errors, * magic annotation malfunctions, etc. The last one in particular actually seems less safe than Python's decorator mechanism.…

You seem to be describing things that frameworks like Spring add. Java itself (as a language) doesn't "do" anything with annotations, they are literally just some extra strings in the class-file. Spring and its friends use those strings to do their magic. (Personally I find modern Spring applications as inscrutable as RoR applications which does indeed throw many categories of debugging out the window. Can't set a br…

[deleted]

Re: On Learning Rust and Go: Migrating Away from Python

#200

Post by ChrisSD » Sun, Mar 24, 2019, 3:37 PM UTC

theshrike79 wrote: post #196

ChrisSD wrote: post #40

This is more of a general observation but why are Rust and Go so often mentioned in the same sentence? They are designed around very different use cases such that a direct comparison doesn't seem to warrant as much attention as it seems to get.

Both are modern languages but with (IMO) vastly different views on how a language should be constructed. Go went with simplicity to a fault. No generics (use code generation instead), just one way to make a loop, garbage collection. Rust on the other hand has all the bells and whistles a language could have combined with the ability to micro manage every bit of memory you're using. People tend to lean either way.

But those different "views" are born of their different use cases. Rust is meant to be low level, like C++, and thus micro managing memory is an essential feature it can't do without.

Go is meant to be a higher level server side language that replaces languages like php, python or Java on the server. It's simple so it's almost as fast to compile as a scripting language is.