121–130 of 297 posts
Well, I want Go to have refcounting instead of current GC, so my programs could guaranty latency. Single-threaded runtime, without all the locks, slow channels, races and so on, because there is no point in so much overhead and complexity for the majority of programs. More consistency couldn't hurt, so I wouldn't have to assign anonymous function to a variable just to return it. Fast regular expressions compiled by t…
Well, I want Go to have refcounting instead of current GC, so my programs could guaranty latency. Single-threaded runtime, without all the locks, slow channels, races and so on, because there is no point in so much overhead and complexity for the majority of programs. More consistency couldn't hurt, so I wouldn't have to assign anonymous function to a variable just to return it. Fast regular expressions compiled by t…
For compiled regular expressions: just use PCRE library for compiled regular expressions. I bet there's already some library that does it for you.
Maybe you should take a look at Lua and especially LuaJIT [1]. You might like it. Lua(JIT) is single threaded, but provides co-routines [2] as a language construct. Performance is about same as Golang, sometimes faster, sometimes a bit slower. Lua has GC, but you can control latency by controlled GC invocations. It can be made pretty predictable, a lot of current AAA games use Lua internally.
LuaJIT's FFI [3] is excellent, calling native C libraries is a breeze, very easy and requires no bridge libraries or code.
[1]: http://luajit.org/
Yes, this can sometimes help you to find silly errors in your code at compile time (and thus occasionally save you a bit of time) but, unfortunately, that occasional benefit doesn't make up for the productivity loss incurred from constantly trying to 'please the compiler'.
Dynamically typed languages offer fluidity in your logic where it is needed. For example, if you add an integer and a decimal (floating point) number together, there is nothing wrong about this mathematically, but a static compiler will complain! It's a limitation of the compiler not the programmer!
Statically typed languages force you to implement rigid class/type schemas within your logic (sometimes with complex hierarchies) - These schemas have to be significantly reworked whenever your business requirements change.
Well, I want Go to have refcounting instead of current GC, so my programs could guaranty latency. Single-threaded runtime, without all the locks, slow channels, races and so on, because there is no point in so much overhead and complexity for the majority of programs. More consistency couldn't hurt, so I wouldn't have to assign anonymous function to a variable just to return it. Fast regular expressions compiled by t…
I'm not sure if this is sarcasm or not, but I will assume not. If they made the changes you suggest golang would be come useless to me. That isn't to say what you want isn't valid, only that it gets to the heart of all these arguments. Every design decision comes with trade offs and you can't please everyone.
Earlier quoted context omitted.
maps and filters are things that have existed for a long time, and are extremely commonplace. They are also very representative of common operations in programming. Not having generics means we can't properly build these ourselves, and Go doesn't offer list comprehensions, so instead we're forced to for loop.
Yes, loops, just like we learned in CS101.
Well, I want Go to have refcounting instead of current GC, so my programs could guaranty latency. Single-threaded runtime, without all the locks, slow channels, races and so on, because there is no point in so much overhead and complexity for the majority of programs. More consistency couldn't hurt, so I wouldn't have to assign anonymous function to a variable just to return it. Fast regular expressions compiled by t…
The majority of the programs do not really need to guarantee latency. That being said, it is well known that Golang's present GC performs poorly. It presently fails to free memory in certain cases, and has pretty high overhead. There is work done on improving the GC to be fully concurrent, but that is still probably still 2-3 major versions away.
Earlier quoted context omitted.
The point is that you reach an area where the mathematical ideas don't map perfectly to the underlying functionality you're providing. You can make your language "unsound" by violating those mathematical principles, or you can make something like the I/O monad. It is indeed "soundness" vs "practicality". EDIT: Oh, and that link seems to have misunderstood the 'worse is better' philosophy -- C++ isn't the champion of…
Paul explains fairly well why he thinks C++ is a good example of "worse is better", including quotes from the language designer to that effect. I think when you get to more complicated (or at least alien) abstractions like the I/O Monad, it's not about whether it's practical to build software with it. It's perfectly practical - I know people working at big investment banks writing large scale software in Haskell, and…
The problem with being in such a rush to confirm your own worldview is that you don't learn anything from anyone else's. The 'worse is better' philosophy is about valuing simplicity over completeness, specifically in the context of UNIX/C vs Lisp machines back in the 80s. How do you think most of those people feel about, say, the STL?
Statically typed languages impose unnatural hardware-oriented constraints on your business logic - It forces you to spend extra time and effort to make sure that your logic is in a format which the compiler can understand. Yes, this can sometimes help you to find silly errors in your code at compile time (and thus occasionally save you a bit of time) but, unfortunately, that occasional benefit doesn't make up for the…
For instance, in Haskell I can type 2 + 3.75 and I get 5.75 right back -- no errors. That's because the type signature of + is "Num a => a -> a -> a," meaning I can add two of any type of Number (Integers and Floats are both Numbers, of course).
Earlier quoted context omitted.
All loops encode simple logic? I don't think that's true. Either way, a very good reason for not using loops is to make code more readable. If I see a loop I have to run it inside my head to figure out what the intent is, and if there's multiple things going on, that can take time. If I see a 'map' I think "right, this is tranforming every element in this list in this way"; if I see a filter, I think "right, this is…
Expanding a map to a for loop is very simple. Yes it removes a shortcut available when writing code, but when reading code I can consume that simple chunk of logic in one mental bite just as easily as I can a call to map.
The first point "no generics, no code reuse" is the best one. Go really needs generics/templates/macros or _something_. It doesn't even have subclassing, although you can kinda extend a type if you only use its public interface. I've been tempted to see if I could reasonably use the "text/template" package and feed that back into the Go compiler to achieve this. The rest is mostly a Haskell fanboy whining that Go isn…
"Code reuse!"
Cracks me up every time. ;-)
We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...