26 ms·

On Learning Rust and Go: Migrating Away from Python

240 points by edward 8y ago

fxj 8y ago
After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.
- danieldk 8y ago
  Even if languages have different typing regimes, that does not mean that they can be compared. They are means to an end after all. Outside the language itself, you can also compare ecosystems, available tooling, etc. For his ends, statically-typed languages have benefits over Python: Obnam is about 15000 lines of Python code. That turned out to be too much for me in Python: too often there were bugs that a static, strong type system would have caught.
- jMyles 8y ago
  At a high level, I agree with what you're saying here - that it's difficult to compare rust or go with python. But I take some issue with your reasoning. > After all python is still an interpreted scripting language. Is it? Or rather, is this even a well-defined category? > interpreted Can't any (OK, almost any) language be either interpreted or compiled? The fact that python is typically run in an interpretive runtime setting doesn't really make it "interpreted" as a language. In fact, since python is nearly always compiled to byte code at runtime, it's arguable just as compiled as it is interpreted. But that's not even the point: there's nothing lingual about python that stops it from being compiled. It can be compared with other languages that are typical run subsequent to a compilation step without being the apple to an orange. > scripting This one speaks to me even less. For python to properly be understood as a "scripting" language, I think you'd have to convince me that the lion's share of community energy is dedicated to a paradigm of running a single module front-to-back as a script. And this is clearly not so.
  - pushpop 8y ago
    They have a historic point but you’re right that their description doesn’t make much sense given the modern way language runtimes are designed. A better description would be “high level JIT compiled language”.
  - codetrotter 8y ago
    I largely agree with what you said but > there's nothing lingual about python that stops it from being compiled Are you sure? Python is a very dynamic language. Some of the most dynamic parts of python might not be possible to compile fully ahead of time and might need to be JITed, because the behavior of the code will only be possible to determine at runtime.
    - darkr 8y ago
      CPython doesn't have a JIT. It compiles to bytecode, which is then "interpreted" by a stack based VM.
  - frou_dh 8y ago
    > Is it? Or rather, is [Scripting Languages] even a well-defined category? We could say that the typical compiled language is used for scripting Unix syscalls :-)
- nkozyra 8y ago
  I disagree. It's a language, it has symbols, syntax and conventions, it either gets interpreted or it gets compiled. In the broad swath of languages, go and python are more similar than, say, python and Haskell. What makes languages apples and oranges is generally not their compilation method but things that are more approach-centric or radically different syntax (which is why I left Rust out. Its syntax has been the thing that's slowed me down most there)
- dcuthbertson 8y ago
  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 writing and debugging large programs. The languages are very different. Both are used for small and large programs. The experience in using them is what makes us choose one over the other.
  - akjha 8y ago
    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.
    - theshrike79 8y ago
      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.
    - dcuthbertson 8y ago
      Sorry for the late reply. There are a few advantages to go. 1. we don't force our customers to lay down a large Node.js blob just to run our software. 2. The old code was written for an old version of Node.js, v4.x, I believe. As such, it was full of code suffering from callback hell, and a lot of anonymous functions written inline. It was very difficult to reason about when tracking down bugs. I'm sure your Typescript code is far better organized. 3. The edit-compile-test loop is far faster. It takes less than a minute (20-50 seconds) to compile the new codebase, which is a mix of Go and C apps and libraries. The developers use a simple build script to rebuild everything from scratch. The old codebase, a mix of Javascript and C apps and libraries, was built with CMake to manage dependencies. Each rebuild would complete in a few minutes for small changes, but could take about 10 minutes if the "right" code was touched. 4. Like theshrike79, I find Go's concurrency patterns, channels, and goroutines a delight to use. 5. We use json files for configuration. Go has a simple scheme for converting between json and structs. Node.js allowed us to make poorly structured json files. When we converted them to follow some simple nesting patterns of structs within structs, converting between structs in memory and json files was just too easy! It seems that the new codebase is significantly smaller, so it's easier to find where things are implemented. Part of that is getting rid of tech debt and being very familiar with the new code. When we were still in beta, we ran some performance tests. They indicated the new code was as performant as the old node code (which has been worked on for years). We expect to be able to improve on that as we have time. I hope that helps. It's been a major amount of work to rewrite our apps while maintaining the old code base - not something to do on a whim. I know the dev team is delighted with the results. Good luck.
- gameswithgo 8y ago
  comparing apples and apples would be even less interesting.
kumarvvr 8y ago
At 15000 loc, if the author found it difficult to organize python code, then it's not python's fault. I find it a pleasure to organize code in python. What am I missing here?
- jacquesm 8y ago
  Exactly. 15Kloc is just out of the 'this stuff is easy' zone and switching to Rust or Go will make that problem larger, not smaller (because you will need more code to achieve the same effect).
  - pushpop 8y ago
    It’s not just about code organisation though. Both Rust and Go have fantastic compilers which catch a great many dumb but common user errors before you even get to the stage of testing. Obviously this doesn’t replace the need for functional tests but writing those tests is as much prone to user error as writing the code itself. So having a compiler check for stupidity up front is always going to be a bonus. Also the static type system helps a lot too. Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes effectively have written specifications defined in the code itself which the compiler verifies the rest of your program against. So if you’re accidentally trying to write text to a numeric type, your compiler will catch that. In my experience the extra up front overhead (in terms of development time) of static typed AOT compiled languages end up saving you development time in the long run when working against larger projects.
    - nurettin 8y ago
      Mypy and type hints does catch that.
      - pushpop 8y ago
        Sure. There are additional tooling you can use in Rust and Go to catch a plethora of errors beyond what I described too. However if they require the user run them manually then they’re just as open to user error as the testing I also described. This is why having those checks in the compiler itself can be invaluable.
jacquesm 8y ago
15Kloc and trouble is indicative of other problems than a problem with the language. I wrote multiple 50Kloc and up pieces of software in GFA Basic, arguably a much more limiting and unsafe environment than Python ever was, and yet, that software worked well and was maintainable to the point that its descendants still run 3 decades later. Python has all the bells and whistles you need to build large code bases, but you do need to get organized, no language can really do that for you and attempts at forcing you to do it give rise to 'factory factory' nonsense. I'm no huge fan of Python, I use it when I have to but Rust is from a bells-and-whistles point of view a step down from Python, it is more a better 'C' than a better Python and Go has it's own share of issues that has kept me away from it so far. If you want to crank out some research project or application quickly building on the libraries that others provide (especially in machine learning or other data intensive fields) then Python would be my first choice, and something like 'R' probably my second (though I see 'R' mostly as a data scientist's workbench that has a programming language bolted on).
- IshKebab 8y ago
  I disagree. 15k lines of code is a lot of code to keep entirely in your head all at once, which is basically what you have to do if you're using a language as dynamic as Python. In static languages like Java you can easily use tools to check types are correct, find usages of variables, jump to definitions and so on. And you get compile time errors if you screw up, rather than runtime errors.
  - Bishonen88 8y ago
    Most of the above is due to a proper IDE. Python, too, has one: PyCharm. Comes with 'find usage of variables', 'jump to definition', types checking, syntax correction, import optimization and much much more. 15k with pycharm is a walk in a park \*More than one, of course. But I use only PyCharm :)
    - mateuszf 8y ago
      It depends on the language. The more metaprogramming is used the harder to automatically refactor. While you can do reflection/code generation even in Java, for the non-framework code almost nobody does it. That's why I feel lot safer with large codebases in Java, even though I love some dynamic languages too. I don't think they're as scalable for big programs though.
therealmarv 8y ago
15K LOC in Python. Be prepared to increase your LOCs to at least 33-100% when writing in Rust or Go, hopefully your error rate by line of code will decrease more than your overall LOC. There are not only benefits.
- weberc2 8y ago
  I’ve written a lot of Python and a lot of Go. The errors per loc are much lower in the latter because code density is much lower and because of the type checker. In other words, if you measured errors by statement or something more meaningful than “line” then it would account for the difference in density, but I would still expect far fewer errors in Go.
