Live data from Hacker News

On Learning Rust and Go: Migrating Away from Python

blog.liw.fi

301–310 of 346 posts

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

#301
post #8

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 y…

> 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 This is almost satirical. > Assembler 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…

This is almost satirical.

I didn't read it that way - but your retort reads as quite definitely snarky.

Either way -- could you condescend to explain to us what was so outright ludicrous in the sentence you quoted?

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

#302
post #26

Earlier quoted context omitted.

Mypy and type hints does catch that.

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.

usually integrated into pycharm or vs code so you get the warnings and errors as you type/save

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

#303
post #46

Earlier quoted context omitted.

You’re flip flopping all over the place with your descriptions of tests. Broadly speaking, There are two types of tests being discussed here. Those are positive tests and negative tests. Positive being that the code does what you expect under normal operation. Those you’d obviously need in any language Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. If…

Those are a only a subset of the possible negative tests, and the ones you shouldn't be writing (if you do, simply switch to another language).

> Those are a only a subset of the possible negative tests

I agree. I said this too

> and the ones you shouldn't be writing (if you do, simply switch to another language).

That was my point

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

#304
post #254

Earlier quoted context omitted.

Or almost any advertisement tracker server.

Isn't that market dominated by a few, or at the max, no more than 10-15 companies? My point is just that are there really more than a few dozen or maybe a hundred companies that see more than 1000 req/sec (on web apps)?

Depends if you're talking maximum or average. Getting to the front page of HN could easily give you a burst of 1000 req/sec. I would agree there's very few CRUD apps that deal with 1000 req/sec on average.

On the other hands, there's various APIs and tracking type of services that probably do handle well in excess of that, being run by not-large companies none of us have ever heard of.

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

#305

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,…

>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.

What does "production grade" mean w/r/t such a tool?

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

#306
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

Google has no business writing a programming guide for something they aren't competent for; the guy who wrote this is about as clueless as they come when it comes to shell programming, for example he thinks using eval should be forbidden for security reasons. And it's a guide by some company, not gospel.

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

#307
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).

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-fr…

No, I don't "probably" mean POSIX, if I write Bourne and Korn shell, then that is what I mean! I grew up on real UNIX operating systems, not the GNU/Linux cheap knockoff! Boy do statements like these make me furious!

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

#308
post #101
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).

Because shell scripts usually have lots of dependencies on external tools, it's harder to make them portable. Those external utilities have different behavior on different platforms. I have much better luck with Python, Perl, etc, for scripts.

Shell scripts depend on what is in /sbin and /usr/bin, so software which comes with the OS. If you are struggling with that, then I warmly recommend the "Learning the UNIX operating system" book from O'Reilly to get the basics down. Your argument makes no sense.

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

#309
post #301

Earlier quoted context omitted.

> 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 This is almost satirical. > Assembler 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…

This is almost satirical. I didn't read it that way - but your retort reads as quite definitely snarky. Either way -- could you condescend to explain to us what was so outright ludicrous in the sentence you quoted?

Hey there. Imo you are far more condescending than I ever was, it is possible though that you missed the point. Let me explain.

The parent I was replying to said this:

> 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 have a problem with this statement which I hoped to convey by satire (but obviously failed).

The argument being put forth by OP is that python's lack of static compile time typing makes it hard to build large code bases. This is a legitimate argument supported by several whitepaper research papers conducted by well known and trusted entities. The parent I replied to countered this with "but you do need to get organized", but neglected to specify any details about the said organization.

Obviously I have a problem with this because the statement is utterly meaningless.

You can make this type of statement about literally every language. I picked assembler to demonstrate this point. Also, it is low effort jab against Java programmers, as if they are clueless about organization.

> Assembler 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.

That statement is equally applies here. Assembler obviously has all the bells and whistles you need to build a large code base, given that it's turing complete and that people have in fact built large code bases with it.

So in summary, the parent I was responding to:

1. Made a vague statement that can be applied to any language.

2. Made a low effort snarky remark about Java developers without providing any support/proof.

3. Said you need to get organized in order to write large code bases in python, provided no further details on the organization.

4. Contained no useful information at all that can actually be applied and used to write software in python or any other language.

5. Tried to counter a legitimate, research supported position with a vague meaningless statement.

I think given all that the satire was warranted.

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

#310
post #284

Earlier quoted context omitted.

Wow. It's amazing the lengths people go to to maintain their delusions. Show me one python IDE in action doing effective refactoring across a large, nontrivial python code base. And you didn't even mention concurrency and skipped over it altogether! > use type hints or one of the many libs that enforce types... As if that's pythonic. Heard of duck typing? And those are things you have to do yourself, as additional wo…

You crossed into personal attack here, and incivility elsewhere in this thread. That's not ok on HN. Would you please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here from now on, regardless of how wrong someone is, or you feel they are?

> You crossed into personal attack here, and incivility elsewhere in this thread.

I disagree with your classifications, and will not be making any adjustments to my behavior/posting habits, thank you very much =)

Post reply on HN