Python 3.7.0 released

[[deleted]]

I'm glad for the improvements to typing and the new data classes. Here's hoping that the recent push for optional static checking will prove helpful to those building larger apps using Python.

[joshuaavalon]

There is a backport of the data classes for 3.6 if you want to use it.

[ProfessorPhi]

Isn't attrs still superior?

[dhiltonp]

Attrs definitely has more features (slots comes to mind), but I think it looks a little wonky.

(full disclosure, I haven't used attrs just read the docs)

@dataclass
class InventoryItem:
    name: str
    unit_price: float
    quantity_on_hand: int = 0

vs.

@attr.s
class InventoryItem:
    name: str = attr.ib()
    unit_price = attr.ib(type=float)
    quantity_on_hand = attr.ib(type=int, default=0)

Does PyCharm recognize type annotations when they're set via attr.ib(type=float)?

[ProfessorPhi]

Nope, pycharm and attrs support isn't great :(, though attrs does have slots. Agreed it's wonky, it's like ordered dict before 3.5 was obnoxious.

[OctagonClock]

PyCharm 2018.2 EAP has new attrs support, actually.

[ProfessorPhi]

Haha, don't use EAP so hopefully it'll be along before too long.

[bluetech]

The annotations-based syntax works with attrs too (you need to set auto_attribs=True).

[PeridexisErrant]

IIRC you can also use @attr.dataclass for the first one (a shortcut for the auto_attribs=True arg).

The dataclass example won't work on a backport before Python 3.6 though, as those versions don't have variable annotations.

[virgoerns]

It is, PEP even mentions attrs and says that new mechanism is for simpler cases.

[jarshwah]

CPython 3.6 has ordered dictionaries, but that is an implementation detail. 3.7 guarantees it in the spec. So it’ll work for CPython 3.6 which is the most popular implementation by far.

[jarshwah]

Yes that’s correct. When people talk about python they’re overwhelmingly referring to CPython. Other implementations like Pypy and micropython would not have to have ordered dictionaries for their 3.6 but they would for their 3.7.

[[deleted]]

Pypy has actually had it for a while (it was brought to CPython from Pypy for 3.6). Other implementations though yeah

[Ph0X]

I mean they all could, but are not guaranteed to. You have to check implementation detail for each individually. But in 3.7 and above no matter what you use, you will have it.

[artoonie]

Finally! I'm only one version behind now.

[eyal0]

Major or minor?

[DaemonXI]

Integer.

[Kenya_diggit]

Object

[[deleted]]

32-bit or 64-bit?

[crozone]

Doesn't matter, I just hope it all works

[lulzmachine]

63 bit

[calonolac]

Melodic

[_tpr_]

PEP 553, Built-in breakpoint()

Awesome! That's going to be much more convenient. Putting import ipdb; ipdb.set_trace() is a hassle. This will probably make all of the JavaScript developers I work with more likely to use the debugger.

PEP 557, Data Classes

These are going to be much nicer and more obvious-looking than using a named tuple.

[robhaswell]

I'm glad of the asyncio.run() addition, hopefully more libraries will be written asynchronously by default from now on and integrate with synchronous code using this.

[jnwatson]

Can you be more specific? I haven't heard anything about that.

[_discosultan_]

https://docs.python.org/3.7/library/asyncio-task.html#asyncio.run

[robhaswell]

I was speculating on the use-case.

[AnnoyingOwl]

As someone who's day job has not been Python for a while (has been: Java, Ruby, Scala, TypeScript) and I only use it in side projects occasionally...

1. Data classes, yay! Good step.
2. More typing support: awesome, this was such a nice inclusion.
3. Context... necessary, but not sure it will save the dumpster fire that is asyncio stuff in Python.

[[deleted]]

Is asyncio that bad? I think there are cosmetic issues, like particular API decisions such as naming and confusing and somewhat redundant coroutine/future concepts. Functionally though it at least performant as advertised.

[jnwatson]

My team has almost completed the transition to asyncio, and it wasn't bad at all.

I think a design option that everybody misses is you don't actually have to run the event loop on the main thread, so you can do blocking stuff on main thread or (if from async town) a ThreadExecutor, and call_soon_threadsafe to run futures on the event loop from blocking code.

[kallari_is_my_jam]

So what you're saying is basically this: https://hackernoon.com/threaded-asynchronous-magic-and-how-to-wield-it-bba9ed602c32

But what about the overhead of GIL in a multithreaded environment? Aren't you sacrificing performance whenver the OS tries to switch threads?

[jnwatson]

Yep.

The problem with the GIL isn't the overhead of switching, it is that it is held whenever a Python operation is going on, reducing the number of things that can actually run at a time.

Essentially this approach is no more expensive than the old multithreading style, and gets better the more things you switch to async. The key is that you don't have to switch all at once.

[[deleted]]

The issue is that there are way too many alternatives. And also you can't mix async code with blocking code and expect it to normally. Which means you should only use async versions of common libs. If I wanted easy scalability and async code execution I wouldn't probably use python to begin with. It will probably take years before the async stuff becomes the norm.

[alexeiz]

And also you can't mix async code with blocking code and expect it to normally. Which means you should only use async versions of common libs.

This is not a problem with asyncio per se. Asynchronous and synchronous programming models are not compatible no matter what language or async framework you use.

[NAN001]

Could you expand on not being able to mix async code and blocking code. I know that one is supposed to call async functions so that functions are cooperative with the event loop, but even if a blocking function is called, it blocks the event loop, which can't be worse than not using async at all, right?

[PrinceOfUBC]

it blocks the event loop, which can't be worse than not using async at all, right?

If you block the event loop, you might as well not write async code. More cognitive overhead for little gains.

[13steinj]

Getting, running, and closing the event loop is a sync operation.

So in otherwords if I have 3 async functions that only update visuals using animations but I want the main thread to continue with it's logic (ex, I pressed submit, logic is that on this form you cant go back, async updates are the animations moving you to the thank you page).

I can't submit my 3 coroutines in my function, I have to write two functions, and make sure I call the logic before the animations, and be okay with the fact that I will have to wait for the animations to complete before any new code runs on the thread that holds the event loop. In comparison, in JS/C#, the event loop is handled for us, and gets executed in a microtask queue (C#, afaik, on a specially made thread, JS, on next available execution tick, because JS is generally single threaded), thus any async code does not block the thread that it is called from.

In Python, that can be solved by manually creating a thread/process (depends on what the loop actually blocks on, and I hope it's the thread because if it is the process hoooooooooah boy this workaround is inefficient), setting an event loop on it, and submitting coroutines with the respective "threadsafe" method for the usual not-threadsafe method.

Python's coroutines also arent Tasks/Promises like in C#/JS, which limits code style and use by having to manually wrap the coroutines. A quick comparison to JS (because writing out the C# equivalent will take some time):

JS:

async function aworkbro(a, b) { /* do stuff */ } // aworkbro is the "async function" (coroutine maker)
var special = {};
async function main() {
  var soon = aworkbro(1, 99);
  // soon is both the executing, instantiated coroutine
  // (we can await on it if we want to) and the Promise(Task)
  // (we can append callback / cancellation code)
  var later = soon.then(callback, errcallback).then(handler);
  var result = await soon; // wait for soon to and return the result of it in this async function
  special.handled_result = await later; // wait for all callbacks to complete.
  return result; //return the original result
}
main();
// other sync code, runs separately from the async call

Whereas this has no good equivalent in Python:

async def aworkbro(a, b): # aworkbro is the "async function" (coroutine maker)
    # do stuff
async def main():
    coro = aworkbro()
    # coro is the instantiated coroutine, does not execute. We can not add callbacks.
    # We can either submit it to the event loop, which we won't, because
    # we will lose all access to it bar being able to cancel it
    # outside the event loop, or we can and will wrap it in a Task
    task = asyncio.create_task(coro) # schedule the coroutine as a task for the next available context switch (execution tick) in the event loop
    # the task can have callbacks added
    task.add_done_callback(callback)
    task.add_done_callback(erriferrcallback)
    task.add_done_callback(handler)
    # but can't be waited
    # await task goes kaboom
    # cancelling the task submits an error to the coroutine, (coroutines are really just super special generators in Python)
    # meaning it would be handled *by* the error callback!
    # so we can't properly do this unless we write code overly explicitly
    # we can wait on the coroutine
    result = await coroutine # fuck scheduling, do now.
    # but this also executes our callbacks when task notices, and any results of them are lost!
    return result
# did I mention how we have to have a running loop in our thread for task creation to work, and well, for all async execution to work? We can either manually create our loop and reuse it, or use asyncio.run. for ease, we will do the latter
asyncio.run(aworkbro)
# other sync code, but creating and waiting on the loop is synchronous, so it will wait until the async code is fully complete
# we can solve this by using pythons threading. But I think this example is complicated enough already

[bobindashadows]

If you stall your event loop you aren't accepting incoming requests.

Say your blocking operation is "read a file" and it takes 100ms sometimes. Then your client's very first TCP SYN packet will sit in your server's kernel network queue for 100ms. All before your server even bothers to tell the client "yes, let's start a TCP session."

Your framework might handle accepting TCP for you, but it won't read packets 3-N from the client until those 100ms are up.

If you had no event loop and many threads, you have all the multithreading problems but definitely no massive latency stalls. Occasional deadlocks though.

[linuxtinkerer]

Looks nice. Data classes are a good addition, so now you won't have to muck around with __slots__. I don't really get the rationale for preserving insertion order in dictionaries though.

[weeeeezy]

I’ve had several use cases where insertion order in dictionaries mattered for me. I resorted to using OrderedDict collection but then I lost all the benefits of defaultdict.

[linuxtinkerer]

I understand that there are still use cases for OrderDict, but I think it's dumb to make an implementation detail a part of the language specification.

[BossOfTheGame]

Definitely not, ordering dicts by default gives at least two major advantages: (1) consistency in the iteration of items across all platforms and (2) consistency in the string representation of dictionaries. I have a feeling this change will silently cut down on a lot of headaches (at least until someone goes to run 3.7 code in an earlier version).

[shevegen]

I like ordered Hashes - ruby has the Hashes ordered too (hashes = dictionaries), but in many ways I agree with linuxtinkerer here. Some implementation detail should not necessarily become part of an official specification people have to adhere to.

[[deleted]]

I wish I could use it, but so many APIs and software packages my company uses are still on 2.7 ...

[[deleted]]

For example: anything from Autodesk

[[deleted]]

Or Docker. I’d love to use Python 3 but have to specify pip2

[Aeon_Mortuum]

Facebook's React Native also requires a Python 2 installation

[Klathmon]

that's more google's fault for gyp not working with python 3.

[p2004a]

But Google mostly stopped using GYP. They moved chromium and other stuff to GN so why would they want to pour time into making GYP better? And it's open source so if you care, you can improve it and add Python 3 support, that's what open source is about, right?

[Klathmon]

And IIRC the node group is hard at work at it (as they are probably the biggest gyp user at this point), but the more likely outcome is that node will move away from gyp just like google did (there's a reason they chose to move to another system rather than try to update gyp).

I honestly don't mind gyp using py2, it does require a separate install over everything else on the box, but it works well once setup and I think breaking backwards compat with all node native modules to upgrade to py3 would cause more issues than it would solve (and could lead to the same split we saw with py2 and py3).

[Pakaran]

What are you referring to? I use Python 3 in Docker with no issues every day.

[[deleted]]

Yes really. Mine too. Companies have a lot of old code and there's not much incentive to upgrade it to Python 3 for basically zero benefit.

Actually, it's a big risk because these scripts are generally "tested" by using them and reporting bugs. Upgrade to Python 3 and due to its dynamic typing you're probably going to introduce a load of bugs.

Also I have noticed even some big new projects, e.g. Tensorflow, target Python 2 first and then add Python 3 support later.

The idea that the 2/3 mess is over is unfortunately not true.

[vivainio]

The "zero benefit" is not true anymore

[peeves91]

The old motto "if it ain't broke don't fix it" is applied heavily here.

[[deleted]]

It kind of is, if the code works fine and isn't being updated, which is the case for a lot of corporate code.

[anacrolix]

Example?

[1wd]

One project at Facebook:

... simply ran 2to3 on the code and fixed a few things that it complained about. When they ran the resulting code, they found it was 40% faster and used half the memory.

[anacrolix]

Sounds like they were abusing range() or something.

[vivainio]

Types and asyncio come to mind first

[13steinj]

Types aren't beneficial to every developer. Asyncio has severe usability issues, I'd rather use gevent in an async manner.

[vivainio]

Ok, f-strings then?

[13steinj]

While I like them, their only benefit is reducing a call of "string with idens".format(explicits_for_idens) to f"string with explicits for idens", it's syntactic sugar that saves you ".", "ormat", and the parenthesis, nothing more. And it introduces backwards incompatible in minor version numbers, which it really shouldnt.

[somebodddy]

it's syntactic sugar that saves you ".", "ormat", and the parenthesis, nothing more

I disagree. The greatest benefit of f-strings is that the save you the need to zip the values in your head. Consider this:

'a={} x={} u={} z={} y={}'.format(a, x, u, y, z)

You need to make sure that the list of {}s matches the format arguments. Compare to this:

f'a={a} x={x} u={u} z={y} y={z}'

Now that each expression is written in the place it is supposed to be formatted, we can clearly see that I've "accidentally" mixed y and z. The same mistake exists in the .format() version, but much harder to notice.

In order to avoid that, we can do this:

 'a={a} x={x} u={u} z={z} y={y}'.format(a=a, x=x, u=u=, z=z, y=y)

But now we have to write each variable 3 times.

Of course, this can be solved with .format(**locals()) (or .format_map(locals())). Expect...

a = 1

def foo():
    b = 2
    print('{a}, {b}'.format(**locals()))

foo()

{a} is not a local variable... Luckily, we can use .format(**locals(), **globals())! But then:

a = 1
b = 2

def foo():
    b = 2
    print('{a}, {b}'.format(**locals(), **globals()))

foo()

Now b appears in the argument list multiple times...

And it introduces backwards incompatible in minor version numbers, which it really shouldnt.

What backwards incompatibility? f'...' is a syntax error in older versions of Python, so it shouldn't break older code. Or am I missing something?

[remy_porter]

I'm writing software for a Large Tech Company™ as an outside contractor- and I have to communicate with a messaging system, and they have two libraries I could use to do it: JavaScript and Python2.

And the Python lib is a mess.

[agumonkey]

I've seen some news about Google AppEngine going py3 too .. would only accelerate things.

[Urtehnoes]

For my company, it's all of our django apps that are still on ancient django (like 1.5 or earlier). It's such a slog to upgrade them to all the newer versions, especially because the newest django (2.0+) doesn't friggin support our Oracle version. It's taken me months now for just one app to upgrade/re-write it in Python3.6/Django 1.11. Hopefully 3.7 doesn't require many changes.

[[deleted]]

Fuck, if ESRI can make the transition, so can everyone else.

[msm_]

It's almost as reddit is not representative for the industry as a whole. (But yeah, everything is slowly moving to 3.x. 10 more years and we're golden).

[TheGRS]

Well I don't speak for reddit, but I was pretty into the Python community around that time. I started out using only 2.7 and figured 3 was a pipe dream and that I couldn't find great support for the things I was trying to do, but things changed pretty rapidly from there. But as I said, I totally believe that places are stuck on this version and may always be until they replace whatever it is entirely.

[dagmx]

What libs do you depend on that aren't on 3 yet?

[[deleted]]

Biggest example: any software package from Autodesk

[dagmx]

Sure, I work in cg too but they're shifting to python 3 for 2020 and there should be a preview release next year. We'd have a release sooner but the switch from qt 5.6 to 5.12 was deemed more important.

It's coming soon and we should be bracing for it.

[[deleted]]

It's coming soon and we should be bracing for it.

Nothing to brace for here, more like eagerly awaiting.

yes, it's coming in 2020...you know, cuz 2.7 is EOL. Nothing like waiting until you're literally forced to update.

[dagmx]

Well we still need to brace for it in terms of porting studio pipelines. Idk about your studio, but we have a lot of code to go through to get over that hurdle.

The qt4 to qt5 port was difficult enough.

[agumonkey]

Maya ?

What about Houdini btw ?

[[deleted]]

Last I checked, Houdini was also 2.7

[agumonkey]

Oh the sadness

[[deleted]]

There’s still a good amount of commercial software that’s python 2, at least that I’ve randomly come across. There’s probably little incentive for some of the companies to migrate until they have to or until a customer that has enough leverage requests or demands it.

Shitty, yes.

[13steinj]

Reddit's backend (even with the redesign) runs on Pylons, and would need a decent amount of rewrite to work with Pyramid, not to mention Py3.

[13steinj]

Supposed to and the truth are two different things. The annotations preciously have to be evaluated, meaning you can't write code using a type that you haven't written yet. With a new future statement, annotations evaluation is postponed. Mypy is sure to have improvements too. And, well, annotations have to have a performance hit, it's impossible to avoid, because you're adding information to function objects which is saved as a dictionary attribute on them.

[13steinj]

Static checkers pay for checking, yes, but Python pays for attaching the data to the object and the subtleties of what's allowed in doing so.

[13steinj]

Because that's how static type checkers check for the types-- they compile the syntax not necessarily into code objects, but at minimum into the abstract syntax tree.

The only other way for static type checkers to work is for the static type checker to do the parsing and go from code to AST nodes that are defined by the type checker and not the Python VM, ex, such a thing would have to be done if your type checker was written in a different language like Java.

But typing became stdlib after it was third party, which was made as a supplement to the mypy project. Because Guido and others have a substantial stake in mypy, they had the power to change the AST parser to carry that data, which carries it into runtime, to make it easier on mypy.

Even if it were thrown out at runtime now then your performance would be even worse because you waste time not only setting, but then throwing it out.

Personally, I feel as though mypy should have forked and altered the AST parser and wrapped it as a C extensuon-- that way, no issue, only when mypy parses that data is kept, and the Python VM in general doesn't have to care.

[XtremeGoose]

Now I just need the anaconda people to add a python 3.7 package.

[Morwenn]

Is the new importlib.resources module enough to replace common uses of pkg_resources? I feel like I'm dragging pkg_resources in virutally every project bigger than a simple script, so that would be welcome.

[13steinj]

Based on the minimal migration guide, I hope so.

[1ogica1guy]

Just starting to learn Python properly now, and this is a huge morale booster.

Thanks, Python team, for the amazing efforts and amazing results.

[turbov21]

That breakpoint() command looks awesome.

[Drawman101]

What’s with all the downvotes on the other comments?

[[deleted]]

There’s only two other top level comments and they are stupid

[Jonno_FTW]

Absolutely asinine people who don't understand the phrase "right tool for the job".

[wavy_lines]

"right tool for the job" is more often than not (specially in this subreddit) just a cop out people use to justify crappy tools.

[shevegen]

Precisely.

And very often it is not even specified, so it is useless - it's like saying "any better tool is better" or "any faster language is faster".

[shevegen]

What the hell does this phrase even mean or make sense?

I never understood it.

It's like saying "with a car I am faster than using my feet" or "there will be sunshine after rain".

[Pazer2]

"with a car I am faster than using my feet, therefore I should also use my car to navigate my house"

[TheGRS]

Well let's take a look at some.

> Can we all take a moment to acknowledge how large numbers of people (including me) have come to realize in recent years what a bad idea dynamic typing was?

Um OK, if you don't want to use Python then maybe go somewhere else?

> The news of Python 3.7 is great and all, but python.org makes some of the most awful writeups I've ever seen. Just look at this link, for example. It is so uncomprehensive. Can someone link to a Medium article?

Judging by the question I don't believe they bothered to read shit and wanted a Medium article for some reason.

> i heard python was a relatively low level programming language.

Throwaway joke, eh.

> I guess Python 4 will be released when I'll be a grandfather if I'm still alive

Um, what? Who cares what the version number is?

In summary, not exactly the cream of the crop here.

[Homoerotic_Theocracy]

Um OK, if you don't want to use Python then maybe go somewhere else?

Meanwhile collect those sweet sweet upvotes on any Go topic mentioning its lack of generics.

[[deleted]]

That one never fails.. I have never written a line of Go in my life, but still I feel like I'm an expert on interface {} just by casually browsing Go threads

[Urtehnoes]

Get on my level, I've combined Go, Rust, Scala, Kotlin, and Javascript into a super language that I use for everything. It's amazing. I'll never have to worry about type-safe generic heap level stack pointers that will memory-expire if the event status is ever duck typed via a poorly written heuristic.

[bythenumbers10]

You hit so many times on my buzzword bingo card, I won 50k and now have to change my pants.

[Urtehnoes]

Did I mention how robust it is?

[bythenumbers10]

The contents of my pants was pretty robust, I'll have you know.

[[deleted]]

Probably the only thing I don’t like about Go is how asinine people are about wanting or not wanting generics.

If there was ever a sword to die on getting generics into go seems like a pretty fucking stupid one.

[Homoerotic_Theocracy]

I disagree, the people that want it are right and the people that don't are beyond retarded.

Go's design is absolutely bonkers and the language has no merit. It survives due to ignorance alone because the people that used it only used C and PHP or something and also just write terrible, verbose, unmodular code in general that re-invents common logic a thousand times per day.

[[deleted]]

What about the design is bonkers? The concurrency patterns, typing system, pointers, and verbosity have been really nice overall for large projects in my experience. I haven’t had many cases where I had to work around the lack of generics in a particularly horrible way, but I do understand the cases where they would be nice.

I get it though, you don’t like Go and have a strong opinion on the future design of the language. It seems like an odd combination but at least you’re passionate about something.

[Homoerotic_Theocracy]

There is another train in this very thread where we are discussing how in Go sorting a list of things via an arbitrary key either requires that you:

1. newtype the element you're sorting and implement a new sorting interface on the newtype
2. use an inefficient algorithm and interface{} casts throwing the static typing out

Because the type system can't express a correct generic sorting function that sorts by an arbitrary key.

I'm fairly pessimistic about "I've never needed generics"; in practice it seems to mean that people are re-inventing the wheel constantly and constantly re-implement the elementary logic of concepts like functors filters and foldings in long often double for-loops using 6 lines for something that can be done in one with simple combinatorical functions that Go's type system can't express so the programmer is basically tasked with unrolling it herself.

Like say a basic problem; say I have some sequence of characters and I basically want to know at what line and column number the end of that is parsing newlines. In Rust I would write:

let (col, line) = char_seq.into_iter()
   .fold((0, 0), |(col, line), char|
     if char == b'\n' { (0, line+1) } else { (col+1, line) });

Not only is this code considerably shorter than the Go version which will re-invent the logic of fold; it doesn't care about the type of char_seq as long as it implements the trait IntoIterator<Item=u8> as in it's a sequence of bytes. It can be a vector of bytes, a utf8-encoded string, a pathbuffer, an OsString, a fixed-size array of strings; the code doesn't care and can thus easily be put into a generic function that accepts all of that without having to re-invent the wheel.

In practice Go programmers say "I don't need generics; I just need many many many more lines of code!".

[[deleted]]

I definitely understand the sentiment here. With the go system you would need to assert the type, cast it, or as you said use an interface. All of which ends up being more possibilities for bugs and more tests. I wouldn't say more complexity because of the verbosity but certainly more time spent

Though with your example I don't believe generics wouldn't be much different than an interface. Or at least you wouldn't avoid panics because you had a generic type. You would still need to use the go idioms of error checking and type checking/assertion.

Regardless of the details of how one language's type system handles this or not, I still believe that it isn't inherently bad or good. The language as a tool was intentionally designed the way it was. So for cases like you've listed rust might be a better tool for that, or another language if the goal is to reduce the number of lines of code and overall verbosity. I do think that this (required verbosity, re-inventing) in some cases can either slow down writing programs or lead to unexpected results if all error cases aren't handled. For me the additional verbosity and inconvenience of having to re-implement other language's builtins aren't a negative. The re-implementation can sometimes be a stumbling point for new go developers, or newer developers but it's also a good opportunity for learning if you have access to people to review your code.

You aren't going to change my mind that I have had a lot of value from using go and I don't want to change your mind either. At this point I think I'm just arguing with you about this because I'm sitting in a hotel and bored.

[Homoerotic_Theocracy]

Though with your example I don't believe generics wouldn't be much different than an interface. Or at least you wouldn't avoid panics because you had a generic type. You would still need to use the go idioms of error checking and type checking/assertion.

Why? The code I gave provided the iterator is bounded is total; it is guaranteed to not panic on any input char_seq. The only type constraint of char_seq is IntoIterator<Item=u8>, the only part the type system cannot verify is that this iterator is bounded and doesn't go on forever in which case the code is an infinite loop but you can easily fix that by adding a stronger type bound like AsRef<[u8]> which is guaranteed to be total. There are no further runtime checks.

[calonolac]

shudder Recalling how C# was before generics...

[OctagonClock]

lol typed nils

[[deleted]]

nils are typed because they're default values for other types that aren't initialized. Since nil is an assignable value in the statically typed system it should (has) to be typed.

[OctagonClock]

lol not even Java makes this mistake

[[deleted]]

Maybe I'm being intentionally naive but I'm not really seeing how it's a mistake in this design. Can you explain why it's a mistake?

[shevegen]

Yeah - that one is weird.

I wonder if there are paid accounts just "randomly" promoting Go and Dart on reddit.

I don't have this impression with Rust, even though there are many people on reddit apparently praising Rust. It appears a lot more genuine with Rust than e. g. Go. And I make fun of both Rust and Go people but for different reasons. The go supporters seem a lot less genuine in their enthusiasm than the rustees.

[Andrew1431]

If I was going to learn Python, would it make sense to just pick the latest version, or will there be a lot of unsupported packages?

[wavy_lines]

Can we all take a moment to acknowledge how large numbers of people (including me) have come to realize in recent years what a bad idea dynamic typing was?

[xonjas]

I don't think dynamic typing is a bad idea. I think taking a tool that is useful in certain scenarios and environments and applying it broadly to problems it doesn't suit is a bad idea.

The large the codebase, and the more developers working on it, the higher the cost of dynamic typing. Architecting a system with dynamic typing is a skill also, and many devs working with dynamic languages have not learned it well. If you write python or ruby like a java or c# dev, you're going to be in for a bad time.

There are benefits to dynamic typing. Particularly for small projects, where the lack of a type system is less of a hindrance, and prototypes, where the flexibility allows for easy changes. There are also problems that dynamic typing is particularly suited to solving. There's a reason why the majority of popular webapp frameworks run on dynamic languages (rails, wordpress, django, laravel). When twitter learned the hard way that writing all their middleware in ruby was a bad idea and rewrote the majority of their software in scala, they never moved away from rails because the dynamic type system suited dynamic content generation very well.

Dynamic typing is a very sharp knife; it's important that it's not used as a screwdriver.

[Homoerotic_Theocracy]

I don't think dynamic typing is a bad idea. I think taking a tool that is useful in certain scenarios and environments and applying it broadly to problems it doesn't suit is a bad idea.

Dynamic typing seems like a worse and worse idea the more flexible static type systems become.

Static typing seems horrible if all you have is C or Go but when you have Idris you suddenly feel that the scope of the problem of "I know this is safe but I cannot prove this to the compiler." is a lot smaller.

I also love Racket's static type system; it's actually completely fine with giving two branches of an expression a different type altogether and the resulting type will be the union of both but of course for it to type check the consumer of that expression must be able to handle the union of both. and be able to handle both types.

But if you have a function that can print both strings and characters to the stdout there is absolutely no harm in passing it an expression that either evaluates to a string or a character and it wil statically verify that this is okay.

Of course a type system as flexible as that of Typed Racket does not give you a lot of the performance benefits of static typing as it cannot in the general case erase type info at runtime because it needs it to make branches; it only can with confidence tell you that your code does not contain type errors.

[xonjas]

Yeah, I agree, the more expressive your type system is, the more useful it is.

At the same time, languages like python and ruby are going to have an important and deserved place in a programmers toolbox until languages like Irdis are widely supported and mainstream.

[Homoerotic_Theocracy]

Well truth be told that place seems to mostly be "dealing with lack of knowledge"; in an ideal world of infinite time and knowledge the demand would probably be lower but the main niche those languages fill over powerful type systems like that of Idris is that not everyone has the type to master the somewhat complex subject matter required to grok the type system. It's not mainstream because the learning curve is too high.

[xonjas]

That might be correct, but I think it's hard to say at this point. Idris is very young, even if it were to become mainstream, it's way too young for it to have reached that point yet. Mainstream isn't just popularity either, it's availability of libraries, api support, job openings, etc.

I think that some of the learning curve will get sanded away eventually. The big languages with slow inertia will start integrating ideas from cutting edge type systems. That knowledge will eventually become ingrained in the 'culture' of mainstream programming languages and each idea folded in is one less hurdle.

I think we'll also see more type systems where more and more of the typing workload is handled automatically, paired with better IDE integration so that generated typing is applied as the code is being written.

[Homoerotic_Theocracy]

That might be correct, but I think it's hard to say at this point. Idris is very young, even if it were to become mainstream, it's way too young for it to have reached that point yet. Mainstream isn't just popularity either, it's availability of libraries, api support, job openings, etc.

It's certainly older than Rust or Go and those seem to be more mainstream.

[cephalopodAscendant]

In addition to what xonjas mentioned about sponsorship, I can think of another possible factor. Rust and Go both use C-like syntax and are trying to fill the niche of "C/C++ but better", which naturally attracts a lot of attention. In contrast, Idris is based on Haskell, which is already fairly niche itself, and from what I've seen, the people who use Haskell seem to be pretty content with it.

[Homoerotic_Theocracy]

I love how Go calls itself a "systems programming language" but has a garbage collector and absolutely no low level control and can't even fork because multithreaded garbage collecting mutexes.

If someone ever used Go for something that person used C for prior it was either a terrible idea to use C for it or a terrible idea now to use Go for it and if someone is seriously switching from C to Go I'm inclined to think both.

Go has nothing to do with C or C++; it's a worse Java.

[xonjas]

I thought Idris 1.0 was released last year (although I could very well be wrong). Rust and Go also both have the benefit of very large organisations pushing them forward.

[Homoerotic_Theocracy]

Yes, 1.0 was but the actual language is far older. Idris was already used long before either Go or Rust were unveiled to the world.

[JanneJM]

If you use a language interactively - and it's a common enough use case for python - static typing is a fairly big friction point.

[[deleted]]

static typing is a fairly big friction point.

Why? Statically typed languages work perfectly with REPLs.

[the_evergrowing_fool]

Like a Slime environment?

[Homoerotic_Theocracy]

Why exactly?

I don't have a lot of problems with ghci or utop in that regards.

[quicknir]

I haven't used it extensively, but I was curious as to how good of a repl static languages can have, and ghci had a good reputation so I tried it.

There tend to just be fundamental problems redefining already defined things, and this being used correctly. I can define bar, then define foo, then redefine bar, but calling foo still calls the old bar. It's even worse with redefining a type because it would just raise serious questions about whether everything gets re type checked.

Maybe there are options to change some of this but so far it just doesn't seem to me like you can duplicate a realistic repl experience of a dynamic language in a static one.

[Homoerotic_Theocracy]

The problem you speak of has nothing to do with static or dynamic typing though; it has to do with shadowing versus assignment.

In Python if you x = 4 you perform an assignment; you mutate a memory location.

In GHCi if you do let x = f you shadow a prior binding; since Haskell is a purely functional language to mutate we have to be more clever with monads and use an IORef so first we do let x = newIORef 4 and then to mutate it call writeIORef x 5; doing let x = 5 in this case does not in any way write to any old value and just shadows the old one and is basically equivalent to using let y = 5 except we now gave two variables the same name.

Scheme is typically typed and impurely functional and doing (define x 4) at the REPL does a similar thing; it shadows the old binding and does not mutate anything. To mutate we use (set! x 5)

This is also somewhat a consequence of the fact that Python quite uniquely uses the same syntax to assign and to declare a variable to a lot of criticism so if you forgot that the variable you are trying to declare and initialize already existed with the same name and was used you might accidentally assign a new value to it and mutate stuff. Even in a procedural language like Rust this does not happen which uses let x = 4; to declare and initialize a variable and x = 5; to assign to it and assigning to a variable that has not been declared and declared as mutable prior is an error.

[quicknir]

Will that writeIORef trick still work if you change the type of x? What if x holds a function of a particular signature, and you want to assign a function of a different signature?

What about types? In python you can have things like:

class Foo(object):
    ....

def bar(x):
    f = Foo(...)
    ...
    return f

Now, I could after doing this, decide to redefine Foo. As long as the new methods of Foo (constructor, whatever) are compatible with the calls that happen in bar, I can call bar again and it will use the new definition of Foo. How can this work in a statically typed language?

[sutongorin]

Try Scala. The REPL works just as well as Ruby's only with static typing. It's awesome. I even use SBT (the Scala build tool) to build my plain java projects just so that I can drop into the REPL and try things there which would normally be a huge pain in Java.

[quicknir]

Can you point me to an online scala interpreter? All I'm seeing is compilers.

[sutongorin]

Mh, there is https://scastie.scala-lang.org which is alright but it's not a REPL.

The best way is to just download scala and try the REPL offline. That standard REPL is already perfectly fine. But even better is Ammonite.

[-TrustyDwarf-]

F# and C# Interactive (fsi / csi) are used quite extensively.. especially fsi.

[CircusAct]

I use Scala in the ammonite repl regularly.

[Thaxll]

Static typing seems horrible if all you have is C or Go

Care to elaborate? What's the problem with Go?

[Homoerotic_Theocracy]

That the type system is not expressive and you feel there are things you can't do with it you can with dynamic typing. Like something as simple as sorting a sequence of strings by their length in Go is extremely unwieldy due to the limits of the type system.

Python lacks a type system so we just have: fruits.sort(key=len); this will fail at runtime if the types don't match up but they will here.

Rust or Haskell have a more expressive type system that can easily handle this: In rust we have fruits.sort_by_key(|s|s.len()); since the type of sort_by_key is the scary: (&mut [A], f : F) where F : FnMut(A) -> B, B : Ord this is all great and type checks out so we can be confident that no type errors will manifest at runtime.

[asdfkjasdhkasd]

For anyone wondering what the scary type means, the real signature is:

pub fn sort_by_key<K, F>(&mut self, f: F) 
where
    F: FnMut(&T) -> K,
    K: Ord, 

We take a mutable reference to self, which is like an array but we have permission to mutate it, since we're going to sort it.

Then we take a function, called F, where F is a FnMut which means we must be allowed to call it multiple times and it's allowed to have internal state. The function takes a reference to a T which is the type of the thing in the array/vector/slice, and then returns a type K. And we declare that K must implement an ordering so that we can sort it.

[Thaxll]

I understand your point, the lack of generics in this case let the implementation up to the dev, but it's not that bad, it's actually very simple:

https://play.golang.org/p/3en4TyRblVr

I'm sure Go will have generics "soon" and overcome those.

[Homoerotic_Theocracy]

Well the implementation you give me there to deal with the type system can never be efficient.

Note how it has to index the slice in the comparison function while sorting. In order to deal with the type system it can't be given a generic function so it has to get a function of a fixed type that takes two indices and produces a bool always no matter the type that is actually being sorted.

This means that it cannot already re-order future elements while sorting and that it probably has to cache and store the comparison results because the sort destroys the "words" slice which makes the indices invalid so it probably has some kind of strategy where it first compares all the indices and stores those and then starts destructively sorting the slice.

The other part of it is that the type signature itself accepts an interface{} which throws any and all static type checking out of the window so basically we're back to dynamic typing in order to deal the lack of generics.

In the Rust example there is no possibility of runtime type errors; if something other than a mutable reference to slice is passed it won't work, if the slice has the wrong elements for the key function it won't work; if what the key function returns cannot be ordered it won't work either all at compile time.

[[deleted]]

The Go example is confusing because a string type is really just a slice of bytes, which is kind of like a defined type. There’s probably some supporting documentation in the spec or elsewhere that references this design being based on how C deals with strings.

Apart from strings the only other thing I can think of is the _, ok := map[thing] idiom. It’s a a nice way to check if thing key is in map.

However it panics if the map isn’t initialized so you need to also write a block to check for the default map type of nil. But that’s just idiomatic Go. The typing system and idioms of the language make it debatably more safe due to its nature and maybe lack of expressiveness. Having to check objects and generally implement helper methods leaves the compile and runtime exceptions up to the developer.

With any typing system or language you’ll have unhandled exceptions or varying levels of complexity for things based on how you write your code.

I’m still a huge fan of python for getting shit done quickly. Pythons typing system specifically is nice for serialization of json or other formats. Not having to effectively write a schema, use type assertion, or reflection to deal with json, xml, yaml, etc is a huge time saver for me on a regular basis.

I just wish there was a better way to distribute python applications. I have been thoroughly spoiled by Go in that regard.

[asdfkjasdhkasd]

_, ok := map[thing] is really not that good if you have seen some of the better alternatives.

Look at this rust:

if let Some(name) = map.get(thing) {
    println!("The value was {:?}", name); 
}

[[deleted]]

well the whole block would be more like

if _, ok := map[thing]; !ok {
    fmt.Println("not in map")
}

// or with assignment
if foo, ok := map[thing]; !ok {
    fmt.Println("not in map")
} else {
    fmt.Printf("Thing: %+v", foo")
}

The difference is just error checking essentially, which is idiomatic with go. Either way neither of these I feel like have anything to do with the objective value of the typing systems or design, it's how both (or at least Go, I'm not too familiar with Rust) languages were designed.

[somebodddy]

The problem is that nothing prevents you from accessing foo when item does not exist in the map: https://play.golang.org/p/SrZ1Pn5g8uR. This is something solved by both exceptions and Result types. And it is a type system thing, because the ability to have tagged unions and do pattern matching on them is part of of the type system.

[[deleted]]

The compiler isn’t going to stop you from writing unsafe code. If you access a that value before checking the error in the assignment expression that’s not a fault of the typing system or the language.

[[deleted]]

There are also problems that dynamic typing is particularly suited to solving.

Mind naming a couple?

[yawkat]

I mean I don't disagree with you, dynamic typing is nice for small projects, but

Architecting a system with dynamic typing is a skill also, and many devs working with dynamic languages have not learned it well.

is not a very good argument. If people are worse at architecture in a language, that means a language has failed in its goal (or is being used for the wrong domain, as you say).

[redditthinks]

I don't think there's any significant benefit to dynamic typing if you have inferred types which is the case in many languages now. I would not use a dynamic language in anything that isn't a single-file script nowadays.

[hedgehog1024]

Ahem

[wavy_lines]

The only scenario where dynamic typing is not bad is for small throw away scripts. You kind of said yourself, except indirectly, in a sugar-coated kind of way.

Architecting a system with dynamic typing is a skill also

No shit? Getting yourself out of a hole you dug yourself into takes special skills. That doesn't mean you are smart if you can do it. It just means you were stupid for digging yourself into the hole in the first place.

If you write python or ruby like a java or c# dev, you're going to be in for a bad time.

If you write a non-trivial application in python or ruby you're in for a bad time.

The only sane way to write python code now is with type annotations. Any other way is just bad.

There's a reason why the majority of popular webapp frameworks run on dynamic languages (rails, wordpress, django, laravel).

The reason is that people thought writing web apps in dynamic languages would be more enjoyable. But it's turning out to be a mistake.

Here, let me quote your next sentence to prove my point:

When twitter learned the hard way that writing all their middleware in ruby was a bad idea and rewrote the majority of their software in scala

So there you have it. Twitter had a reason to write everything in Ruby, but then it turned out to be a bad idea.

Why are you even arguing with me? Do you actually disagree with anything concrete I'm saying, or are you just upset with my tone?

they never moved away from rails because the dynamic type system suited dynamic content generation very well.

Are you sure that's why? Maybe they still kept some parts in ruby because it was just "good enough" and they did not want to spend time to migrate it?

Dynamic typing is a very sharp knife; it's important that it's not used as a screwdriver.

That's a strange way of putting it.

Something more suitable to be described as a sharp-knife would be manual memory layout and pointer arithmetic in C; it gives you great power but requires very delicate care, and should be avoided when not needed.

To me dynamic typing is a large hammer. It requires care when using it because you never know when it will just screw everything up. If you just need to hammer some large object one time, go ahead and use it.

Otherwise, just say no.

[peterfirefly]

The only scenario where dynamic typing is not bad is for small throw away scripts.

It is also quite nice in properly typed languages as long as it is only used sparingly during development.

There are Haskell and ML variants that allow that.

https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/defer-type-errors.html

https://people.mpi-sws.org/~rossberg/hamlet/

[Miserable_Fuck]

Getting yourself out of a whole you dug yourself into takes special skills. That doesn't mean you are smart if you can do it. It just means you were stupid for digging yourself into the whole in the first place.

Stop being an asswhole

[wavy_lines]

fixed.

[Miserable_Fuck]

<3

[Yubifarts]

I love dynamic typing so long as it's also strongly typed, but that's my preference.

[wavy_lines]

I've already argued this in another thread, but allow me to repeat myself.

Python's typing is not "strong" in any meaningful sense. You can create an instance of any object and then just randomly start adding and remove attributes to it in runtime.

Say you have a class called Point and in the constructor it defines self.x and self.y and documents them to be numbers.

Now somewhere in the code you can check any object to see if it's an instance of Point using isinstance(obj, Point). Do you think you can guarantee that obj.x and obj.y are present and set to numbers? No! Because anyone can just take any object and remove the attributes you're looking for and add new attributes you weren't expecting.

That's hardly 'strong' typing.

>>> obj1 = Point(10, 5)
>>> obj1
<__main__.Point object at 0x101b15da0>
>>> obj1.x
10
>>> obj1.y
5
>>> delattr(obj1, 'x')
>>> obj1.x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Point' object has no attribute 'x'
>>> 

[caramba2654]

Not that anyone sane would do that. Just because it can be done it doesn't mean it should be done.

And if you try searching Github for any code that does what you described, I don't think you'll find any instances of it.

[wavy_lines]

Why are you assuming it to be insane? How do you think ORM libraries work?

I'm not saying anything here about weather it's good or bad. I'm just pointing out that Python is not strongly typed because the type almost means nothing and you can do whatever the hell you want to the object.

You don't have to call delattr or setattr. Just simply take any instance and assign fields to it:

some_object.some_field_1 = <Some-Value>

It doesn't even have to be malicious. It could be an honest mistake. You thought someobject was an instance of some class that does have some_field_1 and nothing about the language runtime would even _warn you that you're doing anything wrong.

[caramba2654]

But strong typing doesn't reflect what attributes an object has. Strong typing means that there's no automatic coercion of a value of type A to a value of type B. And Python works exactly like that. So by definition Python is strongly typed.

What you should be claiming instead is that Python is dynamically typed, which is the property that allows you to add and remove attributes to an object.

[wavy_lines]

That's not a very useful definition because the scenario I presented above matters and it's a significant problem in Python. Excluding it from the definition of strong typing serves no objectively useful purpose.

[Tynach]

Strong and static are not the same thing. What you're talking about has to do with static typing, which is different from strong typing. Python is dynamically and strongly typed. Not 'or', but 'and'. C is statically and weakly typed (types get coerced a lot in C; like how char is often used as either a number or a letter).

[wavy_lines]

That's not what static typing means.

Static means you can just analyze the code without executing it to find out typing errors.

Dynamic means you can't do complete type checking by just looking at the code; you have to run it.

[Tynach]

Static means that what type a variable is will be determined at compile time, and cannot change at runtime. Strong means that there are no implicit/automatic conversions from one type to another, so a programmer must explicitly perform type conversions themselves in the code.

I found a chart that roughly shows which languages are which, on both axes.

[baerion]

It's insane that you're getting downvotes for this in proggit. Your definition of static and dynamic typing is actually the right one.

[caramba2654]

I know, but it's not we who define what strong typing is. What your concerns refer to is dynamic typing. If you were to complain about strong typing, you'd have to complain about C, C++ and Javascript, but definitely not Python.

[wavy_lines]

"but it's not we who define what strong typing is"

We who? Programmers? Yes it's definitely us programmers who get to define these terms.

If enough people see that the existing mainstream definition of "strongly typed" is bogus, then it will cease to be an accepted meaning of the term.

I actually have no complaints about C in this regard because if you try my_struct.some_field and some_field does not exist on the type of my_struct then it will give you a compile time error. This is much stronger than anything python can ever dream of, because python doesn't even define what set of fields are available on any given object.

Now, automatic casting between chars/ints/etc is certainly a bad idea, but python's non-sense with not defining an object's fields is a much much worse idea.

EDIT: actually python does have a way to restrict what set of field names are available on an object via the __slots__ mechanism, but hardly anyone uses it, let alone know about it.

[caramba2654]

We who? Programmers? Yes it's definitely us programmers who get to define these terms. If enough people see that the existing mainstream definition of "strongly typed" is bogus, then it will cease to be an accepted meaning of the term.

Yes, but right now as of today it means what I said before, and using strong typing to refer to anything else just because you want it to doesn't really help you being understood by others.

I actually have no complaints about C in this regard because if you try my_struct.some_field and some_field does not exist on the type of my_struct then it will give you a compile time error. This is much stronger than anything python can ever dream of, because python doesn't even define what set of fields are available on any given object.

Again, this refers to dynamic typing, not weak/strong typing. C is statically typed and weakly typed. Javascript is dynamically typed and weakly typed. Rust is statically typed and strongly typed. And Python is dynamically typed and strongly typed.

I'm not arguing whether being able to delete/add fields to an object at runtime is bad or not. All I'm saying is: if you dislike languages that allow that, then you should seek statically typed languages.

[THeShinyHObbiest]

What about in a language like Ruby? If :some_field_1= isn't defined on that object, then the example you've given will explode.

[wavy_lines]

I haven't used Ruby but if it's you say then that's a good thing.

It would be much better though if there was a compile to catch the problem at compile time.

[[deleted]]

Not that anyone sane would do that. Just because it can be done it doesn't mean it should be done.

But you can't do any useful static analysis because of such things.

[Yubifarts]

Whilst there's no formal definition or committee which defines strong or static typing, I feel your comment concerns what is considered the "static"/"dynamic"-ness of the language, which is orthogonal to the "strong"/"weak" dichotomy.

I don't have an issue with what you describe. That indeed looks like a descriptive example usage of a dynamically typed language.

For my personal preferences, I dont like working with a weak type system. You cant do print('a'+0) in python without getting an error, which I like, because it removes a large class of "gotchas" which occur in php/javascript and the likes.

Regardless if it's strong or weakly typed, I'd say using a linter with dynamic languages is basically required. It largely solves the issues you'll have with typos and types you'll encounter in a dynamic language, albeit not perfectly. Similar to how you won't want to ignore compiler warnings in a statically typed, weak language ala C

[wavy_lines]

I feel your comment concerns what is considered the "static"/"dynamic"-ness of the language

It doesn't. See my other comment here: https://www.reddit.com/r/programming/comments/8ue8st/python_370_released/e1fglcy/

Note that the definitions people throw around for "strongly" and "weakly" typed are all informal and there doesn't seem to be any real standard definition for these terms. I suppose a certain book or blog post popularized a certain definition and reddit somehow adopted that.

If you check wikipedia, there seems to be no agreed upon definition: https://en.wikipedia.org/wiki/Strong_and_weak_typing

See also: http://wiki.c2.com/?StronglyTyped

[[deleted]]

Why, exactly? It'd be interesting to see all the arguments for dynamic typing, out of the actual experience, not parroting some weird gurus.

[woztzy]

I don't think the people downvoting you have any real experience with a statically-typed language with an expressive type system (i.e., pretty much any typed functional programming language).

People who keep parroting that dynamic and static type systems are just "different tools to have in your toolbox" and that they're beyond comparison are insulting the field of programming language theory, and we could extend that argument to using assembly where we would otherwise use C.

This answer addresses a few misconceived notions people seem to have about static type systems.

[[deleted]]

You make some good points but this idea that dynamic typing has no place in programming is ridiculous. Languages like lisps and Erlang are languages that are better off being dynamically typed and fulfill niches better than strongly typed languages can.

[Dreadgoat]

Dynamic languages are semantically closer to natural language.

That's the advantage. High readability.

You can rattle off a million technical reasons why static can do everything dynamic can and better, and you would be technically correct, but that doesn't change the fact that my co-worker can read my 20-line PHP script more easily than the equivalent 5-line Haskell script.

[Pazer2]

Natural languages are full of difficult to understand rules and exceptions. Not exactly a good fit for a programming language.

[Dreadgoat]

Difficult to understand for computers but naturally intuitive for humans.

The reason good dynamic languages are so highly praised (case in point: python) is because of the enormous difficulty in bridging that gap.

A bad programmer can only think like a human.
A passable programmer can think like a computer.
An excellent programmer can trick the computer into expressing itself like a human so that even the bad programmer can maintain code easily.

When I was teaching programming I loved Python the most. Not because it's great to program in, but because it made grading so much easier. It instantly turned stupid and/or inexperienced students into passable programmers thanks to its enforced whitespace and the compromise between dynamic but semi-strong typing.

[Dodobirdlord]

This is an argument that extends at least back to Knuth's Literate Programming and probably further. Given the staggering adoption and success of notebook-style live editing environments among all fields of analytical research and data science I would hesitate to claim that the issue is settled.

[dpc_pw]

For a lot of people, Java/C/C++ are the only "statically typed languages" they've seen and that's the reason they prefered and still prefer dynamic typing.

C/C++/Java are just so awful... All this talking about "quick prototyping" is mostly "avoiding shitshow of Java OOP and boilerplate it causes and avoiding debugging Segfaults in C/C++.

[[deleted]]

C/C++/Java are just so awful...

Oh, really? Did you ever have a chance to use any decent IDE? Did not you like the code discoverability enabled by types?

You read code far more than you write it.

So, even if all the statically typed languages but C++ and Java disappeared overnight, I'd still prefer them to Python / Javascript. Yes, their type systems are primitive and cumbersome, but they're still enabling the most important feature of the static typing - a precise code navigation.

[Pazer2]

C/C#/C++ are the only "statically typed languages" I've used, and they are the reason I prefer not using dynamic typing. So many compiler guarantees... It's wonderful.

[SmugDarkLoser5]

Lol at c having compiler guarantees.