julienfr112 8y ago
Line of code is a relative measure. If you leverage package like numpy/pandas, asyncio and co, you could easily write python code that are ten fold shorter than their C/rust/go equivalent. And improving speed when you make a good use of numpy requires quite an amount of time and skills.
sidcool 8y ago
I am personally investing heavily in Rust. I hope to bear some fruit
0815test 8y ago
Not trying to dismiss this person's work in any way, but is there any reason why this blog post should be considered notable? They clearly say at the end that they've yet to write any real-world code in either Rust or Go, and so far have just been learning about either language - so how come that this shoots up to the top of HN? Is it just the magic keywords "Rust" and "Go" that do that?
- dpc_pw 8y ago
  I am a Rust fanboy, and I can't see anything worthwhile in this article. I joke that any love-story about Rust will get you to a front page of HN. Yeah, Rust is awesome, and many people love it, but it is a bit ridiculous.
  - vonseel 8y ago
    I wonder a little about the source of the name "Rust". That seems like an odd choice for a language name - not that it matters. Rust - being associated with old metals - makes me think of something that's been left out and abandoned. Maybe because I'm from a rural part of the country where you see a lot of rusted metal sheds or abandoned structures. Go, on the other hand, makes perfect sense - "let's go!" implies that it is something that is made to get things done and also being the first two letters of Google.
    - steveklabnik 8y ago
      It’s got multiple associations, the “well-worn tool” one is one of them. https://en.m.wikipedia.org/wiki/Rust_(fungus) https://en.m.wikipedia.org/wiki/Rust_(fungus) is another.
yakshaving_jgt 8y ago
I share the author's sentiment, and it's what lead me to Haskell. It's faster and cheaper for me to write prototypes in Haskell than it ever was in Ruby. And at least in startup-world which is the bulk of my career, the speed at which you can build a reasonably robust prototype can be the life or death of a business, and this prototype usually ends up being the production product anyway. Prototypes are seldom rewritten "properly".
- mlthoughts2018 8y ago
  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 deep, stateful dependency injection to properly test for, type class designs that were set up wrong for some use case last year and now are horribly brittle and unmanageable to try to use it for the new use case that needs customer feedback immediately. Plus, for all the syntactical niceties of Haskell, the code becomes unreadable the instant you start needing a dozen different GHC compiler pragmas all defining weird special behavior or syntax. Yet it’s just basic Haskell 101 these days to require new compiler pragmas for tons of basic functionality that you could get out of the box in other languages. Getting a whole team up to speed on how to mentally keep track of that from one section of code to the next is a very difficult chore. My real life experience with Haskell is why I don’t use it professionally any more.
  - yakshaving_jgt 8y ago
    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 such different conclusions despite supposedly having similar experiences 2. The vigour with which you attacked my rather innocuous comment 3. I had a look at some of your previous comments about Haskell, and you seem to repeat the same talking points over and over, almost verbatim. In fact, this comment you made is particularly interesting: > it becomes the same shit code mess as any other paradigm.[0] If what you say is true, then what is your argument exactly? If everything inevitably produces the "same shit code mess", then why are you attacking me for essentially saying "I like Haskell and it is working for me"? [0]: https://news.ycombinator.com/item?id=19400648 https://news.ycombinator.com/item?id=19400648
xyproto 8y ago
The strengths of Go become apparent when working in teams and when deploying, not when reading blogs about the language before trying to write code in it.
- lima 8y ago
  Exactly this. Rust is quite the opposite of Go in that regard - just like C or C++, it makes it really easy to write over-abstracted and clever code that is hard to understand, audit or review. Rust is also an extremely powerful tool and a ray of hope for systems programming, but comparing it to Go is an apples and oranges comparison.
- empath75 8y ago
  I’m working in a team of 5 people who has never used go prior to 9 months ago and had no training in it and we’ve just been unbelievably productive in it. We came to it from a combination of python and javascript backgrounds and have no problems collaborating or jumping into each other’s code. To me the main advantage of it is that the small number of primitives and simple syntax forces people to in general be very explicit about what you’re doing. The code almost doesn’t need comments.
  - 0815test 8y ago
    > To me the main advantage of it is that the small number of primitives and simple syntax forces people to in general be very explicit about what you’re doing. The code almost doesn’t need comments. That has little to do with 'simple syntax', and more with the language itself (and/or its community) setting clear standards as to what "idiomatic" code in the language should look like. And Rust is fairly good at that, albeit with the inherent limitation of having to support the additional complexity of ownership/lifetime management. (Go can do without this since it uses GC instead. Swift just uses ARC everywhere.)
  - apta 8y ago
    Coming from dynamic languages like Python and Javascript, it's not hard to beat those. Compared to something like Java or C#? Yeah, golang trails way behind. That's why you keep seeing such claims, because many people come from a background where they weren't exposed to a strong ecosystem, so any minor improvement seems like a big deal.
LawnboyMax 8y ago
Strongly agree with author. I really like Python and at one point thought that it makes sense to write almost any project in it, since it's so versatile and I know it pretty well. After working on a quite large application and having to use lots of assert(isinstance(arg, type) at the beginning of almost every function, I began to think that a strong type system is very much needed for large projects. I believe this was one of the reasons why Twitter moved from Ruby to Scala. I still love to use Python for hacking something quick for myself. But I also look at some popular strongly-typed languages now and hope to get better at one of them soon.
- ris 8y ago
  You're confusing static typing with strong typing. Python is strongly-typed, but not statically typed. Python's optional typing could also be used to get rid of a lot of your assertions.
  - yawaramin 8y ago
    You are confusing optional typing with optional static typechecking. Python has the latter, not the former. In other words, everything is typed in Python and it will always check types at runtime.
- jsjohnst 8y ago
  > I began to think that a strong type system You’re confusing static/dynamic and strong/weak. Python is a strongly typed language, but also is dynamicly typed language. Need proof? Try doing this: a = 3 b = “3” c = a + b > having to use lots of assert(isinstance(arg, type)) Python has type hinting now, try using a current version of Python and this isn’t needed.
  - flyinglizard 8y ago
    The point is that your example will not break anything until run time, unless some static analysis tools are deployed (which are much more limited compared to what a compiler can achieve).
  - 8y ago
toyg 8y ago
> Note that I've not written any significant code in either language, so I'm just writing based on what I've learnt by reading. So he’s basically comparing 20+ years of Python usage with marketing material from Go and Rust. Right. I wish people could be honest with their motivations, instead of making up excuses to justify this sort of change. Here it’s a classic case of “I got bored and I don’t like the new features, want new shiny”, wrapped in a bit of whining about problems that have well-known solutions (use a good IDE, use type hints or one of the many libs that enforce types...). I have no problem with that, just don’t try to sell it to me on technical grounds, because it looks very much like you have none. Python is still one of the best ways to get stuff done, quickly and with a minimum of boilerplate. Its limitations are well-known and have not really increased for about 15 years - if anything they have shrunk in many, many areas. Adoption rates keep exploding, despite a lot of doom forecasted by some alpha geeks about 10 years ago: “There is no mobile story! We will all be using Ruby/Go/NodeJS tomorrow! Nobody will ever go to Py3!” Etc etc etc. You got bored by it? That’s fine, it happens, no harm done. But you don’t need to convince anyone, including yourself, that you’re moving on because of this or that flimsy excuse.
- 0815test 8y ago
  > Here it’s a classic case of “I got bored and I don’t like the new features, want new shiny”, wrapped in a bit of whining This seems to be a rather shallow reading of the blogpost, and the way you phrased your reaction is not exactly polite either. If anything, the "adoption rates" of Python (like those of ECMAscript, a language of a similar vintage all-things-considered) are most easily explained by non-technical factors, so I have quite a bit of trouble making sense of your comment.
  - Annatar 8y ago
    There was absolutely nothing impolite in the way he phrased his response. Rather, what I'm responding to is passive-aggressive.
- pagefault123 8y ago
  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.
lordnacho 8y ago
I'm going to have a go with Rust and Go too, but for different reasons. IMO Python is still the best language to go with when you are writing anything "scripty": - Stuff that's not expected to be long. Do one thing well, let some other program do another, compose the higher order functions from functions that work. Of course this isn't always possible. - Stuff where the types are not going to confuse you. Often you just have a few types, and it's fairly obvious what you can do with a given object. If you get too many types, there's a good chance it will start to get confusing and then strong typing would help. - Stuff where performance is not a problem. Don't write your HFT system in Python. You simulation though, might benefit from orchestration of some VMs. The ultimate use case for Python is glue code. And guess what, a lot of code is just glue. A good glue language has a large ecosystem of libs, and some language features that make it easy to read. That's Python in a nutshell: whitespace formatting makes things easy to read, and you get built in list/dict syntax to keep everything short and sweet. For me Rust and Go are interesting having come from C++. There's a lot of pitfalls in C++ that might be helped with Rust. At the moment I have a whole load of Valgrind suite tests that look for potential problems. Perhaps Rust can bake those into the language? I haven't had time to look at it yet. Go seems to be interesting as a compromise between easy and fast, and by the sound of it things have turned out well. I have people on my team using it, and it seems to be the thing to do for web services that need to be faster than nodejs but you don't want to spend a load of time making sure a c++ version is correct.
- NateDad 8y ago
  C++ versions are never correct
- Annatar 8y ago
  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).
  - tannhaeuser 8y ago
    You probably mean the POSIX shell [1] ;) I never understood why folks venture into bashisms for no or little gain (bash isn't even the default shell on Debian/Devuan), or would invent/use entire new languages with singleton implementations such as Perl in the 1990s or Python in the 2000s (other than for fun, of course). Note that Python is actually a descendant of the ABC programming language developed to be human-friendly, not a shell replacement language per se. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
buro9 8y ago
I'm currently migrating a similarly sized Python and Django application to Go but for different reasons. For me it's bit rot. My Python is approaching EOL on this version and needs upgrading to Python 3, and I have a lot of 3rd party code in here that made things simpler to create but over time they've changed enough or disappeared that I now have to take on work there too. Then Django and it's internals have changed a lot in the last 6 years. My Go code written at the same time (6+ years ago) hasn't had any of it's libraries change so much that I've needed to do anything. Every now and then I pull the next major version of Go and recompile and it's done. This is all side project stuff but a lot of people use it (monthly average visitors being +250k)... it's non-profit and I don't wish to have to maintain it much. It worked once, if nothing has changed in the functionality it should keep working... but this isn't as true in non-compiled languages where you need to depend on so much of the environment, let alone build culture that doesn't fully vendor dependencies. I like Python, but prefer to write code and move forward with other projects. As to Rust vs Go. I code in both and only picked Go here because a lot of the code in another project I worked on can be used here. I'd probably try Rust if I was starting from scratch now. But I'd be a little concerned bit rot would affect Rust too, it's still quite early for the wider ecosystem.
- ris 8y ago
  What you're actually saying here is "Using Go I'm going to leave the application with unmaintained versions of its libraries", which is a bit of an alarm-bells statement from a security point of view. It's perfectly possible to build a python application that is extremely reliably tied to its dependencies, you just have to avoid the default python package "management" solutions that get shoved down everyone's throat (pip, virtualenv, pipfile, tox and the like). I've been building python projects on top of Nix for years and have managed to maintain stable and reliable results.
  - empath75 8y ago
    “It’s easy to do it if you build your own dependency management system” doesn’t sound like it’s easy to do it.
ChrisSD 8y ago
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.
- empath75 8y ago
  They’re different use-cases but they’re both modern statically typed languages that are ergonomically nice compared to previous alternatives in their spaces.
- theshrike79 8y ago
  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.
  - ChrisSD 8y ago
    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.
    - apta 8y ago
      Because when golang first came out, it was hyped as a "systems language", and meant to compete with C++. Most people use that term to refer to languages you use to write kernel level software. Of course, contrary to the golang author's wishes, golang ended up being a competitor to python/nodejs/etc. but it's still the case that the marketing hype from when the language first came out affects what people talk about, even if they don't know the context of why that discussion came about in the first place. Rust on the other hand, is a (somewhat) viable C++ replacement, as can be seen in the projects that get implemented in it (e.g. Rust made its way into the Firefox browser, as well as other low level and speed critical networking projects at different companies).
_ZeD_ 8y ago
try java. no, seriously. java and a good IDE (netbeans or eclipse, not some editors like vscode) are a godsend to handle "bigger" project. It's absolutely fast to compile and insanely on-the-fly static checks all over the place.
siteshwar 8y ago
> Rust is developed by a community, and was started by Mozilla. Go development seems to be de facto controlled by Google, who originated the language. I'd rather bet my non-work future on a language that isn't controlled by a huge corporation, especially one of the main players in today's surveillance economy. Anyone else agree with this view ? Programming languages should be choosen based on technical merits, rather than who is behind it. Is there a lesson from history that I am missing ?
- russtrotter 8y ago
  I'd say, all things being equal, yes, choose languages on tech merit or suitability to task. But look at what's happening with Java and Oracle's handling of it. I think the Google vs Oracle lawsuit is still going through appeal. Ask Google if they wish in hindsight they'd built Android on something else.
  - stingraycharles 8y ago
    Not saying you’re wrong, but Google re-implemented Java for Android, which is quite different from using Java alone. So it’s not a completely fair comparison.
    - gbear605 8y ago
      Of course the reimplementation is what got them into this lawsuit...
      - phkahler 8y ago
        I think it's more accurate to say that not paying Oracle is what got them in court. Either way it shows that the steward of a language can be important.
  - apta 8y ago
    > But look at what's happening with Java and Oracle's handling of it. It got fully open sourced?
Annatar 8y ago
"Partly it's because I'd like more help from my programming tools, such as static type checking, better handling of abstractions" As soon as I read that, I know immediately that I'm dealing with an object-oriented programmer. Always the same gripes, always the same problems! Your programming paradigm is busted and no language will ever be able to change that, no matter what lexicography and grammar it implements! There is a reason why procedural or functional programmers don't complain about those types of issues!
coleifer 8y ago
So a typically unimaginative python programmer sees new Kool aid and is thinking about taking a drink. Decides to write blog post about it. And somehow it's #1 on hn.
- weberc2 8y ago
  What’s your specific complaint? That someone is picking up other languages? That they are writing about them? I use Python as my primary language too, but I don’t see anything objectionable about these things...
- dang 8y ago
  Please don't break the site guidelines, regardless of how wrong you feel someone else is. We've had to ask you this multiple times before. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - coleifer 8y ago
    Which one did you feel I had broken? This post was just meme-filled gas.
    - dang 8y ago
      You broke the guidelines about name-calling, flamebait, and snark. HN users need to follow those regardless of how bad an article is or they feel it is.
coleifer 8y ago
Dude wants a compiler and wants to go fast. And he picks rust? Guys been hanging out way too long on hackernews.
- Annatar 8y ago
  Could not have put it better myself. If he wants fast, short of hand writing in assembler, CUDA Fortran is the way to go. Too much exposure to "Hacker" "News".
- tomrod 8y ago
  Why not Rust? I am in a similar situation to the author. Python handles most of what I need, but that last 20% I need more.
  - 0815test 8y ago
    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 portability, not so much performance.)
    - AsyncAwait 8y ago
      > The Rust compiler is well known for having rather less-than-stellar performance. You can do 'cargo check' to do the analysis part without actually compiling a binary, it's super fast and excellent for development.
    - civility 8y ago
      > 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.
zachruss92 8y ago
For me I think it comes down to what is the right tool for the job. I have been using Python for years for web scraping & data analysis (via Scrapy and SciPy) and I feel that they are the best tools for what I am doing. Now that a lot of my scraping needs require me to render the DOM, I have had to run a headless web browser (previously PhantomJS/Splash and now Chrome). Chrome released the Puppeteer library which is the most straight forward way to interact with Headless Chrome. This is in Node so that is what i’m using. On my last project we needed to parse through a large amount of HTML files to extract relevant information (about 70,000,000) and put it in a DB for further analyses. I have done similar things in Python before, but there are blocking/concurrency issues that can make it slow and frustrating to build. My solution was to just do this in Go. I can then run my extraction in a goroutine. Go’s selling point for me was speed (relative to Python) and dead simple concurrency - which made it the right tool for the job. Edit: Spelling, iOS’s autocorrect can be so annoying sometimes :)
- justinclift 8y ago
  > parse through a large amount of HTML files to extract relevant information. Any idea if Go has an equivalent to Pythons Beautiful Soup? :) Back when I used to do Python development, Beautiful Soup was awesome for extracting info from possibly-munged HTML. Haven't yet found a good equivalent for Go. :/
  - theshrike79 8y ago
    I haven't found anything that matches Beautiful Soup's ability to parse completely borked HTML. For HTML that's at least mostly valid, I like goquery: https://github.com/PuerkitoBio/goquery https://github.com/PuerkitoBio/goquery
mark_l_watson 8y ago
Thanks for The writeup, I am going through a similar process. I just retired last Friday (I am an old guy) from managing a machine learning team and everything was done in Python. For personal projects (and past consulting work) I have been loving Lisp languages since the 1980s but many languages have so many of the benefits of Lisp (thinking of Haskell and Julia) and there is definitely a ‘lisp tax’ on deploying and shipping products. Anyway, for writing new books, writing open source projects, and perhaps some consulting, I would like to cut back to a single language, instead of the 4 or 5 I use now. EDIT: I did some Go Lang codelabs when I worked at Google and have played with Rust (principally spending some evenings with an open source blockchain project) and neither language will be my home base language.
- dangoor 8y ago
  Congrats on your retirement! And enjoy your opportunity to work with whatever languages you like. The variety of tools available today is so much greater than it was in the 80s.
- pdimitar 8y ago
  If I retired today I'd try really hard to only use Elixir and OCaml. Elixir is perfect for servers and fault-tolerance. Also scales quite well to several tens of machines before needing any special tooling. For a huge percent of most projects today Elixir would be ideal. OCaml I want to use more for its really concise and strict (but extensible) syntax. And mostly for its strong typing and really well-optimized compiled native code. Congratulations on retirement, relax and tinker at your own pace. ^_^
qaq 8y ago
I have reverse experience I've used pretty much everything under the sun, but never really taken Python seriously just had to do a project in Python @ work and it was such a pleasant experience so my current mindset Python + Cython for most projects unless things are really perfomance sensitive than Rust.
sidcool 8y ago
I have a genuine question. One of Rust's biggest plus points is having no GC and the related overhead at runtime. Go, on the other hand does use GC. Then how come so many successful Systems programs (e.g. Kubernetes) are written in Go. Anything I am missing here?
- gbear605 8y ago
  For one, because in many systems situations, having the garbage collector slowdown is okay. Also Kubernetes is probably a bad example since it’s a Google project and Google is of course going to use Go more than most companies would.
  - apta 8y ago
    > Google is of course going to use Go more than most companies would. You'd be surprised.
    - gbear605 8y ago
      I’d expect at least higher usage in products that aren’t a business focus. Kubernetes is a good example of that since Google doesn’t actually use it.
- phkahler 8y ago
  GC is one of those features that divide languages. It isn't a big limitation but it usually precludes hard real time performance. Rust caught the public's attention more recently than go. Both are still in their early days as far as adoption is concerned.
- amelius 8y ago
  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 just want to get work done get turned off by fighting with the typechecker, and choose GoLang instead. And also: GoLang is a very accessible language, that can be mastered in a couple of days.
Kronen 8y ago
Go and Rust as substitutes for python, like really? If it works for you perfect, but this is not serious even for a debate, generally speaking, for the majority of programmers
timvisee 8y ago
I like that you're approaching both Rust and Go, instead of just picking one. Because a _war_ between the two on which is best seems to be quite common.
ratling 8y ago
What a pointless article. It cuts off before... any substance whatsoever. Basically he just wanted to bash python and fanboy rust.
picacho 8y ago
Every time reading someone changing from xxx to Rust feel the need to post this thread, it's really fun indeed. https://www.reddit.com/r/rust/comments/acjcbp/rust_2019_beat_c/ed8ue2p/ https://www.reddit.com/r/rust/comments/acjcbp/rust_2019_beat...
xedrac 8y ago
I'm a long time C++ developer, and recently took a job where I write a lot of Python in a large code base. Initially it seemed great, but I quickly realized how uncomfortable it is to have no safety net up front. The interesting thing is Python eliminates a lot of programming errors you may encounter in C++. But it introduces a whole different set of programming errors you would never see in C++. I don't feel comfortable using Python for any project where the code must be correct. I would use Rust every time for that.
- rujuladanh 8y ago
  Neither Rust nor C++ eliminate logic bugs (and no language can do that). If you are writing code that must work, you should be either formally prove the system (if feasible) or have a huge test suite covering everything.
  - apta 8y ago
    > Neither Rust nor C++ eliminate logic bugs (and no language can do that). While true, it's a big benefit to eliminate classes of known bugs (e.g. memory safe languages eliminate undefined behaviors, and Rust eliminates data races). That allows the programmer to pay attention to other aspects of the code, since there's only so much energy one person can spend.
    - rujuladanh 8y ago
      No. If a system MUST work, then there have to be no bugs at all. Removing a class is useless. You have to remove all bugs. You are talking about systems that SHOULD work, but aren’t required to always work. Typically, safety-critical software is the latter, the rest of software is the former. But the latter are entirely different beasts, and is what we were discussing. By the way, Rust does not eliminate all race conditions; and memory safe languages may still have undefined behavior unrelated to memory (e.g. Rust)
Animats 8y ago
Having used all three of those languages, I've commented on this before. Go is mediocre as a a language, but it has one big edge - if you're doing web backend stuff, the libraries for that are the ones used internally by Google. So they're being executed billions of times per second on Google servers and tend to be well behaved. Python tends to have multiple libraries for basic functions like the database interface, all with different bugs. If you write web backend stuff in Go, it will probably work. Having suffered through the Python 2 to 3 transition, I'm less of a Python fan than I used to be. At some point, they need to stop adding features. Currently, Python is acquiring unchecked "type hints", which look like a terrible idea. Optional typing, sure, but unchecked type hints? If the compiler enforced them, they might be worth something. (And no, running a separate type checking tool is not the answer. Especially since no such tool exists that's production grade and in sync with the language.) Rust has no idea when to stop adding features. Rust started as an imperative language and then morphed into a semi-functional language. Mostly to get a sane error handling model. The borrow checker was a brilliant innovation, though. I used Rust for a while, but quit about two years ago in disgust. I never want to hear "that only compiles in nightly" again.
- tomjakubowski 8y ago
  > Rust has no idea when to stop adding features. > I used Rust for a while, but quit about two years ago in disgust. I never want to hear "that only compiles in nightly" again. I don't understand how you can reconcile these beliefs. They stabilized too many features, but you also want more nightly-only features to be stabilized? It's my experience as a Rust programmer since pre-1.0 that very few libraries require nightly; they tend to be niche things (e.g. Rocket) by authors that prefer to experiment on the bleeding edge of the language over having stability or many users.
  - atombender 8y ago
    I suspect what OP is referring to is the fact that it's just hard to avoid Nightly entirely, even if you don't need the new features. All it takes is that one library you want to use requires Nightly. Since Rust adds features all the time, it's not uncommon for library authors to start using these features before they're in Stable. It's just the nature of a young language with an active community who likes being on the bleeding edge. This also extends to the toolchain; it's not that long ago that RLS and Rustfmt were still Nightly-only, for example. The presence of Nightly alone gives you a choice that usually doesn't exist with other languages. Not too long ago I went down the rabbit hole with some text stream stuff (Unicode is surprisingly poorly supported in places), and ended up with a temporary workaround because the std::io::Chars API wasn't in Stable yet and I just didn't want to deal with Nightly. But it was tempting. With other languages such as Go, the choice generally isn't there, even though you could theoretically download HEAD and go from there.
mlinksva 8y ago
The author's series on learning Rust, not linked in the OP https://blog.liw.fi/learning-rust/ https://blog.liw.fi/learning-rust/ I really enjoy the author's blog, which has been discussed here many times over the years https://hn.algolia.com/?query=liw.fi https://hn.algolia.com/?query=liw.fi
yawaramin 8y ago
Folks may also be interested in a thorough analysis of porting a big Python app (0install) to OCaml, after considering various alternatives like Rust and Haskell: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...
- pdimitar 8y ago
  Thank you for that. I'm very interested in people's stories when migrating to OCaml. Do you have more?
  - yawaramin 8y ago
    That's the biggest one I have :-) but you may also find this interesting: https://www.reddit.com/r/elm/comments/ac7n3e/philip2_an_elmtoreasonml_compiler_paul_biggar/?st=jtqesoe5&sh=be7a539d https://www.reddit.com/r/elm/comments/ac7n3e/philip2_an_elmt...
    - pdimitar 8y ago
      That's actually super interesting. Had no idea there was a way to migrate from Elm to OCaml JS dialects so easily! Thanks.

240 points by edward 8y ago

fxj 8y ago

After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.

danieldk 8y ago
Even if languages have different typing regimes, that does not mean that they can be compared. They are means to an end after all. Outside the language itself, you can also compare ecosystems, available tooling, etc. For his ends, statically-typed languages have benefits over Python: Obnam is about 15000 lines of Python code. That turned out to be too much for me in Python: too often there were bugs that a static, strong type system would have caught.
jMyles 8y ago
At a high level, I agree with what you're saying here - that it's difficult to compare rust or go with python. But I take some issue with your reasoning. > After all python is still an interpreted scripting language. Is it? Or rather, is this even a well-defined category? > interpreted Can't any (OK, almost any) language be either interpreted or compiled? The fact that python is typically run in an interpretive runtime setting doesn't really make it "interpreted" as a language. In fact, since python is nearly always compiled to byte code at runtime, it's arguable just as compiled as it is interpreted. But that's not even the point: there's nothing lingual about python that stops it from being compiled. It can be compared with other languages that are typical run subsequent to a compilation step without being the apple to an orange. > scripting This one speaks to me even less. For python to properly be understood as a "scripting" language, I think you'd have to convince me that the lion's share of community energy is dedicated to a paradigm of running a single module front-to-back as a script. And this is clearly not so.
- pushpop 8y ago
  They have a historic point but you’re right that their description doesn’t make much sense given the modern way language runtimes are designed. A better description would be “high level JIT compiled language”.
- codetrotter 8y ago
  I largely agree with what you said but > there's nothing lingual about python that stops it from being compiled Are you sure? Python is a very dynamic language. Some of the most dynamic parts of python might not be possible to compile fully ahead of time and might need to be JITed, because the behavior of the code will only be possible to determine at runtime.
  - darkr 8y ago
    CPython doesn't have a JIT. It compiles to bytecode, which is then "interpreted" by a stack based VM.
- frou_dh 8y ago
  > Is it? Or rather, is [Scripting Languages] even a well-defined category? We could say that the typical compiled language is used for scripting Unix syscalls :-)
nkozyra 8y ago
I disagree. It's a language, it has symbols, syntax and conventions, it either gets interpreted or it gets compiled. In the broad swath of languages, go and python are more similar than, say, python and Haskell. What makes languages apples and oranges is generally not their compilation method but things that are more approach-centric or radically different syntax (which is why I left Rust out. Its syntax has been the thing that's slowed me down most there)
dcuthbertson 8y ago
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 writing and debugging large programs. The languages are very different. Both are used for small and large programs. The experience in using them is what makes us choose one over the other.
- akjha 8y ago
  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.
  - theshrike79 8y ago
    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.
  - dcuthbertson 8y ago
    Sorry for the late reply. There are a few advantages to go. 1. we don't force our customers to lay down a large Node.js blob just to run our software. 2. The old code was written for an old version of Node.js, v4.x, I believe. As such, it was full of code suffering from callback hell, and a lot of anonymous functions written inline. It was very difficult to reason about when tracking down bugs. I'm sure your Typescript code is far better organized. 3. The edit-compile-test loop is far faster. It takes less than a minute (20-50 seconds) to compile the new codebase, which is a mix of Go and C apps and libraries. The developers use a simple build script to rebuild everything from scratch. The old codebase, a mix of Javascript and C apps and libraries, was built with CMake to manage dependencies. Each rebuild would complete in a few minutes for small changes, but could take about 10 minutes if the "right" code was touched. 4. Like theshrike79, I find Go's concurrency patterns, channels, and goroutines a delight to use. 5. We use json files for configuration. Go has a simple scheme for converting between json and structs. Node.js allowed us to make poorly structured json files. When we converted them to follow some simple nesting patterns of structs within structs, converting between structs in memory and json files was just too easy! It seems that the new codebase is significantly smaller, so it's easier to find where things are implemented. Part of that is getting rid of tech debt and being very familiar with the new code. When we were still in beta, we ran some performance tests. They indicated the new code was as performant as the old node code (which has been worked on for years). We expect to be able to improve on that as we have time. I hope that helps. It's been a major amount of work to rewrite our apps while maintaining the old code base - not something to do on a whim. I know the dev team is delighted with the results. Good luck.
gameswithgo 8y ago
comparing apples and apples would be even less interesting.

kumarvvr 8y ago

At 15000 loc, if the author found it difficult to organize python code, then it's not python's fault. I find it a pleasure to organize code in python. What am I missing here?

jacquesm 8y ago
Exactly. 15Kloc is just out of the 'this stuff is easy' zone and switching to Rust or Go will make that problem larger, not smaller (because you will need more code to achieve the same effect).
- pushpop 8y ago
  It’s not just about code organisation though. Both Rust and Go have fantastic compilers which catch a great many dumb but common user errors before you even get to the stage of testing. Obviously this doesn’t replace the need for functional tests but writing those tests is as much prone to user error as writing the code itself. So having a compiler check for stupidity up front is always going to be a bonus. Also the static type system helps a lot too. Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes effectively have written specifications defined in the code itself which the compiler verifies the rest of your program against. So if you’re accidentally trying to write text to a numeric type, your compiler will catch that. In my experience the extra up front overhead (in terms of development time) of static typed AOT compiled languages end up saving you development time in the long run when working against larger projects.
  - nurettin 8y ago
    Mypy and type hints does catch that.
    - pushpop 8y ago
      Sure. There are additional tooling you can use in Rust and Go to catch a plethora of errors beyond what I described too. However if they require the user run them manually then they’re just as open to user error as the testing I also described. This is why having those checks in the compiler itself can be invaluable.

jacquesm 8y ago

15Kloc and trouble is indicative of other problems than a problem with the language. I wrote multiple 50Kloc and up pieces of software in GFA Basic, arguably a much more limiting and unsafe environment than Python ever was, and yet, that software worked well and was maintainable to the point that its descendants still run 3 decades later. Python has all the bells and whistles you need to build large code bases, but you do need to get organized, no language can really do that for you and attempts at forcing you to do it give rise to 'factory factory' nonsense. I'm no huge fan of Python, I use it when I have to but Rust is from a bells-and-whistles point of view a step down from Python, it is more a better 'C' than a better Python and Go has it's own share of issues that has kept me away from it so far. If you want to crank out some research project or application quickly building on the libraries that others provide (especially in machine learning or other data intensive fields) then Python would be my first choice, and something like 'R' probably my second (though I see 'R' mostly as a data scientist's workbench that has a programming language bolted on).

IshKebab 8y ago
I disagree. 15k lines of code is a lot of code to keep entirely in your head all at once, which is basically what you have to do if you're using a language as dynamic as Python. In static languages like Java you can easily use tools to check types are correct, find usages of variables, jump to definitions and so on. And you get compile time errors if you screw up, rather than runtime errors.
- Bishonen88 8y ago
  Most of the above is due to a proper IDE. Python, too, has one: PyCharm. Comes with 'find usage of variables', 'jump to definition', types checking, syntax correction, import optimization and much much more. 15k with pycharm is a walk in a park \*More than one, of course. But I use only PyCharm :)
  - mateuszf 8y ago
    It depends on the language. The more metaprogramming is used the harder to automatically refactor. While you can do reflection/code generation even in Java, for the non-framework code almost nobody does it. That's why I feel lot safer with large codebases in Java, even though I love some dynamic languages too. I don't think they're as scalable for big programs though.

therealmarv 8y ago

15K LOC in Python. Be prepared to increase your LOCs to at least 33-100% when writing in Rust or Go, hopefully your error rate by line of code will decrease more than your overall LOC. There are not only benefits.

weberc2 8y ago
I’ve written a lot of Python and a lot of Go. The errors per loc are much lower in the latter because code density is much lower and because of the type checker. In other words, if you measured errors by statement or something more meaningful than “line” then it would account for the difference in density, but I would still expect far fewer errors in Go.

julienfr112 8y ago

Line of code is a relative measure. If you leverage package like numpy/pandas, asyncio and co, you could easily write python code that are ten fold shorter than their C/rust/go equivalent. And improving speed when you make a good use of numpy requires quite an amount of time and skills.

sidcool 8y ago

I am personally investing heavily in Rust. I hope to bear some fruit

0815test 8y ago

Not trying to dismiss this person's work in any way, but is there any reason why this blog post should be considered notable? They clearly say at the end that they've yet to write any real-world code in either Rust or Go, and so far have just been learning about either language - so how come that this shoots up to the top of HN? Is it just the magic keywords "Rust" and "Go" that do that?

dpc_pw 8y ago
I am a Rust fanboy, and I can't see anything worthwhile in this article. I joke that any love-story about Rust will get you to a front page of HN. Yeah, Rust is awesome, and many people love it, but it is a bit ridiculous.
- vonseel 8y ago
  I wonder a little about the source of the name "Rust". That seems like an odd choice for a language name - not that it matters. Rust - being associated with old metals - makes me think of something that's been left out and abandoned. Maybe because I'm from a rural part of the country where you see a lot of rusted metal sheds or abandoned structures. Go, on the other hand, makes perfect sense - "let's go!" implies that it is something that is made to get things done and also being the first two letters of Google.
  - steveklabnik 8y ago
    It’s got multiple associations, the “well-worn tool” one is one of them. https://en.m.wikipedia.org/wiki/Rust_(fungus) https://en.m.wikipedia.org/wiki/Rust_(fungus) is another.

yakshaving_jgt 8y ago

I share the author's sentiment, and it's what lead me to Haskell. It's faster and cheaper for me to write prototypes in Haskell than it ever was in Ruby. And at least in startup-world which is the bulk of my career, the speed at which you can build a reasonably robust prototype can be the life or death of a business, and this prototype usually ends up being the production product anyway. Prototypes are seldom rewritten "properly".

mlthoughts2018 8y ago
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 deep, stateful dependency injection to properly test for, type class designs that were set up wrong for some use case last year and now are horribly brittle and unmanageable to try to use it for the new use case that needs customer feedback immediately. Plus, for all the syntactical niceties of Haskell, the code becomes unreadable the instant you start needing a dozen different GHC compiler pragmas all defining weird special behavior or syntax. Yet it’s just basic Haskell 101 these days to require new compiler pragmas for tons of basic functionality that you could get out of the box in other languages. Getting a whole team up to speed on how to mentally keep track of that from one section of code to the next is a very difficult chore. My real life experience with Haskell is why I don’t use it professionally any more.
- yakshaving_jgt 8y ago
  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 such different conclusions despite supposedly having similar experiences 2. The vigour with which you attacked my rather innocuous comment 3. I had a look at some of your previous comments about Haskell, and you seem to repeat the same talking points over and over, almost verbatim. In fact, this comment you made is particularly interesting: > it becomes the same shit code mess as any other paradigm.[0] If what you say is true, then what is your argument exactly? If everything inevitably produces the "same shit code mess", then why are you attacking me for essentially saying "I like Haskell and it is working for me"? [0]: https://news.ycombinator.com/item?id=19400648 https://news.ycombinator.com/item?id=19400648

xyproto 8y ago

The strengths of Go become apparent when working in teams and when deploying, not when reading blogs about the language before trying to write code in it.

lima 8y ago
Exactly this. Rust is quite the opposite of Go in that regard - just like C or C++, it makes it really easy to write over-abstracted and clever code that is hard to understand, audit or review. Rust is also an extremely powerful tool and a ray of hope for systems programming, but comparing it to Go is an apples and oranges comparison.
empath75 8y ago
I’m working in a team of 5 people who has never used go prior to 9 months ago and had no training in it and we’ve just been unbelievably productive in it. We came to it from a combination of python and javascript backgrounds and have no problems collaborating or jumping into each other’s code. To me the main advantage of it is that the small number of primitives and simple syntax forces people to in general be very explicit about what you’re doing. The code almost doesn’t need comments.
- 0815test 8y ago
  > To me the main advantage of it is that the small number of primitives and simple syntax forces people to in general be very explicit about what you’re doing. The code almost doesn’t need comments. That has little to do with 'simple syntax', and more with the language itself (and/or its community) setting clear standards as to what "idiomatic" code in the language should look like. And Rust is fairly good at that, albeit with the inherent limitation of having to support the additional complexity of ownership/lifetime management. (Go can do without this since it uses GC instead. Swift just uses ARC everywhere.)
- apta 8y ago
  Coming from dynamic languages like Python and Javascript, it's not hard to beat those. Compared to something like Java or C#? Yeah, golang trails way behind. That's why you keep seeing such claims, because many people come from a background where they weren't exposed to a strong ecosystem, so any minor improvement seems like a big deal.

LawnboyMax 8y ago

Strongly agree with author. I really like Python and at one point thought that it makes sense to write almost any project in it, since it's so versatile and I know it pretty well. After working on a quite large application and having to use lots of assert(isinstance(arg, type) at the beginning of almost every function, I began to think that a strong type system is very much needed for large projects. I believe this was one of the reasons why Twitter moved from Ruby to Scala. I still love to use Python for hacking something quick for myself. But I also look at some popular strongly-typed languages now and hope to get better at one of them soon.

ris 8y ago
You're confusing static typing with strong typing. Python is strongly-typed, but not statically typed. Python's optional typing could also be used to get rid of a lot of your assertions.
- yawaramin 8y ago
  You are confusing optional typing with optional static typechecking. Python has the latter, not the former. In other words, everything is typed in Python and it will always check types at runtime.
jsjohnst 8y ago
> I began to think that a strong type system You’re confusing static/dynamic and strong/weak. Python is a strongly typed language, but also is dynamicly typed language. Need proof? Try doing this: a = 3 b = “3” c = a + b > having to use lots of assert(isinstance(arg, type)) Python has type hinting now, try using a current version of Python and this isn’t needed.
- flyinglizard 8y ago
  The point is that your example will not break anything until run time, unless some static analysis tools are deployed (which are much more limited compared to what a compiler can achieve).
- 8y ago

toyg 8y ago

> Note that I've not written any significant code in either language, so I'm just writing based on what I've learnt by reading. So he’s basically comparing 20+ years of Python usage with marketing material from Go and Rust. Right. I wish people could be honest with their motivations, instead of making up excuses to justify this sort of change. Here it’s a classic case of “I got bored and I don’t like the new features, want new shiny”, wrapped in a bit of whining about problems that have well-known solutions (use a good IDE, use type hints or one of the many libs that enforce types...). I have no problem with that, just don’t try to sell it to me on technical grounds, because it looks very much like you have none. Python is still one of the best ways to get stuff done, quickly and with a minimum of boilerplate. Its limitations are well-known and have not really increased for about 15 years - if anything they have shrunk in many, many areas. Adoption rates keep exploding, despite a lot of doom forecasted by some alpha geeks about 10 years ago: “There is no mobile story! We will all be using Ruby/Go/NodeJS tomorrow! Nobody will ever go to Py3!” Etc etc etc. You got bored by it? That’s fine, it happens, no harm done. But you don’t need to convince anyone, including yourself, that you’re moving on because of this or that flimsy excuse.

0815test 8y ago
> Here it’s a classic case of “I got bored and I don’t like the new features, want new shiny”, wrapped in a bit of whining This seems to be a rather shallow reading of the blogpost, and the way you phrased your reaction is not exactly polite either. If anything, the "adoption rates" of Python (like those of ECMAscript, a language of a similar vintage all-things-considered) are most easily explained by non-technical factors, so I have quite a bit of trouble making sense of your comment.
- Annatar 8y ago
  There was absolutely nothing impolite in the way he phrased his response. Rather, what I'm responding to is passive-aggressive.
pagefault123 8y ago
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.

lordnacho 8y ago

I'm going to have a go with Rust and Go too, but for different reasons. IMO Python is still the best language to go with when you are writing anything "scripty": - Stuff that's not expected to be long. Do one thing well, let some other program do another, compose the higher order functions from functions that work. Of course this isn't always possible. - Stuff where the types are not going to confuse you. Often you just have a few types, and it's fairly obvious what you can do with a given object. If you get too many types, there's a good chance it will start to get confusing and then strong typing would help. - Stuff where performance is not a problem. Don't write your HFT system in Python. You simulation though, might benefit from orchestration of some VMs. The ultimate use case for Python is glue code. And guess what, a lot of code is just glue. A good glue language has a large ecosystem of libs, and some language features that make it easy to read. That's Python in a nutshell: whitespace formatting makes things easy to read, and you get built in list/dict syntax to keep everything short and sweet. For me Rust and Go are interesting having come from C++. There's a lot of pitfalls in C++ that might be helped with Rust. At the moment I have a whole load of Valgrind suite tests that look for potential problems. Perhaps Rust can bake those into the language? I haven't had time to look at it yet. Go seems to be interesting as a compromise between easy and fast, and by the sound of it things have turned out well. I have people on my team using it, and it seems to be the thing to do for web services that need to be faster than nodejs but you don't want to spend a load of time making sure a c++ version is correct.

NateDad 8y ago
C++ versions are never correct
Annatar 8y ago
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).
- tannhaeuser 8y ago
  You probably mean the POSIX shell [1] ;) I never understood why folks venture into bashisms for no or little gain (bash isn't even the default shell on Debian/Devuan), or would invent/use entire new languages with singleton implementations such as Perl in the 1990s or Python in the 2000s (other than for fun, of course). Note that Python is actually a descendant of the ABC programming language developed to be human-friendly, not a shell replacement language per se. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

buro9 8y ago

I'm currently migrating a similarly sized Python and Django application to Go but for different reasons. For me it's bit rot. My Python is approaching EOL on this version and needs upgrading to Python 3, and I have a lot of 3rd party code in here that made things simpler to create but over time they've changed enough or disappeared that I now have to take on work there too. Then Django and it's internals have changed a lot in the last 6 years. My Go code written at the same time (6+ years ago) hasn't had any of it's libraries change so much that I've needed to do anything. Every now and then I pull the next major version of Go and recompile and it's done. This is all side project stuff but a lot of people use it (monthly average visitors being +250k)... it's non-profit and I don't wish to have to maintain it much. It worked once, if nothing has changed in the functionality it should keep working... but this isn't as true in non-compiled languages where you need to depend on so much of the environment, let alone build culture that doesn't fully vendor dependencies. I like Python, but prefer to write code and move forward with other projects. As to Rust vs Go. I code in both and only picked Go here because a lot of the code in another project I worked on can be used here. I'd probably try Rust if I was starting from scratch now. But I'd be a little concerned bit rot would affect Rust too, it's still quite early for the wider ecosystem.

ris 8y ago
What you're actually saying here is "Using Go I'm going to leave the application with unmaintained versions of its libraries", which is a bit of an alarm-bells statement from a security point of view. It's perfectly possible to build a python application that is extremely reliably tied to its dependencies, you just have to avoid the default python package "management" solutions that get shoved down everyone's throat (pip, virtualenv, pipfile, tox and the like). I've been building python projects on top of Nix for years and have managed to maintain stable and reliable results.
- empath75 8y ago
  “It’s easy to do it if you build your own dependency management system” doesn’t sound like it’s easy to do it.

ChrisSD 8y ago

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.

empath75 8y ago
They’re different use-cases but they’re both modern statically typed languages that are ergonomically nice compared to previous alternatives in their spaces.
theshrike79 8y ago
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.
- ChrisSD 8y ago
  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.
  - apta 8y ago
    Because when golang first came out, it was hyped as a "systems language", and meant to compete with C++. Most people use that term to refer to languages you use to write kernel level software. Of course, contrary to the golang author's wishes, golang ended up being a competitor to python/nodejs/etc. but it's still the case that the marketing hype from when the language first came out affects what people talk about, even if they don't know the context of why that discussion came about in the first place. Rust on the other hand, is a (somewhat) viable C++ replacement, as can be seen in the projects that get implemented in it (e.g. Rust made its way into the Firefox browser, as well as other low level and speed critical networking projects at different companies).

_ZeD_ 8y ago

try java. no, seriously. java and a good IDE (netbeans or eclipse, not some editors like vscode) are a godsend to handle "bigger" project. It's absolutely fast to compile and insanely on-the-fly static checks all over the place.

siteshwar 8y ago

> Rust is developed by a community, and was started by Mozilla. Go development seems to be de facto controlled by Google, who originated the language. I'd rather bet my non-work future on a language that isn't controlled by a huge corporation, especially one of the main players in today's surveillance economy. Anyone else agree with this view ? Programming languages should be choosen based on technical merits, rather than who is behind it. Is there a lesson from history that I am missing ?

russtrotter 8y ago
I'd say, all things being equal, yes, choose languages on tech merit or suitability to task. But look at what's happening with Java and Oracle's handling of it. I think the Google vs Oracle lawsuit is still going through appeal. Ask Google if they wish in hindsight they'd built Android on something else.
- stingraycharles 8y ago
  Not saying you’re wrong, but Google re-implemented Java for Android, which is quite different from using Java alone. So it’s not a completely fair comparison.
  - gbear605 8y ago
    Of course the reimplementation is what got them into this lawsuit...
    - phkahler 8y ago
      I think it's more accurate to say that not paying Oracle is what got them in court. Either way it shows that the steward of a language can be important.
- apta 8y ago
  > But look at what's happening with Java and Oracle's handling of it. It got fully open sourced?

Annatar 8y ago

"Partly it's because I'd like more help from my programming tools, such as static type checking, better handling of abstractions" As soon as I read that, I know immediately that I'm dealing with an object-oriented programmer. Always the same gripes, always the same problems! Your programming paradigm is busted and no language will ever be able to change that, no matter what lexicography and grammar it implements! There is a reason why procedural or functional programmers don't complain about those types of issues!

coleifer 8y ago

So a typically unimaginative python programmer sees new Kool aid and is thinking about taking a drink. Decides to write blog post about it. And somehow it's #1 on hn.

weberc2 8y ago
What’s your specific complaint? That someone is picking up other languages? That they are writing about them? I use Python as my primary language too, but I don’t see anything objectionable about these things...
dang 8y ago
Please don't break the site guidelines, regardless of how wrong you feel someone else is. We've had to ask you this multiple times before. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- coleifer 8y ago
  Which one did you feel I had broken? This post was just meme-filled gas.
  - dang 8y ago
    You broke the guidelines about name-calling, flamebait, and snark. HN users need to follow those regardless of how bad an article is or they feel it is.

coleifer 8y ago

Dude wants a compiler and wants to go fast. And he picks rust? Guys been hanging out way too long on hackernews.

Annatar 8y ago
Could not have put it better myself. If he wants fast, short of hand writing in assembler, CUDA Fortran is the way to go. Too much exposure to "Hacker" "News".
tomrod 8y ago
Why not Rust? I am in a similar situation to the author. Python handles most of what I need, but that last 20% I need more.
- 0815test 8y ago
  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 portability, not so much performance.)
  - AsyncAwait 8y ago
    > The Rust compiler is well known for having rather less-than-stellar performance. You can do 'cargo check' to do the analysis part without actually compiling a binary, it's super fast and excellent for development.
  - civility 8y ago
    > 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.

zachruss92 8y ago

For me I think it comes down to what is the right tool for the job. I have been using Python for years for web scraping & data analysis (via Scrapy and SciPy) and I feel that they are the best tools for what I am doing. Now that a lot of my scraping needs require me to render the DOM, I have had to run a headless web browser (previously PhantomJS/Splash and now Chrome). Chrome released the Puppeteer library which is the most straight forward way to interact with Headless Chrome. This is in Node so that is what i’m using. On my last project we needed to parse through a large amount of HTML files to extract relevant information (about 70,000,000) and put it in a DB for further analyses. I have done similar things in Python before, but there are blocking/concurrency issues that can make it slow and frustrating to build. My solution was to just do this in Go. I can then run my extraction in a goroutine. Go’s selling point for me was speed (relative to Python) and dead simple concurrency - which made it the right tool for the job. Edit: Spelling, iOS’s autocorrect can be so annoying sometimes :)

justinclift 8y ago
> parse through a large amount of HTML files to extract relevant information. Any idea if Go has an equivalent to Pythons Beautiful Soup? :) Back when I used to do Python development, Beautiful Soup was awesome for extracting info from possibly-munged HTML. Haven't yet found a good equivalent for Go. :/
- theshrike79 8y ago
  I haven't found anything that matches Beautiful Soup's ability to parse completely borked HTML. For HTML that's at least mostly valid, I like goquery: https://github.com/PuerkitoBio/goquery https://github.com/PuerkitoBio/goquery

mark_l_watson 8y ago

Thanks for The writeup, I am going through a similar process. I just retired last Friday (I am an old guy) from managing a machine learning team and everything was done in Python. For personal projects (and past consulting work) I have been loving Lisp languages since the 1980s but many languages have so many of the benefits of Lisp (thinking of Haskell and Julia) and there is definitely a ‘lisp tax’ on deploying and shipping products. Anyway, for writing new books, writing open source projects, and perhaps some consulting, I would like to cut back to a single language, instead of the 4 or 5 I use now. EDIT: I did some Go Lang codelabs when I worked at Google and have played with Rust (principally spending some evenings with an open source blockchain project) and neither language will be my home base language.

dangoor 8y ago
Congrats on your retirement! And enjoy your opportunity to work with whatever languages you like. The variety of tools available today is so much greater than it was in the 80s.
pdimitar 8y ago
If I retired today I'd try really hard to only use Elixir and OCaml. Elixir is perfect for servers and fault-tolerance. Also scales quite well to several tens of machines before needing any special tooling. For a huge percent of most projects today Elixir would be ideal. OCaml I want to use more for its really concise and strict (but extensible) syntax. And mostly for its strong typing and really well-optimized compiled native code. Congratulations on retirement, relax and tinker at your own pace. ^_^

qaq 8y ago

I have reverse experience I've used pretty much everything under the sun, but never really taken Python seriously just had to do a project in Python @ work and it was such a pleasant experience so my current mindset Python + Cython for most projects unless things are really perfomance sensitive than Rust.

sidcool 8y ago

I have a genuine question. One of Rust's biggest plus points is having no GC and the related overhead at runtime. Go, on the other hand does use GC. Then how come so many successful Systems programs (e.g. Kubernetes) are written in Go. Anything I am missing here?

gbear605 8y ago
For one, because in many systems situations, having the garbage collector slowdown is okay. Also Kubernetes is probably a bad example since it’s a Google project and Google is of course going to use Go more than most companies would.
- apta 8y ago
  > Google is of course going to use Go more than most companies would. You'd be surprised.
  - gbear605 8y ago
    I’d expect at least higher usage in products that aren’t a business focus. Kubernetes is a good example of that since Google doesn’t actually use it.
phkahler 8y ago
GC is one of those features that divide languages. It isn't a big limitation but it usually precludes hard real time performance. Rust caught the public's attention more recently than go. Both are still in their early days as far as adoption is concerned.
amelius 8y ago
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 just want to get work done get turned off by fighting with the typechecker, and choose GoLang instead. And also: GoLang is a very accessible language, that can be mastered in a couple of days.

Kronen 8y ago

Go and Rust as substitutes for python, like really? If it works for you perfect, but this is not serious even for a debate, generally speaking, for the majority of programmers

timvisee 8y ago

I like that you're approaching both Rust and Go, instead of just picking one. Because a _war_ between the two on which is best seems to be quite common.

ratling 8y ago

What a pointless article. It cuts off before... any substance whatsoever. Basically he just wanted to bash python and fanboy rust.

picacho 8y ago

Every time reading someone changing from xxx to Rust feel the need to post this thread, it's really fun indeed. https://www.reddit.com/r/rust/comments/acjcbp/rust_2019_beat_c/ed8ue2p/ https://www.reddit.com/r/rust/comments/acjcbp/rust_2019_beat...

xedrac 8y ago

I'm a long time C++ developer, and recently took a job where I write a lot of Python in a large code base. Initially it seemed great, but I quickly realized how uncomfortable it is to have no safety net up front. The interesting thing is Python eliminates a lot of programming errors you may encounter in C++. But it introduces a whole different set of programming errors you would never see in C++. I don't feel comfortable using Python for any project where the code must be correct. I would use Rust every time for that.

rujuladanh 8y ago
Neither Rust nor C++ eliminate logic bugs (and no language can do that). If you are writing code that must work, you should be either formally prove the system (if feasible) or have a huge test suite covering everything.
- apta 8y ago
  > Neither Rust nor C++ eliminate logic bugs (and no language can do that). While true, it's a big benefit to eliminate classes of known bugs (e.g. memory safe languages eliminate undefined behaviors, and Rust eliminates data races). That allows the programmer to pay attention to other aspects of the code, since there's only so much energy one person can spend.
  - rujuladanh 8y ago
    No. If a system MUST work, then there have to be no bugs at all. Removing a class is useless. You have to remove all bugs. You are talking about systems that SHOULD work, but aren’t required to always work. Typically, safety-critical software is the latter, the rest of software is the former. But the latter are entirely different beasts, and is what we were discussing. By the way, Rust does not eliminate all race conditions; and memory safe languages may still have undefined behavior unrelated to memory (e.g. Rust)

Animats 8y ago

Having used all three of those languages, I've commented on this before. Go is mediocre as a a language, but it has one big edge - if you're doing web backend stuff, the libraries for that are the ones used internally by Google. So they're being executed billions of times per second on Google servers and tend to be well behaved. Python tends to have multiple libraries for basic functions like the database interface, all with different bugs. If you write web backend stuff in Go, it will probably work. Having suffered through the Python 2 to 3 transition, I'm less of a Python fan than I used to be. At some point, they need to stop adding features. Currently, Python is acquiring unchecked "type hints", which look like a terrible idea. Optional typing, sure, but unchecked type hints? If the compiler enforced them, they might be worth something. (And no, running a separate type checking tool is not the answer. Especially since no such tool exists that's production grade and in sync with the language.) Rust has no idea when to stop adding features. Rust started as an imperative language and then morphed into a semi-functional language. Mostly to get a sane error handling model. The borrow checker was a brilliant innovation, though. I used Rust for a while, but quit about two years ago in disgust. I never want to hear "that only compiles in nightly" again.

tomjakubowski 8y ago
> Rust has no idea when to stop adding features. > I used Rust for a while, but quit about two years ago in disgust. I never want to hear "that only compiles in nightly" again. I don't understand how you can reconcile these beliefs. They stabilized too many features, but you also want more nightly-only features to be stabilized? It's my experience as a Rust programmer since pre-1.0 that very few libraries require nightly; they tend to be niche things (e.g. Rocket) by authors that prefer to experiment on the bleeding edge of the language over having stability or many users.
- atombender 8y ago
  I suspect what OP is referring to is the fact that it's just hard to avoid Nightly entirely, even if you don't need the new features. All it takes is that one library you want to use requires Nightly. Since Rust adds features all the time, it's not uncommon for library authors to start using these features before they're in Stable. It's just the nature of a young language with an active community who likes being on the bleeding edge. This also extends to the toolchain; it's not that long ago that RLS and Rustfmt were still Nightly-only, for example. The presence of Nightly alone gives you a choice that usually doesn't exist with other languages. Not too long ago I went down the rabbit hole with some text stream stuff (Unicode is surprisingly poorly supported in places), and ended up with a temporary workaround because the std::io::Chars API wasn't in Stable yet and I just didn't want to deal with Nightly. But it was tempting. With other languages such as Go, the choice generally isn't there, even though you could theoretically download HEAD and go from there.

mlinksva 8y ago

The author's series on learning Rust, not linked in the OP https://blog.liw.fi/learning-rust/ https://blog.liw.fi/learning-rust/ I really enjoy the author's blog, which has been discussed here many times over the years https://hn.algolia.com/?query=liw.fi https://hn.algolia.com/?query=liw.fi

yawaramin 8y ago

Folks may also be interested in a thorough analysis of porting a big Python app (0install) to OCaml, after considering various alternatives like Rust and Haskell: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

pdimitar 8y ago
Thank you for that. I'm very interested in people's stories when migrating to OCaml. Do you have more?
- yawaramin 8y ago
  That's the biggest one I have :-) but you may also find this interesting: https://www.reddit.com/r/elm/comments/ac7n3e/philip2_an_elmtoreasonml_compiler_paul_biggar/?st=jtqesoe5&sh=be7a539d https://www.reddit.com/r/elm/comments/ac7n3e/philip2_an_elmt...
  - pdimitar 8y ago
    That's actually super interesting. Had no idea there was a way to migrate from Elm to OCaml JS dialects so easily! Thanks.